[Top][All Lists]

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

RE: Key bindings proposal

From: Drew Adams
Subject: RE: Key bindings proposal
Date: Fri, 13 Aug 2010 17:01:07 -0700

> >> > I would even guess that most Windows users never use the
> >> > ALT key in a Windows-specific way (except for CONTROL-ALT-DELETE)
> >> > and never use the Window key at all.  For one thing, most are not
> >> > programmers (another guess), and most interact with Windows using
> >> > the mouse most of the time, not the keyboard.  And
> >> > my guess is that _very_ few (proportionally) users of
> >> > Windows use menu accelerators.
> >>
> >> Here is a lesson from MS on using MS Word:
> >> http://office.microsoft.com/en-us/word-help/
> >> work-with-the-keyboard-RZ006078589.aspx?section=9
> >>
> >> It mentions explicitly Alt+Letter.
> >
> > So what?  No one said that menu accelerators do not _exist_.
> > And no one said that Microsoft has no doc describing them.
> This is the way MS Word users are educated.

Sorry, my friend (sincerely), but that is nonsense.  99.999999999% of Windows
users have never, ever, ever, ever read that doc section, I am sure.  And very,
very few Windows users make use of menu accelerators.

No, I have no stats to back that up.  But I'm stickin to it.  ;-)

My impression is that you have a very narrow view of the average Windows user,
even the average Windows programmer.  Most do not use menu accelerators, or
ALT-TABbing, or sticky keys.  They just don't.  Sorry.

My sister, who uses Word, never heard of any of those, and she would not dream
of using any of them if I told her they existed.  Your sister too, no doubt.

> People who are mostly programmers or similar might never learn that
> kind of things.

Hey, if those who are mostly programmers don't use them, AND the average
point-and-click user doesn't use them either, then who are you so worried about?
It wouldn't be just yourself, would it?

> I do not know. But where I was working on the
> technical university people actually wrote a lot of text too. (And
> they used tools like MS Words.)

Hey, where I work now and at other places I've worked in the past, lots of
people use Word too.  I've never known _any_ who use menu accelerators.  I've
known only a few who use ALT-TAB etc., and they were all programmers.

Different people use the same tools differently.  Including Emacs.  That's why I
support giving users such things as you've mentioned (as optional behavior).

I really think the only real question is how that could be done
(implementation/design).  I sure cannot speak for Yidong - hell, we disagree on
nearly everything (!), but I would not be surprised if he were _not_ really
opposed to giving users such options.

My guess is that he does not like the sound of the implementation changes it
would seem to require to provide these options.

Why do I think that, even though he said that he was not in favor of providing
such an option?  Because every time we start to get into the details of how it
might be done there ensues a conversation where you say that you have already
done it all - but others do not agree.  They say "Where's the beef?" and you say
"It's all there, look for yourself and figure it out", and 'round you all go in

Or else you say something like you've done it all but there are still some
problems to be worked out.

Do you remember how we got to discussing menu accelerators?  It was I who
mentioned "menus, menus, menus" in response to Uday who was saying that it is
too difficult to discover commands and keys in Emacs.

And later it was I who mentioned that you (Lennart) have already implemented
Windows menu accelerators for Emacs - I mentioned that in the context of telling
Uday that that feature exists and he can use it with La Carte.

But what did you reply to my saying that?  Here it is:

> Yes and we were also discussing adding this to GNU/Linux but it has
> not happened yet.
> A problem is of course that Emacs uses the Alt key by default as Emacs
> META key. (I have a patch for this for w32 as I have said before many
> times).
> There are some bugs in menuacc.el (it depends on tmm), but it works
> reasonably well. I have postponed further development on it until it
> is included in Emacs.

Do you see?  You said that menuacc.el is not fully baked and you have stopped
developing it.  You said you will finish it only after it is included in Emacs.
And you suggested that your feature should have been added to GNU/Linux (not
Emacs) but someone dropped the ball.

And you brought in another topic: use of ALT as Meta by Emacs.  You said, in
effect, that your menu-accelerator feature depends on Emacs not using the ALT
key as Meta by default.  _BY DEFAULT_ no less.

I hope you see the problem I'm trying to point out.  You say that you have a
solution, but that you won't finish it until it is merged into Emacs, and to do
that Emacs has to give up its use of Alt as Meta by default.  Is it any wonder
that things are not clear and the feature has not been adopted as an option?

I might be completely wet, but my guess is that your changes are not clear to
those who could judge them (which does not include me, certainly), and they are
not convinced of how these optional features could be offered.  You "have a
patch for this for w32", but no one seems to see the patch, or perhaps they have
seen it but do not understand it.

Clear that up and I'm convinced we could progress.  If you have a simple
solution, then I'll bet we can get the options you guys want into Emacs (as

But if there is no such real communication about the changes to be made
(implementation), then no progress will be made.  You will remain convinced that
no one wants the features you have to offer, and others will remain convinced
that there was no reasonable and completed implementation of the feature as
optional behavior.

Remember that you know your implementation better than others do.  If you do not
master it and cannot communicate it then others will naturally lose interest.
My friendly advice is to look again at the problem, finish your solution (if
unfinished), and send a complete, clear solution to the list for consideration.

But it needs to offer the feature in an optional way, not hard-coded/built-in or
difficult to bypass.  Above all, the changes need to be clear.

I really think that is the problem behind the resistance you see about this.
But yes, I could be wrong.

reply via email to

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