[wingide-users] Tiny feature request
martin_d_frankel at yahoo.com
Thu Jun 22 20:11:20 EDT 2006
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.
More information about the wingide-users