Vscode: Cannot distinguish different files with the same path.filename(x)

[alexdima]

Testing #7854

[alexdima]

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

[bpasero]

Interesting what ST does in this case:

[bgashler1]

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.

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]

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]

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]

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]

Please use the search feature before filing new issues:

[ecraig12345]

@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]

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]

@ligaz yes I like that too.

@ecraig12345 https://github.com/Microsoft/vscode/issues/1723 (you owe me 2 minutes of my morning)

[bpasero]

Also related: https://github.com/Microsoft/vscode/issues/3119

[bpasero]

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]

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]

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]

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

First of all this is how it looks:

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]

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]

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

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]

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]

@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]

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]

Good stuff!

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

[bpasero]

@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:

[jhofker]

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

[steve-ross]

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:

[bpasero]

https://github.com/Microsoft/vscode/issues/13350

[peabnuts123]

+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]

@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.

[orangemooncreative]

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

[matthewrbrooks]

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?