From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Galen Boyer Newsgroups: gmane.emacs.help Subject: Re: eshell: Support old-style completion and cycling completion? Date: 17 Feb 2003 09:09:20 -0600 Sender: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: 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 1045494542 32511 80.91.224.249 (17 Feb 2003 15:09:02 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 17 Feb 2003 15:09:02 +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 18kmsO-0008Mv-00 for ; Mon, 17 Feb 2003 16:08:20 +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 18kmuf-0006TF-03 for gnu-help-gnu-emacs@m.gmane.org; Mon, 17 Feb 2003 10:10:33 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newshosting.com!news-xfer1.atl.newshosting.com!novia!newscene.com!newscene.com!newscene!novia!novia!sequencer.newscene.com!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 36 Original-Sender: galenboyer@hotpop.com User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 Original-Xref: shelby.stanford.edu gnu.emacs.help:110275 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:6777 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:6777 On Mon, 17 Feb 2003, kai.grossjohann@uni-duisburg.de wrote: > Galen Boyer writes: > >> On Sun, 16 Feb 2003, kai.grossjohann@uni-duisburg.de wrote: >> >>> Hm. Thinking some more, it's possible that a behavior that I would >>> like is this: >>> >>> If there is a common prefix for all completions, insert that. If >>> there is more than one possible completion, beep. After the next >>> TAB, show all possible completions. After the next TAB, complete to >>> the first completion. So it's a kind of a hybrid between old-style >>> and cycling style. >> >> The tab following the first completion buffer scrolls that completion >> buffer. How should the user retain that functionality? > > Good point. I hadn't thought about that. Well, C-M-v can be used > for scrolling. Or TAB scrolls until it arrives at the end and then > starts cycling. Probably depends on taste. 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? 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) -- Galen deForest Boyer Sweet dreams and flying machines in pieces on the ground.