unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* eshell/pcomplete suggestion: indicator for completion cycling
@ 2004-01-06  8:54 Kai Grossjohann
  2004-01-07  2:41 ` Richard Stallman
  0 siblings, 1 reply; 6+ messages in thread
From: Kai Grossjohann @ 2004-01-06  8:54 UTC (permalink / raw)


I think that I might like completion cycling, as implemented by
default in eshell.  But I always get confused whether cycling is
happening or not.

So I think it would be useful to have a visual indicator that shows
whether TAB performed cycling or not.  For example, a momentary string
display at point could be used, or the (text) cursor could change
color, or the inserted text could have some face.

What do people think?

Kai

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: eshell/pcomplete suggestion: indicator for completion cycling
  2004-01-06  8:54 eshell/pcomplete suggestion: indicator for completion cycling Kai Grossjohann
@ 2004-01-07  2:41 ` Richard Stallman
  2004-01-07  8:24   ` Kai Grossjohann
  0 siblings, 1 reply; 6+ messages in thread
From: Richard Stallman @ 2004-01-07  2:41 UTC (permalink / raw)
  Cc: emacs-devel

    I think that I might like completion cycling, as implemented by
    default in eshell.

What is "completion cycling"?

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: eshell/pcomplete suggestion: indicator for completion cycling
  2004-01-07  2:41 ` Richard Stallman
@ 2004-01-07  8:24   ` Kai Grossjohann
  2004-01-07 10:59     ` Eli Zaretskii
  2004-01-07 21:19     ` Richard Stallman
  0 siblings, 2 replies; 6+ messages in thread
From: Kai Grossjohann @ 2004-01-07  8:24 UTC (permalink / raw)


Richard Stallman <rms@gnu.org> writes:

>     I think that I might like completion cycling, as implemented by
>     default in eshell.
>
> What is "completion cycling"?

Let's say you have a directory with files foo1, foo2, and foo3.  Let's
say you type f and then hit the TAB key.  The default Emacs completion
behavior is to complete f to foo.  Then you hit TAB again and get a
list of all possible completions.

Cycling completions means that the first TAB, instead of completing f
to foo, inserts the first possible completion, foo1.  Hitting TAB
again replaces foo1 with foo2, and again replaces that with foo3, and
again goes back to foo1.

By default, TAB in eshell does the cycling thing if there are up to
five possible completions.  If there are more than five possible
completions, then it inserts substrings.

The problem should be obvious: if I don't know which files are in the
directory, then I don't know whether an insertion is a prefix of the
full filename or a full filename already.

Kai

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: eshell/pcomplete suggestion: indicator for completion cycling
  2004-01-07  8:24   ` Kai Grossjohann
@ 2004-01-07 10:59     ` Eli Zaretskii
  2004-01-07 21:19     ` Richard Stallman
  1 sibling, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2004-01-07 10:59 UTC (permalink / raw)
  Cc: emacs-devel

> From: Kai Grossjohann <kai@emptydomain.de>
> Date: Wed, 07 Jan 2004 09:24:26 +0100
> 
> By default, TAB in eshell does the cycling thing if there are up to
> five possible completions.  If there are more than five possible
> completions, then it inserts substrings.

FWIW, Less's completion also cycles.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: eshell/pcomplete suggestion: indicator for completion cycling
  2004-01-07  8:24   ` Kai Grossjohann
  2004-01-07 10:59     ` Eli Zaretskii
@ 2004-01-07 21:19     ` Richard Stallman
  2004-01-08  6:52       ` Kai Grossjohann
  1 sibling, 1 reply; 6+ messages in thread
From: Richard Stallman @ 2004-01-07 21:19 UTC (permalink / raw)
  Cc: emacs-devel

    Cycling completions means that the first TAB, instead of completing f
    to foo, inserts the first possible completion, foo1.  Hitting TAB
    again replaces foo1 with foo2, and again replaces that with foo3, and
    again goes back to foo1.

I am not sure that should be the default, since it might confuse
people who were not expecting it.  It certainly should not be the
default in eshell only, since that is inconsistent.  However, having
it as an option everywhere in Emacs would be good.  And maybe having
it as the default everywhere in Emacs would be good, I am just not sure.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: eshell/pcomplete suggestion: indicator for completion cycling
  2004-01-07 21:19     ` Richard Stallman
@ 2004-01-08  6:52       ` Kai Grossjohann
  0 siblings, 0 replies; 6+ messages in thread
From: Kai Grossjohann @ 2004-01-08  6:52 UTC (permalink / raw)


Richard Stallman <rms@gnu.org> writes:

>     Cycling completions means that the first TAB, instead of completing f
>     to foo, inserts the first possible completion, foo1.  Hitting TAB
>     again replaces foo1 with foo2, and again replaces that with foo3, and
>     again goes back to foo1.
>
> I am not sure that should be the default, since it might confuse
> people who were not expecting it.

Yes.  I just wanted to change its behavior when it is on.  Whether or
not it should be on by default is orthogonal.

I can think of a way to make it behave more similar to non-cycling
completion, but I'm not sure if this is acceptable:  With
delete-selection-mode (or a similar mode) turned on, one could insert
the common prefix normally, and the suffix that's unique to the first
completion could be selected.  Then users just typing more characters
will delete the part that they don't expect, and those people who want
to keep the unique suffix can just disable the selection.

(I used the term "selection" because it is part of the name
delete-selection-mode; maybe I should have said region or active
region instead?  But I think you understand what I mean.)

The "inserted part is selected, and typing a key removes the
selection" behavior is common to other programs/systems, too, so many
people will be familiar with it.

> It certainly should not be the default in eshell only, since that is
> inconsistent.  However, having it as an option everywhere in Emacs
> would be good.

I agree.  This has (partially) been discussed some moons ago:
shell-mode was changed to use the pcomplete package instead of
comint-dynamic-complete.  But then people complained about the change
in behavior, so shell-mode was made to use comint-dynamic-complete
again.

I *think* that it would have been sufficient to turn off cycling in
pcomplete to make the complainers happy, but I never really got the
chance to find out.

Maybe now is the time to discuss this again?


Above and beyond what has been discussed up to now, I think that
unifying completion across Emacs would be good.  There are a number of
packages that influence completion in one way or another.  In addition
to pcomplete (which provides cycling completion, but my understanding
is that its focus is on selecting the right set of completions --
restrict completion to *.dvi files after the command xdvi, for
example), there is also iswitchb and ido, which provide completion for
C-x b and/or C-x C-f.  And then there is icomplete which I think
affects all minibuffer completions.

> And maybe having it as the default everywhere in Emacs would be
> good, I am just not sure.

Same here.

Kai

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2004-01-08  6:52 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-06  8:54 eshell/pcomplete suggestion: indicator for completion cycling Kai Grossjohann
2004-01-07  2:41 ` Richard Stallman
2004-01-07  8:24   ` Kai Grossjohann
2004-01-07 10:59     ` Eli Zaretskii
2004-01-07 21:19     ` Richard Stallman
2004-01-08  6:52       ` Kai Grossjohann

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).