From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: [friedman@splode.com: some other observations on pcomplete] Date: Mon, 11 Mar 2002 09:43:47 -0500 Sender: emacs-devel-admin@gnu.org Message-ID: <200203111443.g2BEhlU09346@rum.cs.yale.edu> References: <200203102132.g2ALWfr04155@wijiji.santafe.edu> <87it8339co.fsf@alice.dynodns.net> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1015859905 29723 80.91.224.249 (11 Mar 2002 15:18:25 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 11 Mar 2002 15:18:25 +0000 (UTC) Cc: John Wiegley , emacs-devel@gnu.org Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16kRZB-0007jI-00 for ; Mon, 11 Mar 2002 16:18:25 +0100 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16kRaw-0002Hb-00 for ; Mon, 11 Mar 2002 16:20:14 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16kR3a-0006j2-00; Mon, 11 Mar 2002 09:45:46 -0500 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16kR1j-0006a4-00; Mon, 11 Mar 2002 09:43:51 -0500 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id g2BEhlU09346; Mon, 11 Mar 2002 09:43:47 -0500 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: Miles Bader Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:1854 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:1854 > John Wiegley 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