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

Cannot distinguish different files with the same path.filename(x) #8499

Closed
alexdima opened this issue Jun 29, 2016 · 29 comments
Closed

Cannot distinguish different files with the same path.filename(x) #8499

alexdima opened this issue Jun 29, 2016 · 29 comments
Assignees
Labels
bug Issue identified by VS Code Team member as probable bug ux User experience issues verified Verification succeeded workbench-tabs VS Code editor tab issues
Milestone

Comments

@alexdima
Copy link
Member

Testing #7854

image

@alexdima
Copy link
Member Author

I had both the user settings and the workspace settings ...

@alexdima alexdima changed the title Cannot distinguish different files with the sane path.filename(x) Cannot distinguish different files with the same path.filename(x) Jun 29, 2016
@bpasero bpasero added ux User experience issues workbench-tabs VS Code editor tab issues labels Jun 29, 2016
@bpasero bpasero assigned stevencl and bgashler1 and unassigned bpasero Jun 29, 2016
@bpasero
Copy link
Member

bpasero commented Jun 29, 2016

Interesting what ST does in this case:

image

@bgashler1
Copy link
Contributor

bgashler1 commented Jun 29, 2016

As originally designed, we did something very similar: whenever something is opened that is not in the root of the folder, then we show it's parent folder below the file name in smaller text.

tabs-01c

Some things to note... If we want to go with this approach, then we need to use something other than the italic font (this was before we decided to use italic font on preview tabs). What we could do is a less pronounced color. Combined with the smaller font size, I think that may work. I can work on some variations of this if we go down this route.

@stevencl
Copy link
Member

stevencl commented Jul 4, 2016

If we showed the path to the file in the status bar would this resolve this issue?

Is there enough horizontal and vertical space in the tab to be able to show the path to the file?

@bpasero bpasero added this to the August 2016 milestone Jul 13, 2016
@bpasero bpasero self-assigned this Jul 13, 2016
@bpasero
Copy link
Member

bpasero commented Jul 13, 2016

We should talk about this when I am back from vacation, a user posted a PR that does the simple thing: Just add the path of the file to the tab if another tab has the same name.

@ecraig12345
Copy link
Member

What about showing the path to the file in the window title like ST does? Often I would like to see the full path (for various reasons) even when I don't have multiple files by the same name open. (Since this is a slightly different issue, I can open a separate issue report if that seems more appropriate.)

@bpasero
Copy link
Member

bpasero commented Jul 15, 2016

Please use the search feature before filing new issues:

image

@ecraig12345
Copy link
Member

@bpasero If the request to use the search feature was directed at me, I did that already and didn't find anything... My question was whether the idea merits a separate issue (since it's one potential solution to this issue), not whether an issue has already been opened for it.

@ligaz
Copy link

ligaz commented Jul 15, 2016

I would personally vote for something similar to what Sublime is doing. It is smart about it and if the parent folders have the same name it prepends their parent names and so on.

@bpasero
Copy link
Member

bpasero commented Jul 15, 2016

@ligaz yes I like that too.

@ecraig12345 #1723 (you owe me 2 minutes of my morning)

@bpasero
Copy link
Member

bpasero commented Jul 15, 2016

Also related: #3119

@bpasero bpasero removed their assignment Aug 8, 2016
@bpasero
Copy link
Member

bpasero commented Aug 8, 2016

I think this needs some design work first. Assign to me once we made a decision please. I am not sure we plan this for August.

@stevencl
Copy link
Member

stevencl commented Aug 9, 2016

Will discuss again tomorrow. I forgot to add notes from our discussion last week. We agreed that we should show the name of the parent folder whenever there are two files opened with the same name.

@rmunn
Copy link
Contributor

rmunn commented Aug 11, 2016

This is especially needed when working on Ansible scripts: I have a whole folder tree full of files with names like role1/defaults/main.yml, role1/handlers/main.yml, role1/tasks/main.yml, role2/defaults/main.yml, role2/handlers/main.yml, role2/tasks/main.yml, and so on for about a dozen different roles. It's tedious to hover over each tab trying to find out which main.yml it is.

@bpasero bpasero added the bug Issue identified by VS Code Team member as probable bug label Aug 12, 2016
@bpasero
Copy link
Member

bpasero commented Aug 12, 2016

@stevencl @bgashler1 I pushed this with some changes to our initial discussions.

First of all this is how it looks:

screen shot 2016-08-12 at 11 50 02

For one, I decided to use the same UI for showing the path that we already have when disabling tabs: That is, smaller font, some margin and a different color so that the file name is still standing out strong.

And then I am always showing the full path of the file and not just its parent for several reasons:

  • this is consistent with our non-tabs UI and any other place throughout the UI where we show paths
  • this will work for any editor opened and not just files (we could have name collisions also for other editor types and making it specific to files is bad)
  • this helps the user to see the full context of a file because I argue that the parent folder might not be enough to understand where the file is coming from (e.g. in the case of Alex the parent folders are "code" and ".vscode"

@ligaz
Copy link

ligaz commented Aug 12, 2016

Is there a reason to show the full path instead of just the difference as Sublime does it? Showing the full path will widen the tab which might be good for users with 13' displays.

@jhofker
Copy link

jhofker commented Aug 12, 2016

+1 to "just the difference" -- I was starting to write an extension before I found this issue to help solve this type of thing:
image

I don't need the full path, I just need to know the name of the folder it's in, as they're all just React components. If this had an extension api I'd probably keep going with what I was doing, but I can't seem to find it.

@bpasero
Copy link
Member

bpasero commented Aug 13, 2016

I had a longer discussion with @stevencl on this and maybe we can discuss it here so that more people can chime in. If we decide to only show the parent name of the folder, things are maybe OK and expected, but what happens if the parent names are also identical? You start going up one level so you might have a description of "foo/bar" and "some/bar" next to the file name. Would that not draw the impression that the file is within a folder "foo/bar"?

I think to solve that confusion, at the very minimum we should show the last portion of the folder with a leading "../" so that people understand, the folder is not the absolute path to the file.

@jhofker
Copy link

jhofker commented Aug 15, 2016

@bpasero -- personally I'd be down with that. My goal is to be able to distinguish identically-named files from each other in as little space as is required to do it.

If I open foo/bar/index.js and cat/bar/index.js, seeing index.js | foo/.. and index.js | cat/.. as tabs would work well for my needs.

Also, I think this is similar to #8501 (just so they get linked up)

bpasero added a commit that referenced this issue Aug 15, 2016
@bpasero bpasero added the verification-needed Verification of issue is requested label Aug 15, 2016
@bpasero
Copy link
Member

bpasero commented Aug 15, 2016

I pushed a change to show the name of the folder to distinguish tabs with the same file name but I am falling back to showing the full path as soon as the parent folder is also identical. I think that is a good solution.

@stevencl fyi, this solution is closer to what you suggested in the first place.

@jhofker
Copy link

jhofker commented Aug 15, 2016

Good stuff!
image

But multiple files in one folder matching multiple files in another gets hairy:
image

@bpasero
Copy link
Member

bpasero commented Aug 15, 2016

@jhofker yeah, nice finding, and I saw this today this morning and pushed a fix after our nightly was already running.

The really only situation you should ever see a full path (that is: workspace relative if the file is from an opened folder) in a tab is when both files have the same parent folder. But that seems to be happening in ST as well:

image

@jhofker
Copy link

jhofker commented Aug 18, 2016

@bpasero just updated to last night's build and this is working great. Thank you!

@steve-ross
Copy link

Know this is closed (and working fine) however, is there a way to force setting to always on? Would be useful if i have the editor split so I can tell the following apart easily:

screen shot 2016-11-01 at 8 54 53 am

@bpasero
Copy link
Member

bpasero commented Nov 1, 2016

#13350

@peabnuts123
Copy link

+1 for a setting to force this always on, but for a different use-case than @steve-ross. Working in a project that has many of the same filenames (e.g. Ember, where filenames are relatively semantic, or many NodeJS apps where index.js has an important role) produces strong usability issues as you often don't need to edit two files with the same name at the same time, but may lose track of which file you have open. It would, personally, make my life a lot easier if I could set a minimum value for tab path (i.e. always show at least the parent folder name, or more if you have multiple instances open) or perhaps a setting similar to window.title wherein you could supply a magic string for tab title and subtitles. I find in Ember especially (where I have many different application.js files and forms and routes with the same name) I have to hover over the tab to see the full path quite often.

@steve-ross
Copy link

@peabnuts123 same use case :) as in my screen shot (react / redux app) maybe that approach makes more sense. Guess we should really dig in and see if we could contribute. Special thanks to all you open source contributors. Don't let our "complaints" & feature requests diminish the fact that you all kick ass for bringing us tools.

@davidacreates
Copy link

+1 i am working on a react/redux app and would love an always on option as @steve-ross mentioned.

@matthewrbrooks
Copy link

matthewrbrooks commented Jun 16, 2017

Another +1 for exactly the same reasons as @orangemooncreative @steve-ross ...

And another +1 for 'it's a great tool'!

I'm not github-by enough to know whether we should / can file this as a feature request?

@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 18, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Issue identified by VS Code Team member as probable bug ux User experience issues verified Verification succeeded workbench-tabs VS Code editor tab issues
Projects
None yet
Development

Successfully merging a pull request may close this issue.