[wingide-users] Tiny feature request

[Martin Frankel]

Your original complaint was that you edited the wrong file of many with 
the same name. The full file path is in the window title bar. You don't 
have to touch your mouse or wait for any tool tip to know what file 
you're working on.

Now you're talking about selecting which tab to click on to edit one of 
many files with the same name. You claim that "anything is better than 
the current solution." So let's examine that assertion.

1) Any solution which increases the size of the tabs in the common case 
in order to give a small benefit in the uncommon case is a terrible 
design tradeoff. This includes non-adaptive paths of any sort in the 
tab. I think we agree on this.
2) The number provides a mnemonic that is better than nothing, and far 
more compact than a full path. It costs nothing in the common case where 
files have descriptive names. It costs very little in the uncommon case, 
just a few characters in the tab. Users often remember the sequence in 
which files were opened, so this has good mnemonic value for just a few 
characters. I find this the correct tradeoff as do (for example) the 
authors and users of Emacs over the 20 year history of that editor.
3) For those who don't like remembering numbers, the tooltips work fine 
as a reminder. Since you're using the mouse to click on the tab anyway, 
you've already spent the time to move your hands from the keyboard to 
the mouse, and maneuver to the correct button. All you have to do is 
wait a half second. This method also has no cost in the common case.
4) There are various possibilities for adaptive paths to resolve 
ambiguities. "Eclipse" and "ellipses" seem to be the two proposals on 
the table. It is easy to come up with corner cases that are misleading 
with either scheme. For example "bar/baz/baz/foo.py" and 
"bar/baz/foo.py" are misleading with both schemes. Neither scheme scales 
well to large projects. Both schemes violate common pathname 
conventions. Neither seems appropriate as a default, although they could 
be valuble to users who habitually edit many files with identical names. 
As you pointed out, feature creep and excess configurability have their 
own costs, which needs to be weighed against the marginal advantage in a 
generally uncommon use case.

It's interesting that you bring up Apple's UI design which has always 
placed high value on consistency and orthogonality, and much lower value 
on specialized tweaks for power users with rare use cases. I would argue 
that these values have been instrumental to Apple's success.

The real solution of course is to choose unique file names. It's not 
like this is a big hardship. __init__.py's can and (arguably) should 
contain just a few lines of imports.

Martin