Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can we show the file path in search results without splitting them? #43445

Closed
seanpoulter opened this issue Feb 11, 2018 · 12 comments
Closed

Can we show the file path in search results without splitting them? #43445

seanpoulter opened this issue Feb 11, 2018 · 12 comments
Assignees
Labels
feature-request Request for new features or functionality *out-of-scope Posted issue is not in scope of VS Code search Search widget and operation issues

Comments

@seanpoulter
Copy link
Contributor

  • VSCode Version: 1.19.3
  • OS Version: Any

Steps to Reproduce:

  1. Search in files

Does this issue occur when all extensions are disabled?: Yes


As a developer searching in a large project, I would like to see the path not split in search results. For example, I would like following search result to read src/containers/root/index.js. I propose we add an option to configure the search results to show the relative path called "search.showRelativePath".

image

This bothers me enough I'll have a go at a PR in the next release cycle if someone's got the bandwidth to review it. Do we need anything else to scope this out? Can anyone familiar with the repo suggest a file or two to start looking at?


/cc @sandy081 - Saw you were assigned other search-related issues 😉

@vscodebot vscodebot bot added the search Search widget and operation issues label Feb 11, 2018
@roblourens
Copy link
Member

Will pass this to you for now @isidorn because I think you're looking at search UI this iteration.

@roblourens roblourens assigned isidorn and unassigned roblourens Feb 12, 2018
@isidorn
Copy link
Contributor

isidorn commented Feb 12, 2018

@roblourens this iteration I am looking into moving the whole search viewlet into the panel. I do not plan to change the UX insider search.
I do not mind owning search ux, but then we need to plan for this. For now assigning back to you

@isidorn isidorn assigned roblourens and unassigned isidorn Feb 12, 2018
@roblourens
Copy link
Member

This format matches other file path labels - on editor tabs, in quickopen, in problems view, etc. I would only change it for the search viewlet as part of a larger UI change. Personally I prefer the current approach but I can see that others might like showing the path as one label without splitting. Have you ever considered that @bpasero?

@seanpoulter
Copy link
Contributor Author

I wouldn't want to change the editor tabs, but I can see the intent of the request carrying over to other UI like the problems. I'm not fond of the a UX that forces my focus to shift all over when I'm trying to quickly skip over files in some folders I don't care about.

@bpasero
Copy link
Member

bpasero commented Feb 13, 2018

@roblourens no, but I am not sure changing it everywhere makes sense, maybe it needs a setting for search specifically. The widget we use to render the labels is called IconLabel.

@roblourens
Copy link
Member

Why specifically for search? I think file labels should be shown in a consistent way everywhere. They are playing the same role everywhere they show up.

@seanpoulter
Copy link
Contributor Author

seanpoulter commented Feb 13, 2018

Most of the time you get context from the filename or partial path, but every now and then when you open up a bigger JavaScript repo the majority of your search results can be index.js. 😭

@patrys
Copy link

patrys commented Feb 15, 2018

I'm quite happy with how search works currently but would love a button that would display the results in a tree view similar to the file explorer. This way I could fold away entire folders instead of constantly fiddling with exclude patterns.

@roblourens roblourens added the under-discussion Issue is under discussion for relevance, priority, approach label Feb 15, 2018
@roblourens
Copy link
Member

@patrys #20224

@seanpoulter
Copy link
Contributor Author

That would also solve my problem @roblourens. 👍

@roblourens roblourens added feature-request Request for new features or functionality and removed under-discussion Issue is under discussion for relevance, priority, approach labels Sep 12, 2018
@roblourens roblourens added the *out-of-scope Posted issue is not in scope of VS Code label Sep 22, 2018
@vscodebot
Copy link

vscodebot bot commented Sep 22, 2018

This iteration we focus on issue grooming. This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that are not going to be addressed in the foreseeable future: We look at the number of votes the issue has received and the number of duplicate issues filed. More details here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!

@vscodebot vscodebot bot closed this as completed Sep 22, 2018
@roblourens
Copy link
Member

Things like this are maybe better covered in #20224?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Request for new features or functionality *out-of-scope Posted issue is not in scope of VS Code search Search widget and operation issues
Projects
None yet
Development

No branches or pull requests

5 participants