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

["Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu>]

> John Wiegley <johnw@gnu.org> writes:
> > These behaviors are all configurable.  Perhaps we should simple tell
> > shell.el to configure pcomplete so that it behaves like Emacs'
> > standard (and dumb yet straightforward) completion.
> 
> This seems like the wrong answer -- the `cycling' behavior is potentially
> very convenient, it's just that the implementation has some rough edges.

Indeed, there are two issues:
- should the default behavior be to cycle or should it be the same
  as in the rest of Emacs ?  (I personally don't like cycling too much,
  but maybe we can have non-cycling completion bound to TAB and cycling
  bound to M-TAB).
- when using the sometimes-cycling-sometimes-not behavior (which depends
  on the total number of possible completions IIUC), it should tell the
  user what actually happened in a unambiguous way.

>    and /tmp contains `foo1' and `foo2', then hitting TAB at eob would display:
> 
>      $ cat /tmp/foo1_  [1 more completion]

I agree, but last time I looked at it, I found it difficult to implement
because the completion might be done in the middle of the line and because
the "[1 more completion]" message might wrap around forcing the rest of
the display to temporarily scroll down by one line.
It seems to me that this "[1 more completion]" message should be an
overlay text which only hides other parts of the display but doesn't
cause anything else to move (it's overwritten rather than inserted).
But Emacs doesn't seem to offer any such form of "overlay text".
The closest seems to be tooltip frames.
Although maybe using overwrite-mode one could get something good enough
(problem is, it's difficult to undo the overwrite 100% because it messes
up markers).


	Stefan


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