2009/2/20 Beni Cherniavsky <[email protected]>
> On Mon, Feb 16, 2009 at 22:41, Axel Liljencrantz <[email protected]>
> wrote:
> >
> > 2009/2/6 Josic Goran <[email protected]>
> >>
> >> I known CDPATH from bash...that's not the point
> >>
> >> I was just wondering why there isn't the same functionality for ls.
> >> I know that for the other commands can be dangerous.
> >> I don't expect the same functionality for mv and rm ... but for ls it
> can
> >> be very useful.
> >>
> >
> > Never though of it, but I agree that it does make sense that
> non-destructive
> > commands like ls try to be a bit more forgiving and 'do what you mean'.
> > Unfortunatly, that's not the choice of the shell. 'cd' is a builtin ish
> > command, so we can make it behave any way we please. 'ls' is, and should
> be,
> > an external command. It would be possible in theory to recognize that ls
> is
> > a non-destructive command and remorph path names under without telling
> > anybody, but before you know it, you'll end up with some very, very
> > confusing corner cases.
> >
> I claim CDPATH as-is is fundamentally evil. By "evil" I mean:
>
> - Surprising and undiscoverable: something magic happens silently; if
> you notice it at all, you have no idea you should look up "CDPATH".
> And the way completion supports it (expanding a directory name that
> isn't there!) just reinforces the surprise.
>
> - Non-orthogonal: it only affects "cd foo" (or just "foo"). And we
> are afraid of expanding this to all commands because it's surprising.
>
> Here is an alternative take: instead of supporting CDPATH at cd
> execution time, let's expand it at completion time! if you try
> something like:
>
> cd proj<tab>
>
> you should obtain:
>
> cd ~/project/
>
> Benefits:
>
> + Unsurprising: you see that the completion changed your command, the
> command itself does nothing magic.
>
> - Half-discoverable: you see how it behaves, you still don't know
> that CDPATH is the culprit. We could mention it the completion
> description (the thing that appears to the right in parens). Can we
> arrange some kind of transient display of descirptions even when there
> is a single completion?
>
> + Orthogonal: works with any command (in places where you expect a path)!
>
> + Safe: it only happens when you ask for it.
>
> The price is pressing an extra Tab in the common "cd foo" case. I
> claim it's worth it.
> As a side effect, I think it makes "~" not so useful in CDPATH (Tab is
> 1 press, ~/ is 2).
> And if the default CDPATH can be clean, the discoverability problem
> vanishes - nothing magic happens until you set CDPATH, which means you
> already know where to change it.
>
> Now we just have to decide how to handle ambiguous completion.
> Suppose CDPATH is: /home/me /home/you, /home/me/project and
> /home/you/project both exist and I type:
>
> ls proj<tab><tab>
>
> I should obtain:
>
> ls project/
>
> /home/me/project/ (Directory)
> /home/you/project/ (Directory)
>
> (with the "project/" part uncolored),
> But how do I choose one? Typing an extra character doesn't work well,
> because we are trying to complete a prefix rather than a suffix.
>
> * Support for completion in the middle of words would help. I could
> go to the start of "project", press <tab><tab> and obtain:
>
> ls /home/project
>
> /home/me/project/ (Directory)
> /home/you/project/ (Directory)
>
> (with the "/home/" and "project/" part uncolored). But now, pressing
> "m" or you does help!
>
> ls /home/m<tab here>project/
>
> should expand unambiguously to:
>
> ls /home/me/project/
>
> * We could turn the pager into a menu. Instead of just scrolling, Up
> and Down could move a selection, so that another Tab would select the
> current offer. I'd even claim that this is always convenient and
> should work with short non-paged completion lists too!
>
> But both of these are generic enhancements to completion, arguably
> desirable in their own right but should not delay the change of
> CDPATH.
>
> * We could adopt the current order-dependant behaviour of CDPATH and
> always choose the first matching completion.
>
> And of course "CDPATH" is not longer a good name under the new scheme.
> "COMPLETEPATH"? "COMPLETEDIRS"? lowercase?
>
The drawback I see with this suggestion is that we actually overload two
very different operation on the same key: Complete an incomplete argument
and transform a shorthand version of an argument to the full version. I see
the value of providing the latter as well, but it's not obvious that they
should use the same activation key.
I see potential for situations where _both_ completion and shorthand might
make sense at the same time, and by overloading them to the same key, we'll
piss off users when we do the wrong thing. For example, if I have a file
foosball.c in CWD, and a directory ~/food/, the string 'foo' can be either
completed or shorthand expanded with different results.
Other shorthand features that might be nice to implement is to transform
e.g. the string/u/l/b/ into /usr/local/bin/.
Axel
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users
