all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Kai Grossjohann <kai@emptydomain.de>
Subject: Re: eshell/pcomplete suggestion: indicator for completion cycling
Date: Thu, 08 Jan 2004 07:52:58 +0100	[thread overview]
Message-ID: <87wu837wz9.fsf@emptyhost.emptydomain.de> (raw)
In-Reply-To: E1AeL5l-0002UV-7t@fencepost.gnu.org

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

      reply	other threads:[~2004-01-08  6:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wu837wz9.fsf@emptyhost.emptydomain.de \
    --to=kai@emptydomain.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.