Display buffer/project search entries in the outline panel

[SomeoneToIgnore]

Prototypes a way to display new entities in the outline panel, making it less outline. The design is not final and might be adjusted, but the workflow seems to be solid enough to keep and iron it out.

• Now, when any project search buffer is activated (multi buffer mode), or buffer search is open (singleton buffer mode, but is available for search usages multi buffer too — in that case buffer search overrides multi buffer's contents display), outline panel displays all search matches instead of the outline items.

Outline items are not displayed at all during those cases, unless the buffer search is closed, or a new buffer gets opened, of an active buffer search matches zero items.

https://github.com/user-attachments/assets/4a3e4faa-7f75-4522-96bb-3761872c753a

• For the multi buffer mode, search matches are grouped under directories and files, same as outline items

• For buffer search , search matches are displayed one under another

For both cases, the entire match line is taken and rendered, with the hover tooltip showing the line number. So far it does not look very bad, but I am certain there are bad cases with long lines and bad indents where it looks not optimal — this part most probably will be redesigned after some trial. Or, maybe, it's ok to leave the current state if the horizontal scrollbar is added?

Clicking the item navigates to the item's position in the editor. Search item lines are also possible to filter with the outline panel's filter input.

• Inline panel is now possible to "pin" to track a currently active editor, to display outlines/search results for that editor even if another item is activated afterwards:

This is useful in combination with project search results display: now it's possible to leave the search results pinned in the outline panel and jump to every search result and back.

If the item the panel was pinned to gets closed, the panel gets back to its regular state, showing outlines/search results for a currently active editor.

Release Notes:

• Added a way to display buffer/project search entries in the outline panel

[baldwindavid]

@SomeoneToIgnore - 🥳 Already this is something I will make use of even without changes. You mention some of this already, but a few notes:

• The most noticeable thing is the indentation of results. I do think that at least each result should be left aligned. As it is the results are all over the place. I mentioned here how VSCode does it. If it's easier, I wonder if an early pass might be to left align at the first non-whitespace character.
• Maybe I need to update my keymap, but mostly only clicking on a result seemed to open it, rather than keyboard-driven.
• I don't think I understand what those line numbers represent when hovering over a result. They seem to be an "order" or something more than the actual line number of the result within a file. But, even then, I'm seeing some gaps in that count so I'm not sure what it's doing.

Regardless, these things can come in later. Thanks!

[SomeoneToIgnore]

Thank you for the testing,

The most noticeable thing is the indentation of results. I do think that at least each result should be left aligned. As it is the results are all over the place. I mentioned https://github.com/zed-industries/zed/pull/13034#issuecomment-2168453430 how VSCode does it. If it's easier, I wonder if an early pass might be to left align at the first non-whitespace character.

Do you have any extra ugly examples to share? What if we trimmed just the trailing whitespaces on the left (leaving the matches in the middle of the line still shifted) and/or allowed to scroll horizontally?

I am not certain what to do here entirely: I sort of dislike ... and a mixture of those as :

...foo
foo
...foo
foo
foo

and love how outline panel tries to show "real code" inside of it now. I agree that it's questionable, and asked a better designer than me to check on things when he has time.

Maybe I need to update my keymap, but mostly only clicking on a result seemed to open it, rather than keyboard-driven.

Outline panel currently tries to mimic project panel and its way of dealing with things, and there, multiple selections are allowed, and project_panel::Open (space on mac) is used to actually open the files. Same outline_panel::Open (same space) exists in the outline panel, so it should be possible to navigate via keyboard only in the panel.

One large issue is that input field steals the focus and does not provide a way to move it away. I have to change things around that, but if you click once into the outline panel once, you would be able to press space and open the files. Thank you for the catch, I definitely should rework it to be keyboard-friendly.

what those line numbers represent

Supposed to be line number, I'll recheck again, thank you. Overall, is there any use of those numbers? I am somewhat sceptical on how flashy those pop-ups are and wondering whether I should remove the whole tooltip entirely.

[baldwindavid]

and love how outline panel tries to show "real code" inside of it now.

I think I understand this perspective now in wanting to actually see the indentation level of each result. I can appreciate how this might be an interesting way to look at the results to see them in their natural alignment. This is effectively still looking at this as somewhat of an outline. However, for me, once the "in between" code is removed from the results, the outline/indentation is just no longer something I can make much sense of and just looks kind of random and cluttered. It's hard to skim and immediately see the directories and file names because indentation is all over the place.

I would say I'm mostly looking at this from a multi-buffer search scenario as opposed to a single file scenario. That indentation would be much easier for me to understand if I'm only looking at one file. At the same time, that's also the scenario where I'm less likely to open the panel in the first place. Not to say it won't be useful there; just that the main issue this solves for me is project search results.

What if we trimmed just the trailing whitespaces on the left (leaving the matches in the middle of the line still shifted) and/or allowed to scroll horizontally?

Yeah, trimming the whitespace on the left is what I had mentioned and might be a good first pass (especially if easier). At the same time, I suspect this will eventually end up at a place where the actual result is visible without side-scrolling, especially if there is some sort of "live replace" of text. I'm a vim and former vscode user though, so that has undoubtedly colored my view on usage/interaction with this sort of thing.

One large issue is that input field steals the focus and does not provide a way to move it away.

Yeah, poked around a bit more and that's definitely what I was running into.

Overall, is there any use of those numbers?

I can tell you that I won't use them, but I can't speak for others that like to hover/click things. :)

[SomeoneToIgnore]

Thank you for the feedback, I am now fully in favor of removing the indentation in the project search results too. I have left them for singleton buffers still, let's see if that holds.

Besides, more improvements were added on top:

• keyboard navigation is more sane now, automatically focusing the search input on panel focus; focusing panel items on any action (change or toggle items). Then, space could be used to Open the items, also there's Open { change_selection: true } action with no default binding that works on double click and not only scrolls to the items' positions in the corresponding editor, but moves the focus and places the caret there

• search mode shows a search query above now, and has no flashing pop-ups anymore (making line information not available currently, we'll see how it works)

• less work is done when the outline panel is not visible and debounce the caret position reveal actions, to reduce performance impact and selection flickering

Overall, I feel that this iteration is ready to be merged and further style improvements could be landed on top. Besides, general outline panel implementation seems to be relatively complete for the time being: further large improvements on top seem to be needed after MultiBuffer rework and further git work based on top of that.

[baldwindavid]

Awesome work! Thanks for adding; very slick.