Re: [friedman@splode.com: some other observations on pcomplete]

From: Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann)
Cc: monnier+gnu/emacs@rum.cs.yale.edu, emacs-devel@gnu.org,
	johnw@gnu.org, friedman@splode.com
Subject: Re: [friedman@splode.com: some other observations on pcomplete]
Date: Wed, 13 Mar 2002 13:38:09 +0100	[thread overview]
Message-ID: <vaf3cz4y766.fsf@INBOX.auto.emacs.devel.tok.lucy.cs.uni-dortmund.de> (raw)
In-Reply-To: <200203131058.g2DAwSX05431@wijiji.santafe.edu> (Richard Stallman's message of "Wed, 13 Mar 2002 03:58:28 -0700 (MST)")

Richard Stallman <rms@gnu.org> writes:

>     The use of pcomplete.el has several advantages, even if you make
>     it behave "almost as the old code", so I think it would be an error
>     to revert the change.
>
> Could someone tell me what they are?

I'm not an expert on this, but two things at least come to my mind:

* pcomplete can offer context-sensitive completion, depending on the
  shell command.  For instance, "make a<TAB>" reads the Makefile and
  offers all make targets starting with "a".  Filename completion
  after the "xdvi" command could be restricted to *.dvi files.  (Not
  sure if this is in pcomplete already, but it could be added easily.)

* After hitting TAB to pop up a *Completions* buffer, typing makes the
  buffer (window, actually) go away.

Additionally, if everything uses pcomplete, then the user just needs
to frob one option to get the cycling behavior, everywhere.  Same for
the other options that pcomplete allows.

kai
-- 
Silence is foo!

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel