eshell: Support old-style completion and cycling completion?

eshell: Support old-style completion and cycling completion?

[Kai Großjohann]

Usually, I know and love the fact that hitting TAB completes as far
as it can, then offers the list of completions.

But sometimes, I think it might be nice to cycle the completions
instead.  So I tried a naive approach:

(defun kai-eshell-pcomplete-cycling ()
  "Like `pcomplete', but turn on cycling explicitly."
  (interactive)
  (let ((eshell-cmpl-cycle-completions t))
    (pcomplete)))

Then I bound this to a key.  No dice.

Hm.  Thinking some more, it's possible that a behavior that I would
like is this:

If there is a common prefix for all completions, insert that.  If
there is more than one possible completion, beep.  After the next
TAB, show all possible completions.  After the next TAB, complete to
the first completion.  So it's a kind of a hybrid between old-style
and cycling style.

But I don't have this behavior, so I haven't tried it, so I don't
know.  What do people think?
-- 
A turnip curses Elvis

Re: eshell: Support old-style completion and cycling completion?

[Galen Boyer]

On Sun, 16 Feb 2003, kai.grossjohann@uni-duisburg.de wrote:

> Hm.  Thinking some more, it's possible that a behavior that I would
> like is this:
> 
> If there is a common prefix for all completions, insert that.  If
> there is more than one possible completion, beep.  After the next
> TAB, show all possible completions.  After the next TAB, complete to
> the first completion.  So it's a kind of a hybrid between old-style
> and cycling style.

The tab following the first completion buffer scrolls that completion
buffer.  How should the user retain that functionality?

-- 
Galen deForest Boyer
Sweet dreams and flying machines in pieces on the ground.

Re: eshell: Support old-style completion and cycling completion?

[Kai Großjohann]

Galen Boyer <galenboyer@hotpop.com> writes:

> On Sun, 16 Feb 2003, kai.grossjohann@uni-duisburg.de wrote:
>
>> Hm.  Thinking some more, it's possible that a behavior that I would
>> like is this:
>> 
>> If there is a common prefix for all completions, insert that.  If
>> there is more than one possible completion, beep.  After the next
>> TAB, show all possible completions.  After the next TAB, complete to
>> the first completion.  So it's a kind of a hybrid between old-style
>> and cycling style.
>
> The tab following the first completion buffer scrolls that completion
> buffer.  How should the user retain that functionality?

Good point.  I hadn't thought about that.  Well, C-M-v can be used
for scrolling.  Or TAB scrolls until it arrives at the end and then
starts cycling.  Probably depends on taste.

-- 
A turnip curses Elvis

Re: eshell: Support old-style completion and cycling completion?

[Galen Boyer]

On Mon, 17 Feb 2003, kai.grossjohann@uni-duisburg.de wrote:
> Galen Boyer <galenboyer@hotpop.com> writes:
> 
>> On Sun, 16 Feb 2003, kai.grossjohann@uni-duisburg.de wrote:
>>
>>> Hm.  Thinking some more, it's possible that a behavior that I would
>>> like is this:
>>> 
>>> If there is a common prefix for all completions, insert that.  If
>>> there is more than one possible completion, beep.  After the next
>>> TAB, show all possible completions.  After the next TAB, complete to
>>> the first completion.  So it's a kind of a hybrid between old-style
>>> and cycling style.
>>
>> The tab following the first completion buffer scrolls that completion
>> buffer.  How should the user retain that functionality?
> 
> Good point.  I hadn't thought about that.  Well, C-M-v can be used
> for scrolling.  Or TAB scrolls until it arrives at the end and then
> starts cycling.  Probably depends on taste.

Maybe it could be sensitive to the speed of tab'n?  2 tabs in succession
with very little pause between those tabs moves the user into cycling?
One could probably assume slower tab'n would mean user making judgements
and therefore using the completion buffer?

One other puzzling thing for me was the beep if there is more than one
completion?  Is this beep to signify to the user that they should make a
determination of cycling vs normal completion buffer?  Why not just
straight to the completion buffer and have some way to engage cycling
from there?  (fast tab'n is the idea that came to mind, but I'm sure
there are better ways)

-- 
Galen deForest Boyer
Sweet dreams and flying machines in pieces on the ground.

Re: eshell: Support old-style completion and cycling completion?

[Kai Großjohann]

Galen Boyer <galenboyer@hotpop.com> writes:

> Maybe it could be sensitive to the speed of tab'n?  2 tabs in succession
> with very little pause between those tabs moves the user into cycling?
> One could probably assume slower tab'n would mean user making judgements
> and therefore using the completion buffer?

That's a possibility.  I don't like speed sensitivity that much, but
oh, well.  I think I could get used to it.

> One other puzzling thing for me was the beep if there is more than one
> completion?  Is this beep to signify to the user that they should make a
> determination of cycling vs normal completion buffer?  Why not just
> straight to the completion buffer and have some way to engage cycling
> from there?  (fast tab'n is the idea that came to mind, but I'm sure
> there are better ways)

I wanted the number of TAB to be predictable to effect a certain
result.  So the user can type a prefix, then hit TAB three times, to
obtain the first possible completion.  When skipping the beep, some
prefixes would require two, others three, TABs.

-- 
A turnip curses Elvis

Re: eshell: Support old-style completion and cycling completion?

[Stefan Monnier <foo@acm.com>]

>> Good point.  I hadn't thought about that.  Well, C-M-v can be used
>> for scrolling.  Or TAB scrolls until it arrives at the end and then
>> starts cycling.  Probably depends on taste.
> Maybe it could be sensitive to the speed of tab'n?  2 tabs in succession

I think Kai's suggestion makes perfect sense.  After all, if the
list of completions is long enough to span two screens, then
you probably don't want to start cycling through them,


        Stefan

Re: eshell: Support old-style completion and cycling completion?

[Kai Großjohann]

"Stefan Monnier <foo@acm.com>" <monnier+gnu.emacs.help/news/@flint.cs.yale.edu> writes:

> I think Kai's suggestion makes perfect sense.  After all, if the
> list of completions is long enough to span two screens, then
> you probably don't want to start cycling through them,

Well...  My suggestion was to cycle anyway (perhaps after TAB has
scrolled the completions buffer to the end).

It could be useful if I know that my file is the second or third,
even if there are 100 choices.
-- 
A turnip curses Elvis

Re: eshell: Support old-style completion and cycling completion?

[Kevin Rodgers]

Kai Großjohann wrote:

> Usually, I know and love the fact that hitting TAB completes as far
> as it can, then offers the list of completions.
> 
> But sometimes, I think it might be nice to cycle the completions
> instead.  So I tried a naive approach:
> 
> (defun kai-eshell-pcomplete-cycling ()
>   "Like `pcomplete', but turn on cycling explicitly."
>   (interactive)
>   (let ((eshell-cmpl-cycle-completions t))
>     (pcomplete)))
> 
> Then I bound this to a key.  No dice.


Does eshell use the normal completion mechanism (i.e. does it display the
*Completions* buffer when there is more than one possible completion)?

If so, my minibuffer-complete-cycle.el package may be useful:


http://groups.google.com/groups?selm=3B6ED00C.E937D0B3%40ihs.com



-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

Re: eshell: Support old-style completion and cycling completion?

[John Wiegley]

>>>>> On Mon Feb 17, "Stefan writes:

> I think Kai's suggestion makes perfect sense.  After all, if the
> list of completions is long enough to span two screens, then you
> probably don't want to start cycling through them,

Pcomplete (which is what Eshell uses) will not cycle if the number of
completions exceeds `eshell-cmpl-cycle-cutoff-length'.

These fancy TAB behaviors sound very interesting.  I'm eager to hear
what you all decide upon.

As for me, I like TAB to cycle right away if the number of
completions is very small, and to pop up the Completions buffer if it
is large.

John

Re: eshell: Support old-style completion and cycling completion?

[Kai Großjohann]

Kevin Rodgers <kevin.rodgers@ihs.com> writes:

> Does eshell use the normal completion mechanism (i.e. does it display the
> *Completions* buffer when there is more than one possible completion)?

No, eshell uses pcomplete.  That package already allows for cycling
completion.  I turned that off a while ago.  But now I think I might
like to use it from time to time.

-- 
A turnip curses Elvis

Re: eshell: Support old-style completion and cycling completion?

[Galen Boyer]

On Mon, 17 Feb 2003, johnw@gnu.org wrote:

> Pcomplete (which is what Eshell uses) will not cycle if the number of
> completions exceeds `eshell-cmpl-cycle-cutoff-length'.
> 
> These fancy TAB behaviors sound very interesting.  I'm eager to hear
> what you all decide upon.

> As for me, I like TAB to cycle right away if the number of
> completions is very small, and to pop up the Completions buffer if it
> is large.

I think I like this the best.

If the completions buffer is envoked, does the cycling behavior kick in
after the completions have decremented past
eshell-cmpl-cycle-cutoff-length'?  That could make the final choice
always based on cycling (or full completion), which might be useful.

-- 
Galen deForest Boyer
Sweet dreams and flying machines in pieces on the ground.

Re: eshell: Support old-style completion and cycling completion?

[John Wiegley]

>>>>> On Mon Feb 17, Galen writes:

>> As for me, I like TAB to cycle right away if the number of
>> completions is very small, and to pop up the Completions buffer if
>> it is large.

> I think I like this the best.

That's the default. ;)

John

Re: eshell: Support old-style completion and cycling completion?

[Kai Großjohann]

John Wiegley <johnw@gnu.org> writes:

> These fancy TAB behaviors sound very interesting.  I'm eager to hear
> what you all decide upon.
>
> As for me, I like TAB to cycle right away if the number of
> completions is very small, and to pop up the Completions buffer if it
> is large.

Maybe it is best to start with something simple, then add dwimishness
later on.  It turns out that I, personally, like both the non-cycling
and the cycling behavior, so I just want two keys: one for cycling
and one for non-cycling.  M-TAB appears to be available.  So I'd be
happy to use it for cycling completion.

It ought to be simple, but I couldn't do it.  What did I do wrong?
-- 
A turnip curses Elvis