# Objective
Closes#61646.
For code completions, Zed currently fuzzy-matches against
`CodeLabel::filter_text()`:
https://github.com/zed-industries/zed/blob/ddd9b3a3f09fe67258b81e017414df37266809d0/crates/editor/src/code_context_menus.rs#L337-L343
`CodeLabel::filter_text()` is a substring of `CodeLabel.text`, which is
essentially the text itself. `CodeLabel.text` is constructed by Zed's
per-language adapters from the `label` and `detail` fields of the
completion items returned by the language server — the exact
construction differs from adapter to adapter, but the source data is the
same. In effect, `CodeLabel.text` ≈ `label` + `detail`. Zed therefore
filters on the server-returned `label` and `detail`, while the
server-returned `filterText` field is silently ignored.Per the LSP spec:
```
/**
* A string that should be used when filtering a set of
* completion items. When omitted, the label is used as the
* filter text for this item.
*/
filterText?: string;
```
we should use `filterText` when it is provided.
Normally, language servers populate `filterText` as a substring of
`label`, so the current behavior works fine. But for certain language
servers or functions, `filterText` can be entirely unrelated to `label`
and `detail`. For example, for `std::path::Path::parent()` in Rust,
rust-analyzer returns:
```json
{
"label": "parent()",
"labelDetails": {
"detail": "(alias dirname)",
"description": "fn(&self) -> Option<&Path>"
},
"kind": 2,
"preselect": true,
"sortText": "7ffffff6",
"filterText": "parentdirname",
...
}
```
Typing `dirname` therefore never surfaces this completion.
The root design issue behind this bug is that `CodeLabel` is not
well-suited to filtering LSP completions.
## Solution
`CodeLabel` and its related methods are kept untouched: the struct is
reused across the repo and is only unsuitable for filtering LSP
completions. Instead, the changes are made in `CompletionSource` and
`Completion`, each gaining a `filter_text()` method:
- `CompletionSource::filter_text()` handles LSP completions, returning
the server-provided `filterText` and falling back to the `label` when
`filterText` is absent.
- `Completion::filter_text()` is the general entry point used for fuzzy
matching; for non-LSP completions it falls back to the existing
`label.filter_text()`.
The fuzzy match target is switched from `CodeLabel::filter_text()` to
`Completion::filter_text()` — that is the core change.
Since the fuzzy match target is no longer guaranteed to be a substring
of the displayed `CodeLabel.text`, the matched characters no longer have
a direct position in the displayed text to highlight. Bold highlights
are therefore only rendered when `CodeLabel::filter_text()` equals
`Completion::filter_text()`. This is a safe choice, though not an ideal
one.
## Testing
Added a new GPUI test covering the new behavior; also built and tested
with a before/after comparison, attached in the Showcase section.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
| Before | After |
|:--:|:--:|
| <img width="708" height="308" alt="Before"
src="https://github.com/user-attachments/assets/ca2e3820-7ea1-4dcc-a91f-28aab71aecc5"
/> | <img width="696" height="248" alt="After"
src="https://github.com/user-attachments/assets/334e240b-64d5-495b-aef6-772456b993ba"
/> |
---
Release Notes:
- Improved completion filtering for lsp completions.
While building Zed with nightly rustc I've noticed it doesn't compile
because of good old pathfinder_simd. It also emits a bunch of warnings
about use of f64 literals where f32 is expected, so I've fixed them - it
should make future upgrades more straightforward.
# Objective
- Fixes#60374
## Solution
- Moved the `documentation_label` from the `ListItem::end_slot` into the
main `h_flex` layout alongside the `main_label`.
- Added `.flex_shrink(1.0)` and `.truncate()` to the documentation
container.
- To allow it to shrink gracefully when space is tight.
- Removed `.w_full()` from the main label's container.
- To prevent it from aggressively occupying all available horizontal
space, allowing the layout to balance the width between the label and
the documentation.
## Testing
- Visual and layout fixes tested manually by verifying the completion
menu in `settings.json`.
- All unit tests in the affected crate passed: `cargo test -p editor`.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
### Visual change
<img width="813" height="314" alt="スクリーンショット 2026-07-20 143707"
src="https://github.com/user-attachments/assets/1daa3fa4-a479-465a-b7fd-cc803242c8a2"
/>
---
Release Notes:
- Fixed(CompletionsMenu): prevent completion labels and docs from being
truncated.
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
PR https://github.com/zed-industries/zed/pull/45892 changed the logic
for rendering completion labels and divided rendering up into the "main"
part (consisting of the completion's `filter_range`) and "details" part
(everything after `filter_range`), but no longer renders text that comes
before the `filter_range`. This text is probably not relevant in too
many cases but makes some Rust completions unclear and ambiguous, as can
be seen in this example:
Without this change:
<img width="1262" height="313" alt="Image"
src="https://github.com/user-attachments/assets/dcdd9da4-c449-445d-b379-771b368c3778"
/>
With this change:
<img width="1328" height="376" alt="grafik"
src="https://github.com/user-attachments/assets/05fdaf95-7a18-4d50-8e3b-35be10d9a1ef"
/>
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes#56973
Release Notes:
- Fix completion labels not being rendered completely
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
This PR tackles how we communicate errors/warnings relative to skills.
It touches three major surfaces: callouts in the thread view, menu items
in the completion menu, and settings UI. These are all the places where
we display something to tell the user a skill might have a problem.
In the settings UI, we now clamp the skill description to five lines.
And if there's a warning, we show the warning icon and the description
in a tooltip when hovering it:
<img width="600" alt="Screenshot 2026-06-08 at 10 51@2x"
src="https://github.com/user-attachments/assets/1a1233b0-c24a-4082-9fe6-2ab1d00ba9fd"
/>
In the thread view, we display callouts with the warnings. I simplified
the long-description one specifically given we can click on each skill
item right there, so no need for a "manage global skills" button or
descriptions in each item:
<img width="600" alt="Screenshot 2026-06-08 at 10 52@2x"
src="https://github.com/user-attachments/assets/4b9aad23-7362-40cd-8ab5-6dfceb46badd"
/>
In the code completion menu, I removed the icon that appeared at the far
right and instead added the ability for it to render a colored warning
icon instead of the icon it'd already display in the left; I think this
simplifies it nicely:
<img width="350" alt="Screenshot 2026-06-08 at 10 53@2x"
src="https://github.com/user-attachments/assets/8d0c731a-31a0-4d30-abab-1eb40f61031e"
/>
Release Notes:
- Agent: Improved how we communicate problems relative to skills, in
both the agent panel and the settings UI.
---------
Co-authored-by: Martin Ye <martin@zed.dev>
Closes https://github.com/zed-industries/zed/issues/54840
There are likely more places we can use this new workspace function in,
but these are the known ones to me right now
Release Notes:
- Fixed file hyperlinks in the agent panel not opening files when
clicked
Co-authored-by: saberoueslati <saberoueslati12@gmail.com>
This PR adds an icon button to Markdown codeblocks allowing to control
whether or not the content should be wrapped. At the moment, this is not
hard-persisted, meaning that 1) wrapping text in one codeblock instance
does not affect others, and 2) the codeblock will be reset every time
its view is recreated (i.e., closing and opening a Markdown Preview tab,
an agent thread, etc.). I intentionally kept it simple just to see how
it feels, but we can certainly consider a setting later on.
| Unwrapping | Wrapping |
|--------|--------|
| <img width="782" height="658" alt="Screenshot 2026-05-20 at 5 09
2@2x"
src="https://github.com/user-attachments/assets/e9151e91-32ba-40d4-9c65-535dec309291"
/> | <img width="736" height="604" alt="Screenshot 2026-05-20 at 5
09@2x"
src="https://github.com/user-attachments/assets/157db6fd-ec4c-4c96-b44a-119273cbd0f9"
/> |
Release Notes:
- Added the ability to control codeblock content wrapping through the
UI.
Closes AI-230
This PR makes skills, added as /-mentions, be rendered in the agent
panel as creases, like anything you'd @-mention. Naturally, clicking on
the crease button opens the corresponding skill file in a buffer.
It turned out to be quite a bit of plumbing to make this work,
particularly as I am also introducing an interface to display dividers
and headers in the completion menu. This was relevant to me to add
because it sets a good foundation to convert many agent panel-related
actions as slash commands.
Release Notes:
- N/A
---------
Co-authored-by: MartinYe1234 <52641447+MartinYe1234@users.noreply.github.com>
## Summary
Fix completion ordering when two items are otherwise tied and only
differ by letter case.
In cases like `abc` vs `ABC`, if the user types `a`, Zed should prefer
`abc`. If the user types `A`, Zed should prefer `ABC`. This matches the
expectation described in #37081 and #27993, where `subscription` should
rank above `Subscription` for query `s`.
## What changed
In `CompletionsMenu::sort_string_matches`, I added a tie-breaker that
prefers completions with more exact case-sensitive matches at the
fuzzy-match positions.
This only applies after the existing higher-priority sort keys, so it
does not replace fuzzy score, match positions, snippet ordering, or LSP
`sortText`. It only resolves ambiguous ties more intuitively.
## Tests
Added regression coverage in `code_completion_tests` for abstract
case-only examples:
- `a` prefers `abc` over `ABC`
- `A` prefers `ABC` over `abc`
- `ab` prefers `abc` over `ABC`
- `AB` prefers `ABC` over `abc`
- mixed-case multi-letter queries like `Ab` and `aB`
## Verification
Ran:
```bash
cargo test -p editor code_completion_tests
```
PS: all code and description is generated by Codex
Release Notes:
- Fixed completions not tie braking by case
TODO:
- [x] merge main
- [x] nonshrinking `set_excerpts_for_path`
- [x] Test-drive potential problem areas in the app
- [x] prepare cloud side
- [x] test collaboration
- [ ] docstrings
- [ ] ???
## Context
### Background
Currently, a multibuffer consists of an arbitrary list of
anchor-delimited excerpts from individual buffers. Excerpt ranges for a
fixed buffer are permitted to overlap, and can appear in any order in
the multibuffer, possibly separated by excerpts from other buffers.
However, in practice all code that constructs multibuffers does so using
the APIs defined in the `path_key` submodule of the `multi_buffer` crate
(`set_excerpts_for_path` etc.) If you only use these APIs, the resulting
multibuffer will maintain the following invariants:
- All excerpts for the same buffer appear contiguously in the
multibuffer
- Excerpts for the same buffer cannot overlap
- Excerpts for the same buffer appear in order
- The placement of the excerpts for a specific buffer in the multibuffer
are determined by the `PathKey` passed to `set_excerpts_for_path`. There
is exactly one `PathKey` per buffer in the multibuffer
### Purpose of this PR
This PR changes the multibuffer so that the invariants maintained by the
`path_key` APIs *always* hold. It's no longer possible to construct a
multibuffer with overlapping excerpts, etc. The APIs that permitted
this, like `insert_excerpts_with_ids_after`, have been removed in favor
of the `path_key` suite.
The main upshot of this is that given a `text::Anchor` and a
multibuffer, it's possible to efficiently figure out the unique excerpt
that includes that anchor, if any:
```
impl MultiBufferSnapshot {
fn buffer_anchor_to_anchor(&self, anchor: text::Anchor) -> Option<multi_buffer::Anchor>;
}
```
And in the other direction, given a `multi_buffer::Anchor`, we can look
at its `text::Anchor` to locate the excerpt that contains it. That means
we don't need an `ExcerptId` to create or resolve
`multi_buffer::Anchor`, and in fact we can delete `ExcerptId` entirely,
so that excerpts no longer have any identity outside their
`Range<text::Anchor>`.
There are a large number of changes to `editor` and other downstream
crates as a result of removing `ExcerptId` and multibuffer APIs that
assumed it.
### Other changes
There are some other improvements that are not immediate consequences of
that big change, but helped make it smoother. Notably:
- The `buffer_id` field of `text::Anchor` is no longer optional.
`text::Anchor::{MIN, MAX}` have been removed in favor of
`min_for_buffer`, etc.
- `multi_buffer::Anchor` is now a three-variant enum (inlined slightly):
```
enum Anchor {
Min,
Excerpt {
text_anchor: text::Anchor,
path_key_index: PathKeyIndex,
diff_base_anchor: Option<text::Anchor>,
},
Max,
}
```
That means it's no longer possible to unconditionally access the
`text_anchor` field, which is good because most of the places that were
doing that were buggy for min/max! Instead, we have a new API that
correctly resolves min/max to the start of the first excerpt or the end
of the last excerpt:
```
impl MultiBufferSnapshot {
fn anchor_to_buffer_anchor(&self, anchor: multi_buffer::Anchor) -> Option<text::Anchor>;
}
```
- `MultiBufferExcerpt` has been removed in favor of a new
`map_excerpt_ranges` API directly on `MultiBufferSnapshot`.
## Self-Review Checklist
<!-- Check before requesting review: -->
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Jakub Konka <kubkon@jakubkonka.com>
Co-authored-by: Conrad <conrad@zed.dev>
- **Remove some of the settings types from ui**
- **drag settings-less ui across the line**
Self-Review Checklist:
- [ ] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- N/A
---------
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
This PR is an additive change introducing the `truncate_start` method to
labels, which gives us the ability to add an ellipsis at the beginning
of the text as opposed to the regular `truncate`. This will be generally
used for truncating file paths, where the end is typically more relevant
than the beginning, but given it's a general method, there's the
possibility to be used anywhere else, too.
<img width="500" height="690" alt="Screenshot 2025-12-17 at 12 35@2x"
src="https://github.com/user-attachments/assets/f853f5a3-60b3-4380-a11c-bb47868a4470"
/>
Release Notes:
- N/A
---------
Co-authored-by: Lukas Wirth <lukas@zed.dev>
Closes#43355
Fixes the issue were code actions with long labels would get cut off
without being able to see the full description. We now properly truncate
those labels with an ellipsis and show the full description in an aside.
Release Notes:
- Added ellipsis to truncated code actions and an aside showing the full
action description.
Only by reusing the previous scroll handle, we can ensure that both the
scrollbar remains usable and also that the scrollbar does not flicker.
Previously, the scrollbar would hold the reference to an outdated
handle.
I tried invalidating the handle the scrollbar uses, but that leads to
flickering, which is worse. Hence, let's just reuse the scrollbar here.
Release Notes:
- Fixed an issue where the scrollbar would become stale in the code
completions menu after the items were updated.
At some point, rust-analyzer started including the snippet expression
for some completions in the description field, but that can look like a
bug:
<img width="1570" height="578" alt="CleanShot 2025-11-27 at 20 39 49@2x"
src="https://github.com/user-attachments/assets/5a87c9fe-c0a8-472f-8d83-3bc9e9e00bbc"></img>
In these cases, we will now inline the tab stops as an ellipsis
character:
<img width="1544" height="428" alt="CleanShot 2025-12-01 at 10 01 18@2x"
src="https://github.com/user-attachments/assets/4c550891-4545-47cd-a295-a5eb07e78e92"></img>
You may also notice that we now syntax highlight the pattern closer to
what it looks like after accepted.
Alternatively, when the tab stop isn't just one position, it gets
highlighted as a selection since that's what it would do when accepted:
<img width="1558" height="314" alt="CleanShot 2025-12-01 at 10 04 37@2x"
src="https://github.com/user-attachments/assets/ce630ab2-da22-4072-a996-7b71ba21637d"
/>
Release Notes:
- rust: Display completion tab stops inline rather than as a raw LSP
snippet expression
This PR introduces `Nearest` scrolling strategy to `UniformList`. This
is now used in completions menu and the picker to choose the appropriate
scrolling strategy depending on movement direction. Previously,
selecting the next element after the last visible item caused the menu
to scroll with `ScrollStrategy::Top`, which scrolled the whole page and
placed the next element at the top. This behavior is inconsistent,
because using `ScrollStrategy::Top` when moving up only scrolls one
element, not the whole page.
https://github.com/user-attachments/assets/ccfb238f-8f76-4a18-a18d-bbcb63340c5a
The solution is to introduce the `Nearest` scrolling strategy which will
internally choose the scrolling strategy depending on whether the new
selected item is below or above currently visible items. This ensures a
single-item scroll regardless of movement direction.
https://github.com/user-attachments/assets/8502efb8-e2c0-4ab1-bd8d-93103841a9c4
I also noticed that some functions in the file have different logic
depending on `y_flipped`. This appears related to reversing the order of
elements in the list when the completion menu appears above the cursor.
This was a feature suggested in #11200 and implemented in #23446. It
looks like this feature was reverted in #27765 and there currently seem
to be no way to have `y_flipped` to be set to `true`.
My understanding is that the opposite scroll strategy should be used if
`y_flipped`, but since there is no way to enable this feature to test it
and I don't know if the feature is ever going to be reintroduced I
decided not to include it in this PR.
Release Notes:
- gpui: Add 'Nearest' scrolling strategy to 'UniformList'
A user on Discord requested this feature:
https://discord.com/channels/869392257814519848/1434188637389717556/1434188637389717556
I added a scrollbar setting called `completion_menu_scrollbar` to the
completion menu and defaulted it to "Never" to match past behavior.
Release Notes:
- editor: Add `editor.completion_menu_scrollbar` setting to show a
scrollbar in the completion menu
Co-Authored-By: Ben K <ben@zed.dev>
Co-Authored-By: Anthony <anthony@zed.dev>
Co-Authored-By: Mikayla <mikayla@zed.dev>
Release Notes:
- settings: Major internal changes to settings. The primary user-facing
effect is that some settings which did not make sense in project
settings files are no-longer read from there. (For example the inline
blame settings)
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Co-authored-by: Anthony <anthony@zed.dev>
Follow up to https://github.com/zed-industries/zed/pull/37824, which
made items be cut-off in the _editor_ instance of the code actions menu.
This PR applies the default UI font size for the code action menu items
only when the origin is the quick actions bar.
Release Notes:
- Fix code actions menu items being cut-off in the editor.
Follow-up of https://github.com/zed-industries/zed/pull/37352
Closes https://github.com/zed-industries/zed/issues/37132
* disabled word completions in the agent panel's editor
* if not disabled, allow to trigger word completions with an action even
if the completions threshold is not reached
Release Notes:
- Fixed word completions appearing in the agent panel's editor and not
appearing when triggered with the action before the completion threshold
is reached
Follow up to https://github.com/zed-industries/zed/pull/30598
This PR introduces the `display_options` field in the
`CompletionResponse`, allowing a code context menu width to be
dynamically dictated based on its larger item. This will allow us to
have the @-mentions and slash commands completion menus in the agent
panel not be bigger than it needs to be. It may also be relevant/useful
in the future for other use cases.
For now, we set all instances of code context menus to use a fixed
width, as defined in the PR linked above, which means this PR shouldn't
cause any visual change.
Release Notes:
- N/A
Co-authored-by: Michael Sloan <mgsloan+github@gmail.com>
Add support for scrolling the contents rendered aside an
`editor::code_context_menus::CodeContextMenu` by introducing the
`scroll_aside` method.
For now this method is only implemented for the
`CodeContextMenu::Completions` variant, which will scroll the aside
contents for an `editor::code_context_menus::CompletionsMenu` element,
as a `ScrollHandle` is added to the aside content that is rendered.
In order to be possible to trigger this via keybindings, a new editor
action is introduced, `ContextMenuScrollAside`, which accepts a number
of lines or pages to scroll the content by.
Lastly, the default keymaps for both MacOS and Linux, as well as for
Zed's vim mode, are updated to ensure that the following keybindings are
supported when a completion menu is open and the completion item's
documentation is rendered aside:
- `ctrl-e`
- `ctrl-y`
- `ctrl-d`
- `ctrl-u`
### Recording
https://github.com/user-attachments/assets/02043763-87ea-46f5-9768-00e907127b69
---
Closes#13194
Release Notes:
- Added support for scrolling the documentation panel shown alongside
the completion menu in the editor with `cltr-d`, `ctrl-u`, `ctrl-e` and
`ctrl-y`
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: MrSubidubi <finn@zed.dev>
This removes around 900 unnecessary clones, ranging from cloning a few
ints all the way to large data structures and images.
A lot of these were fixed using `cargo clippy --fix --workspace
--all-targets`, however it often breaks other lints and needs to be run
again. This was then followed up with some manual fixing.
I understand this is a large diff, but all the changes are pretty
trivial. Rust is doing some heavy lifting here for us. Once I get it up
to speed with main, I'd appreciate this getting merged rather sooner
than later.
Release Notes:
- N/A
Closes#34338
After https://github.com/zed-industries/zed/pull/31872, to avoid
re-querying language servers, we keep the context menu around, which
stores initial query, completions items, etc., even though it may not
contain any items and hence not be rendered on screen. In this state,
up/down arrows try to switch focus in the context menu instead of
propagating it to the editor. Hence blocking buffer movement.
This PR fixes it by changing the context for `menu`,
`showing_completions`, and `showing_code_actions` to only be added when
the menu is actually being rendered (i.e., not empty).
Release Notes:
- Fix an issue where the cursor doesn’t move up and down on arrow keys
when no completions are shown.
This mirrors VSCode setting that inspired `snippet_sort_order` to begin
with; VSCode supports inline/top/bottom/none, with none completely
disabling snippet completion. See
https://code.visualstudio.com/docs/editing/intellisense#_snippets-in-suggestions
This is helpful for LSPs that do not allow configuring snippets via
configuration such as clangd.
Release Notes:
- Added `none` as one of the values for `snippet_sort_order` to
completely disable snippet completion.
Partially fixes:
https://github.com/zed-industries/zed/discussions/33777#discussioncomment-13646294
### Improves debug console autocompletion behavior
This PR fixes a regression in completion trigger support for the debug
console, as we only looked if a completion trigger, was in the beginning
of the search text, but we also had to check if the current text is a
word so we also show completions for variables/input that doesn't start
with any of the completion triggers.
We now also leverage DAP provided information to sort completion items
more effectively. This results in improved prioritization, showing
variable completions above classes and global scope types.
I also added for completion the documentation field, that directly comes
from the DAP server. NOTE: I haven't found an adapter that returns this,
but it needs to have.
**Before**
<img width="1200" alt="Screenshot 2025-07-03 at 21 00 19"
src="https://github.com/user-attachments/assets/611e8d38-e302-4995-a425-ce2c0a1843d4"
/>
**After**
<img width="1200" alt="Screenshot 2025-07-03 at 20 59 38"
src="https://github.com/user-attachments/assets/ab1312db-bbad-49b7-872d-712d6ec708d7"
/>
Release Notes:
- Debugger: Improve autocompletion sorting for debug console
- Debugger: Fix autocompletion menu now shown when you type
- Debugger: Fix completion item showing up twice for some adapters
Closes#33106
Instead of directly using `filter_text` in `StringMatchCandidate`, which
yields better results for fuzzy matching but messes up with highlighting
letters in bold, as `positions` list generated by fuzzy crate are now of
`filter_text` and not `label` shown to the user.
This PR fixes it by keeping use of `filter_range` in
`StringMatchCandidate`, which is range w.r.t to `label` shown to user.
And actually generating this `filter_range` at source by using
`filter_range` if exists.
- [x] Tests
Release Notes:
- Fixed issue where incorrect letters are marked as bold in completions.
Xin Zhao