Multi-file search results are very hard to skim and use

[ccinelli]

Intro

I have used Visual Studio Code as my main editor for about 1.5 years. I like everything of it except the format of the search results. Before that, mainly for this very reason, I used VSCode for few months but I ended up switching back to Atom as main editor.

Even if I am trying not to make this a VSCode vs Atom discussion, I think it is useful to compare and contrast. I still find myself going back to Atom when it comes to search across multiple files. I honestly tried not to. But more often than I wanted it, I had to do it.

#18326 was closed with "This feature request will not be considered in the next 6-12 months roadmap". It was Nov 20, 2017. I think it is time to talk about this again.

Compare pictures

Look at this picture:

Picture 1

On the left there is Atom. On the right there is Visual Studio Code.

Look also at this one:

Picture 2

What are the advantages?

What I like about VSCode search results is that by default, clicking on a result does not hide the search results. On Atom, the search result window is hidden by the opened file.
That is pretty much it.

What are the problems?

As the number of results increase, VSCode's results become more and more hard to skim.
I tried to order the specific problems in order of priority.

Not enough horizontal space

This is the root cause of some other problems. In general a full line of code does not fit the size of the search sidebar. Find one (or usually more) specific occurrences of the search term is a human process that needs context. Having a such narrow column limits a lot the context that can be rendered around the search term. There should be a way to take advantage of more screen real estate. [Edit: this was discussed in #23931 and fixed by #43833 - results in a tab is still not the default, though ]

File name first and path

When the path makes the difference, I cannot always see "enough" of the path before the .... I find myself to drag with the mouse the right side of search results sidebar to make it wider and then doing the opposite to make it smaller again.

You can see an example in Pic 2. In this case I want to find out which npm module contains the search term.

Another example is when you have a few files with the same name in the same repo. Somebody here decided that UI modules should have a index.js file. I may end up having 10+ index.js files in the results. If I am interested only in certain UI modules (that means only some folders), I cannot see the part of the path that makes a difference.

I also think that people are used to read the filename after the path. So switching them around add some cognitive overhead.

When the same term is in multiple places in the same line

Sometime I am interested only in specific patterns in a specific position in the line. It is usually not a problem to find them in Atom. But in Code it is very hard to read the results ( see Pic 1 ).
When I look at a log file is often the case.

Notice that sometimes the result is completely cut off in VSCode and only the ... is highlighted.

Lack of line numbers

Code does not have them.
For this reason, it is impossible for the user to understand where the pattern is inside the file.

A few times (if I have a stack trace for example) I want to both see all places where a function is called and I want to click on a specific result.

Other times I just need to know approximately where the pattern is in a file (beginning, middle, end). Line numbers help with this.

Not using a monospace font for the results

Not having monospaced code in the results make more difficult to scan the code. As far as I know this is the only time that code is shown with proportional characters in VSCode. Interesting I was able to find this as workaround: #5192 (comment)

Low contrast in the highlighted text in the results

This is minor, but I think a higher contrast can help to identify the term in the search results when you are scanning among tons of results. BTW, in #18326 it seems that the window's background used to be lighter and the current highlight color was fine with it. This is probably just a problem with some themes including the Default Dark+. Consider changing the highlight color or at least, let people customize the colors in the search results window. @wavebeem also pointed out that the path+filename on sublime is different from the code snippet. Having a different colors could also helps to visually break the result among different files. See also: #43283

Conclusion

I understand that the VSCode's UI is made to expand from left to right. I understand that some compromises had to be done to fit the search results in a narrow column. I suggest to reconsider how the search results are displayed. I would at least add the option to have a special "result window" that is bigger. I found #10121 that suggests adding support for floating windows that can help with that.

[ccinelli]

See also: #5192, #45665, #1833.

These people seemed to be interested in this kind of issues in the format of search results: @abenhamdine, @dakaraphi, @FibHeap, @AbraXus, @sheinzle, @leemhenson, @felixfbecker, @phase, @atombender, @Yukaii, @erickrawczyk, @H14, @swrobel, @usernamehw, @esutton, @myrdd, @jhasse, @karlhorky, and @suan
CCing them.

[atombender]

Agreed. File search is one of the weakest aspects of VSCode today.

I really prefer the way Sublime Text uses an editor tab for the search results. The sidebar is a bad UI because the results don't fit horizontally; the bottom panel is a bad UI because they don't fit vertically. Search results are code, just like editor tab.

Sublime Text actually uses an editor buffer to show search results, and it's not even read-only; you can edit the contents. Having it be an editor buffer has benefits, such as that you can copy all the search results (which can be handy; let's say you want to collect a bunch of symbol names in order to make a list of them for a switch statement or similar; with this, you can just search, copy the results, then turn the list into a bunch of case statements).

But when using Sublime, I always wished that the search result view was fully interactive. That is, that the matched lines were actually editable, and that the search results were a virtual view into the underlying result data. For example, let's say you have 10 hits in 5 different files. You'd have 10 lines, each being a view into those 5 files. You could edit those lines just like a normal editor, and all those 5 individual files would be updated in real time. This means you could use multiple cursors and all the other tools at your disposal to edit results.

[gjsjohnmurray]

Lack of line numbers

Code does not have them.

The search.showLineNumbers setting in my 1.29 seems to meet this need.

Not enough horizontal space

Have you tried setting search.location to "panel" rather than its default of "sidebar"?

[ccinelli]

Thanks for the suggestions @gjsjohnmurray. A little better.
I set search.location to panel. At the beginning I could not see the results! 😩
I thought it was not working. I was going to disable some extensions to make sure there were not conflicts:

But then I expanded vertically the panel and the results were there:

Now the code part of the screen is not big enough but I can adjust it. It is nice to have the line numbers... but why they are on the far right instead on the very first thing on the left?

I want to point out that in the search results the lines of code look very different compared to any other places in VSCode.

I think that @atombender 's suggestions are spot on. I understand that being able to edit in the result area is probably not so easy to implement, but using the same styles used in code panel should be relatively easy.

[ccinelli]

Regarding #5192 (comment) :
Custom CSS and JS Loader seems pretty hacky:

SPECIAL NOTE: If Code complains about that it is corrupted, simply click “Don't show again”.

NOTE: Every time after Code is updated, please re-enable Custom CSS.

NOTE: Every time you change the configuration, please re-enable Custom CSS.

...

Mac and Linux users

The extension would NOT if Code cannot modify itself. The cases include:

Code files being read-only, like on a read-only file system or,
Code is not started with the permissions to modify itself.
You need to claim ownership on Code's installation directory, by running this command:

sudo chown -R $(whoami) <Path to Code>

I think there are some security concerns to let people modify Code's JS and CSS.

Furthermore:

• Consider that Code's CSS and JS code is minimized, it is not super easy to play around it. Why are you minimizing it? The extra space saved on disk is negligible. The load time should not vary too much too.
• In order to chance the order of the items on the results line, I doubt that CSS is going to be enough. It is easy to add the monospace font, though.

In my humble opinion, it is a major readability improvement! Now if implement this by default, move the line number on the left and swap the path and filename, I would call this solved 😃

By the way, while I was working on this, I noticed another example of multiple file search in Chrome Dev Tools:

[ccinelli]

I see that the label under-discussion is described as "Issue is under discussion for relevance, priority, approach" What is the process and what is it waiting for? Are you waiting for input or people commenting on this discussion, going through some design iterations internally... Anything I or somebody else can do to help to move this forward?

[roblourens]

I left it open with that tag so interested people can keep commenting. I agree with many of your points. Some are covered by other open issues.

At some point I would like to allow search results in an editor. We have the proposed api findTextInFiles which would sort of allow an extension to implement this. But I'm not really convinced that an extension could provide a really good experience here, so I think it will have to be tackled in vscode itself at some point. You can 👍 this issue if you want: #23931

File name first and path

All "file labels" in vscode are formatted the same. I think that given the limited horizontal space we should keep the focus on the file name. Results in an editor would probably just include the path in order.

When the same term is in multiple places in the same line

Again, in the case of search in the sidebar, there isn't room for more than one result horizontally, but with result in a file, we could probably show them the same as Atom.

Not using a monospace font for the results

This has come up before, currently it's the same as code in Find All References. We actually changed these to a monospace font once, and the reaction was very mixed. Some people really hated mixing monospace code with non-monospace file paths. Or that since it's not colorized, it looked like there was a bug. So we are back here for now.

I think someone could probably do a PR for #43283 if that would help readability.

[ccinelli]

@roblourens - some thoughts:

Re: monospace and "Find All References - reaction was very mixed"

People do not usually like changes. If there are pros in the "old way" that are lost in the "new way", you are guaranteed to have complains. And complainers are usually louder than happy campers. So these reactions need to be kept in prospective and definitely not to listen to the louder person in the room and ignoring the others.
One way to mitigate a lot the complains is to provide a new default but having a way to use the old setting. Recognizing that the new way is better can take some time for some people. If the "new way" is really better, eventually most of the complainers switch and forget the "old way". You can always monitor how many people are using the old setting and you will know when the option can be deprecated and eventually eliminated. Google does that in all the main re-designs.

I understand there is an overhead cost if implementing a toggle and maintaining it at the feature level. Some companies (ex: Apple) do not do it and their product manages are ok to annoy people if they think their option is the best one (see new Apple laptop ports and lack of headphone jack in iPhone). Other companies listen more their customers (ex: Samsung's phone SD card's support).

I am not using a lot "Find All References" and I am not familiar with the mixed reactions.
A clear advantage or a proportional font vs a monospace is that the length of proportional text is shorter than with monospace. And it looks "prettier" (to some people). It looks like that in "Find All References" horizontal space is again lacking and you still have the whole code in monospace on the left. I would still prefer using monospace but I think in this case it is more a matter of "preference" than usability.

Re: Display search results in a tab instead of the side bar

#23931 seems to be already "solved" by setting search.location to "panel" rather than its default of "sidebar" as suggested above. I would challenge you to try to switch the defaults but I easily see this to have a lot of push back by people used to the result in the side bar.

I think the idea of an API, if flexible enough, is great. People can come with solutions that nobody though before and enable customization.

Re: "File name first and path"

What about having some options and maybe some way to customize it =)

[ccinelli]

Is this the the "mixed reaction"?

[roblourens]

That is definitely some of it. I remember more feedback either in other issues or offline.

[ccinelli]

That is all I got searching is:issue "Find All References" with monospace or font. It may be something offline because otherwise it seems a pretty mild reaction.

[roblourens]

My personal opinion is that a monospace font just looks wrong, like the result is trying to be an editor but doing a poor job of it. The mixing of fonts was always a bit jarring. I think it's not enough of an issue to add a setting for it - this is how we can end up with 100s of settings that almost nobody uses.

If this helps, our mental model for the search view is that it is not a good place to read your code and understand what the result is. It will never be good at that. It's just a list of the results. You can see that 5 results exist, then look at the actual code in the editor. The editor is good at displaying code, the search view is not.

I would challenge you to try to switch the defaults but I easily see this to have a lot of push back by people used to the result in the side bar.

Probably not going to do this. I don't like changing long-established defaults unless there is a really good reason.

[ccinelli]

Monospace

Premising that the monospace font was not the most important thing in my list, I definitely agree that a proportional font is not a biggy when you have only a small amount of code. Lack of a monospace font becomes a problem when there is too much text to process by your brain. Maybe your workflow does not require to do it?

Is it not enough thinking it as code should look like code? From a cognitive point of view it is pretty clear that we process better things in the format we usually interact with them.

It is normal that search results may need to be refined scanning them. And being able to reduce the effort to find what you are looking for is number one concern.

I do not think that is a coincidence that among all the other code editors that I know, VSS Code is the only code editor that uses a different no-monospaced font for search results. Even here on Github the search results are read only and they still use a monospace font.

I agree in trying to reduce the settings. It is hard to decide when you want to have a setting or not.
To reduce complains, above I suggested that when you modify a feature you can always add (1) a setting, (2) a metric and (3) a "plan" to deprecate and eliminate the old one eventually. Once it is part of the workflow it becomes easier.

I also think that "letting people add their CSS" is an easy fix to reduce the need of switches here.
I understand you think "CSS is a hidden implementation details" but I have noticed that a few other people requested it and it would be a quick fixes to more than a few issues reported here.

Letting people change the CSS, or at least making easier and more secure than with "Custom CSS and JS Loader" extension, could actually reduce the number of reported issues here.

Regarding switching the search.location default to panel, see #23931 (comment)

[roblourens]

You make good points and I appreciate the discussion but given what I've said above this just isn't something that I plan to change right now.

I also think that "letting people add their CSS" is an easy fix to reduce the need of switches here.

That would help but we are definitely not planning on changing that 😁 It has been discussed many times before and I think it would cause more problems than it solves.

I'm going to close this now, if there are any other specific requests to follow up on, feel free to open new more specific issues.