[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Assignment of misc packages for emacs

From: Miles Bader
Subject: Re: Assignment of misc packages for emacs
Date: 08 Jun 2002 10:09:04 +0900

address@hidden (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.


Yo mama's so fat when she gets on an elevator it HAS to go down.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]