From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.devel Subject: Re: Fast completion with visible cue? Date: Fri, 27 Aug 2004 12:16:44 +0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1093601853 2134 80.91.224.253 (27 Aug 2004 10:17:33 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 27 Aug 2004 10:17:33 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 27 12:17:19 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1C0dnL-0006yD-00 for ; Fri, 27 Aug 2004 12:17:19 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C0ds0-0005PV-6J for ged-emacs-devel@m.gmane.org; Fri, 27 Aug 2004 06:22:08 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C0drk-0005Oz-Ld for emacs-devel@gnu.org; Fri, 27 Aug 2004 06:21:53 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C0dri-0005Ne-I7 for emacs-devel@gnu.org; Fri, 27 Aug 2004 06:21:52 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C0dri-0005NF-4s for emacs-devel@gnu.org; Fri, 27 Aug 2004 06:21:50 -0400 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C0dmx-0006P9-FP for emacs-devel@gnu.org; Fri, 27 Aug 2004 06:16:55 -0400 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1C0dmw-0007cd-00 for ; Fri, 27 Aug 2004 12:16:54 +0200 Original-Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Aug 2004 12:16:54 +0200 Original-Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Aug 2004 12:16:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-To: emacs-devel@gnu.org Original-Lines: 56 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se Mail-Copies-To: nobody User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:kBaZ/ucWgaFdlGjJZcVawOaMHEo= X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:26561 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:26561 "Jan D." writes: >> Is the following possible with some ad-on package? If so, would it >> make sense to enable the ad-on by default? If not, what do people >> think about adding this feature? >> > > ... > >> Now, wouldn't it be Really Nice if the minibuffer prompt would >> contain: >> >> Find File: ~/pro[CURSOR]ects/src/foo/doc/drafts/template/help.txt >> >> where CURSOR isn't shown verbatim, but indicate where the cursor is, >> and the latter part of the string is displayed in a light gray color >> but the earlier part of the string is in black. >> >> You could continue typing and TAB complete like the normal prompt, but >> would be able to open the "suggested" filename (shown in light gray) >> by simply pressing RET. To really open a file called "~/pro" you >> could press SPC DEL or similar. > > Care must be taken when implementing this feature. For example, there > should be some delay before showing the suggested part. In Safari > (the browser on Mac OSX) I find myself often type in a complete path > and then hit RETURN, just to end up with a longer part that I visited > previously. In your example I would type > > Find File: ~/projects/src/foo/doc/drafts/[RETURN] > > only to find that help.txt is opened again. The suggested part is added > in the same millisecond as I hit return. This behaviour is very > annoying. I've seen it too, and I agree. I wonder what a good default delay would be. 100ms? OTOH, perhaps it is better to display the cue instantly, but to only use it as the user entry, if it had been shown to the user for 100ms. So the user can hit RET even when the hint is shown, as long as she doesn't wait 100ms or more. Mozilla's URL input uses a pull down input field, so the user would type ~/pro, and see a pull down input field with matching file names from the history ring, and can use TAB RET to select the first one. This is very addictive. Of course, Emacs couldn't use TAB since it is already used for old style file name completion. M-TAB? Perhaps this latter idea is less disruptive to how things used to work. The only difference would be that the minibuffer is enlarged a few lines to show matching file names from the history ring, and that M-TAB would allow the user to cycle through those entries, and place the content of those entries in the first 'Find File: ' line. Thanks.