From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: kai.grossjohann@uni-duisburg.de (Kai =?iso-8859-1?q?Gro=DFjohann?=) Newsgroups: gmane.emacs.help Subject: Re: eshell: Support old-style completion and cycling completion? Date: Mon, 17 Feb 2003 16:34:16 +0100 Organization: University of Duisburg, Germany Sender: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: <84smum7wg7.fsf@lucy.is.informatik.uni-duisburg.de> References: <84k7g0x9oz.fsf@lucy.is.informatik.uni-duisburg.de> <84lm0fidel.fsf@lucy.is.informatik.uni-duisburg.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1045496092 8888 80.91.224.249 (17 Feb 2003 15:34:52 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 17 Feb 2003 15:34:52 +0000 (UTC) Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18knI6-0002Im-00 for ; Mon, 17 Feb 2003 16:34:46 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18knJg-0000dO-07 for gnu-help-gnu-emacs@m.gmane.org; Mon, 17 Feb 2003 10:36:24 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!opentransit.net!fu-berlin.de!uni-berlin.de!lucy.is.informatik.uni-duisburg.DE!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 24 Original-NNTP-Posting-Host: lucy.is.informatik.uni-duisburg.de (134.91.35.216) Original-X-Trace: fu-berlin.de 1045496104 49336522 134.91.35.216 (16 [73968]) User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/21.3.50 Cancel-Lock: sha1:0sjechs9c9IqWxDkdLCuWdtwyl4= Original-Xref: shelby.stanford.edu gnu.emacs.help:110282 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:6782 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:6782 Galen Boyer writes: > Maybe it could be sensitive to the speed of tab'n? 2 tabs in succession > with very little pause between those tabs moves the user into cycling? > One could probably assume slower tab'n would mean user making judgements > and therefore using the completion buffer? That's a possibility. I don't like speed sensitivity that much, but oh, well. I think I could get used to it. > One other puzzling thing for me was the beep if there is more than one > completion? Is this beep to signify to the user that they should make a > determination of cycling vs normal completion buffer? Why not just > straight to the completion buffer and have some way to engage cycling > from there? (fast tab'n is the idea that came to mind, but I'm sure > there are better ways) I wanted the number of TAB to be predictable to effect a certain result. So the user can type a prefix, then hit TAB three times, to obtain the first possible completion. When skipping the beep, some prefixes would require two, others three, TABs. -- A turnip curses Elvis