From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: Assignment of misc packages for emacs Date: 08 Jun 2002 10:09:04 +0900 Sender: emacs-devel-admin@gnu.org Message-ID: <87wutapoen.fsf@tc-1-100.kawasaki.gol.ne.jp> References: <200205050534.g455YfF01634@aztec.santafe.edu> <5xbsbumexh.fsf@kfs2.cua.dk> <200205141941.g4EJfud15293@aztec.santafe.edu> <5xvg9qmgzt.fsf@kfs2.cua.dk> <200205151927.g4FJRRW26103@rum.cs.yale.edu> <5x3cwr4q7m.fsf@kfs2.cua.dk> <87g00rd74y.fsf@tc-1-100.kawasaki.gol.ne.jp> <87sn4otknt.fsf@tc-1-100.kawasaki.gol.ne.jp> <200205191441.g4JEfMg23080@rum.cs.yale.edu> <200205202134.g4KLYHj26031@aztec.santafe.edu> <200205222227.g4MMRIX29393@aztec.santafe.edu> <87g0030xah.fsf@tc-1-100.kawasaki.gol.ne.jp> <200206070045.g570j5125701@aztec.santafe.edu> <5xk7pa1xi7.fsf@kfs2.cua.dk> Reply-To: Miles Bader NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1023498940 1845 127.0.0.1 (8 Jun 2002 01:15:40 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 8 Jun 2002 01:15:40 +0000 (UTC) Cc: rms@gnu.org, monnier+gnu/emacs@RUM.cs.yale.edu, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17GUpQ-0000Te-00 for ; Sat, 08 Jun 2002 03:15:40 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17GVB2-0002cE-00 for ; Sat, 08 Jun 2002 03:38:00 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17GUot-0001w3-00; Fri, 07 Jun 2002 21:15:07 -0400 Original-Received: from smtp02.fields.gol.com ([203.216.5.132]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 17GUoQ-0001ta-00; Fri, 07 Jun 2002 21:14:39 -0400 Original-Received: from tc-2-222.kawasaki.gol.ne.jp ([203.216.25.222] helo=tc-1-100.kawasaki.gol.ne.jp) by smtp02.fields.gol.com with esmtp (Magnetic Fields) id 17GUoM-0000W7-00; Sat, 08 Jun 2002 10:14:35 +0900 Original-Received: by tc-1-100.kawasaki.gol.ne.jp (Postfix, from userid 1000) id 3678C30A4; Sat, 8 Jun 2002 10:09:05 +0900 (JST) Original-To: storm@cua.dk (Kim F. Storm) System-Type: i686-pc-linux-gnu In-Reply-To: <5xk7pa1xi7.fsf@kfs2.cua.dk> Original-Lines: 57 X-Abuse-Complaints: abuse@gol.com Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:4645 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:4645 storm@cua.dk (Kim F. Storm) writes: > > I think it should be the same delay -- having a separate parameter > > seems like creeping featurism. > > IMO, there shouldn't be any delay for key-menus. This functionality > is similar to a menu, and for menus we don't want any delay if we can > avoid it. Well, exactly how you view it depends on who you are, I suspect. In any case, they're very different from normal mouse-menus (or some other sorts of keyboard menus), because the latter are inherently visual, whereas this sort of keyboard menu is _not_, it's really just a visual aid added on top of the existing key-binding mechanism. Sometimes visual aids are good, and sometimes they're a distraction. I forsee two common ways of use: (1) For bindings the user knows well, they'll just hit the prefix key and the following key with no pause, and won't need to look at a menu at all -- and will be annoyed by any flash of the menu popping up and any extra slowness/GC caused by the menu code executing. (2) For bindings the user _doesn't_ know, they'll want the menu, to help them choose. Since they're going to have to pause here anyway to examine the menu and think about what to do, a short delay for the menu to appear is not much of a problem. Morever, for me (like many other long-time emacs users, I suspect), it seems _natural_ because I'm used to the visual indication of a key prefix showing up in the echo area after a short delay, and because emacs generally avoids unnecessary verbiage when possible. For me, it seems like Just The Right Thing To Do. The only existing (that I know of) use of this mechansim is in pcl-cvs's diff menu, where `d d' will run a diff -- something which I do _very_ often, and hardly need a menu for. I presume more and more people may want to use this menu code after they become aware of it (for instance, with a few tweaks, calc could probably use it for its many key prefixes). Having a menu suddenly pop _always_ where previously there was none (unless you hit ?, in calc's case) would be very annoying for many people, I think. This, BTW is why I suggested that perhaps a different delay variable might be appropriate. For menus, I think a somewhat shorter delay than the prefix-key-echoing is right -- you want to avoid them popping up only in the case where you hit the prefix key and the following key in quick succession (my case (1) above), and for case (2), you want the menu to appear in a timely manner. Also, beginners _may_ want to set this delay to 0 (but I rather think not, actually, as long as it's not so long). Anyway, that's my rant on the issue. -Miles -- Yo mama's so fat when she gets on an elevator it HAS to go down.