Key bindings proposal [Was: Emacs learning curve]

Key bindings proposal [Was: Emacs learning curve]

[Uday S Reddy]

Stephen J. Turnbull writes:

> It's trivial to change key bindings.  M-x local-set-key RET
> <keys-to-define> <command-name> RET and Bob's your uncle.  Or maybe
> you want a swap-keys command that would have the UI M-x swap-keys RET
> <keys1> <keys2>.  I don't have that function on the top of my head,
> but I'm pretty sure it requires at most three lines to express.

Hi Stephen, I was going to reply to this originally saying that
`local-set-key' and `global-set-key' are destructive change operations
which shouldn't be taken lightly.  They are kind of heavy duty hammers
that are looking for nails to hit on and of course everything looks
like a nail.

I thought better of it because this thread had already been too long
and wandering.  But a post in the gnu.emacs.help newsgroup today
prompted me to come back to it.  The poster says:

> For example now I just installed ruby-tests.el from emacswiki, which (I
> saw too late) unfortunately has some "global-set-keys" with combinations
> that normally I use for other things.

> Is there any way to revert back to the last global state (it might be
> useful also in other cases of cours)?

If Emacs did take key binding customization seriously, it would have
provided a whole bunch of *declarative* methods for specifying key
bindings, along with rules for how they override each other or not
override, as the need may be.  If and when a set of key bindings needs
to be installed (e.g., when a mode is entered), it would go and
compile the key bindings from all the sources, detect conflicts if
necessary, and install the right set.  The user would be protected.
The user wouldn't have to mess with mode-hooks or whatever.  

This is not an out-of-the-world idea.  Almost all customization
systems out there work this way.

Instead, Emacs acts rather like a grumpy child that believes that it
has the best key bindings already cased.  And, local-set-key and
global-set-key are like "if you really must change a key binding,
well, go right ahead.  Go and change all the key bindings if you want.
I don't care."  A totally unhelpful attitude.

Yidong asked for a specific proposal if there is one.  So, here is
mine:

    Redesign Emacs so that key bindings can be designed by end users
    or third party customizers and exchanged with each other.  It
    should be possible to change the entire set of key bindings in a
    running Emacs with the click of a button.  If there are conflicts
    between different sets of key bindings that users import, there
    should be clear rules for what to do in such a case, an analysis
    of what goes wrong and gentle feedback given to the users.

    If you think that Emacs is alredy capable of doing all of this,
    then demonstrate it by implementing a radically different set of
    key bindings.  Show the users how it can be done.

Cheers,
Uday

PS: By the way, I sort of speak from experience here.  I had RSI some
15 years ago and explored a whole bunch of options for how to change
things, including going to Vim or Viper, using speech recognition,
hand-writing etc.

Key bindings proposal [Was: Emacs learning curve]

[Stephen J. Turnbull]

Uday S Reddy writes:

 > Yidong asked for a specific proposal if there is one.  So, here is
 > mine:

This is not a specific proposal.  This is waving hands over an
enormous cowpie.  I'm sorry, but you've managed to get pretty much all
of the standard misunderstandings exhibited by the CUA-by-default
advocates into a single post.  I hope you don't feel too battered when
I'm done debunking them.

 > Stephen J. Turnbull writes:
 > 
 > > It's trivial to change key bindings.  M-x local-set-key RET
 > > <keys-to-define> <command-name> RET and Bob's your uncle.  Or maybe
 > > you want a swap-keys command that would have the UI M-x swap-keys RET
 > > <keys1> <keys2>.  I don't have that function on the top of my head,
 > > but I'm pretty sure it requires at most three lines to express.
 > 
 > Hi Stephen, I was going to reply to this originally saying that
 > `local-set-key' and `global-set-key' are destructive change operations
 > which shouldn't be taken lightly.

In context of this thread, that's what was wanted: a permanent change
(to CUA by default).  I think you're missing the point, or perhaps
simply don't understand how keymapping works in Emacs if you think
that's an important criticism of my statement.

Bringing up broken ruby-related software, well, too bad for the rubes.
It's always possible to abuse flexibility, and you know that crap
would never get into Emacs as is.

If a safe change to the global keymap is wanted, do

(defvar saved-global-keymaps nil)
(push global-keymap saved-global-keymaps)
(setq global-keymap (copy-keymap global-keymap))

(In practice it would be simpler than that, but this shows the most
general pattern.)  Yes, it would be tedious to do this for a lot of
keymaps, but it could be done, and there are only about a half-dozen
important ones that more or less *must* be protected.  The reason
Emacs doesn't do this already is that it's not useful without a
concrete proposal ("concrete" is defined below).

 > If Emacs did take key binding customization seriously, it would have
 > provided a whole bunch of *declarative* methods for specifying key
 > bindings, along with rules for how they override each other or not
 > override, as the need may be.

I'm flabbergasted.  What do you think a keymap is, if it isn't
declarative?  What do you think the cascade of keymaps, inheritance,
and the like is, if not a set of rules for precedence?

 > If and when a set of key bindings needs to be installed (e.g., when
 > a mode is entered), it would go and compile the key bindings from
 > all the sources, detect conflicts if necessary, and install the
 > right set.  The user would be protected.

If you don't think Emacs has this feature already, what's your
explanation for the coexistence of CC-mode (in multiple variants!),
Gnus, VM, and AUCTeX in the same Emacs process?

 > The user wouldn't have to mess with mode-hooks or whatever.

Configurable commands are a separate problem from changing bindings of
keys to commands, although obviously they are closely related in the
user's experience.  That is out of context (it's about [remap command]
specifically, not the problem of keymap conflicts), anyway.

 > This is not an out-of-the-world idea.  Almost all customization
 > systems out there work this way.

What you imply here is nonsense.  First, an Emacs keymap has semantics
nearly identical to what you claim you want.  Second, almost all
customization systems deal with very sparse keymaps, which makes
collisions relatively unlikely.  (BTW, IME none of them work well in
practice; I have yet to find a GNOME-compatible WM whose stock
bindings don't conflict with some application (usually Emacs :-).)
Not so for Emacs, which gave up on "keymap wall-paper" when the
wallpaper exceeded the area available on the Great Wall of China,
ca. 1986.

Look up "whack-a-mole effect" on wikipedia.  That, not poor design, is
why default Emacs keymappings are hard to change.  If you don't need
the default bindings at all, you can go wild.  Cf. Gnus or viper.

 > Yidong asked for a specific proposal if there is one.  So, here is
 > mine:
 >
 >     Redesign Emacs so that key bindings can be designed by end users
 >     or third party customizers and exchanged with each other.

Don't you think you really ought to learn how Emacs works before
suggesting that a redesign is needed?

I'm really tired of hearing that Emacs is poorly designed in this
respect.  Sure, I disagree with the [remap command] feature, but
that's minor, micro, nano, pico.  Maybe even femto.

 >     It should be possible to change the entire set of key bindings
 >     in a running Emacs with the click of a button.

It is possible.  What do you think "M-x gnus" (or "M-x viper") does?

The problem is "to what?"  The "concrete" part of "concrete proposal"
is a request to exhibit a reasonably complete alternative keymap.
Without that, the whole exercise is pointless.

 >     If there are conflicts between different sets of key bindings
 >     that users import, there should be clear rules for what to do
 >     in such a case, an analysis of what goes wrong and gentle
 >     feedback given to the users.

This is not possible IMSEO.  The problem is the whack-a-mole effect.
You want to put something on C-x C-s, Emacs comes back with

    Please, be careful.  The old binding to `save-buffer' is very
    important.  If you really want to bind C-x C-s, you should put
    `save-buffer' on another key sequence.  I can do that for you.
    Choose a key sequence, or type C-g for none [C-x C-# C++ u r k]: _

After getting that warning for about seven commands in succession (the
suggested keysequence "C-x C-# C++ u r k" isn't very appetizing :-),
the user is not going to feel gently about the process of rebinding
commands.  And it's about three orders of magnitude worse if you're
trying to design a new keymap "for the rest of us", who are hardly a
group with homogeneous requirements.

Cf. also the wild popularity (not) of
http://www.jwz.org/software/xkeycaps.  Great program with an excellent
interface, but do Gentle Newbies use it?  Uh-uh.

The problem is that *nothing* goes *wrong*!  Keymaps, for all the
discussion spent on the colors of their bikesheds, are *arbitrary* (if
you start from scratch).  Even arbitrary alterations to the
traditional full keymap can be correct depending on the user's intent.
The whole problem here is specifying what users want, not implementing
a set of requirements once you've got them.

Specifying the requirements here involves, at a guess, thousands of
interrelated decisions.  If you want them made, maybe you should get
started instead of asking Emacs developers, who would rather do
something else, to do it.

 >     If you think that Emacs is alredy capable of doing all of this,
 >     then demonstrate it by implementing a radically different set of
 >     key bindings.  Show the users how it can be done.

Why should I reinvent the wheel?  It's been done, multiple times.
CUA, viper, Gnus, and hey, *you* are the maintainer of VM, no?  *You*
show them radically different keybindings, they're right there at your
fingertips.

If you want a permutation of the default bindings for fundamental and
the other "most common" modes, no, I don't think that's my job.  The
people who want that should produce it.  viper is a fairly good
example already, I should think.

Re: Key bindings proposal

[Stefan Monnier]

> If Emacs did take key binding customization seriously, it would have
> provided a whole bunch of *declarative* methods for specifying key
> bindings, along with rules for how they override each other or not
> override, as the need may be.

I understand what you want.  But, I'm not 100% sure what a good solution
would look like, and I'm even less clear on how we could get to such
a solution starting from Emacs's current system.

The main problem is not whether the method is declarative or not, but
rather the problem is to make intentions clear.

The issue with "intentions" is typically along the lines of "do you want
to bind `foo' to C-x C-x or do you want to bind it to the C-x key within
the main prefix keymap, or do you want to bind it to the repetition of
the key-sequence to which this main keymap is bound, or maybe only to
the repetition of just the last key in this key-sequence, or maybe to
the repetition of C-"the key above my "alt" key, or maybe you want to
bind it to whichever key `foobar' is bound in such-and-such-mode, ..."

If all Emacs packages could replace their `define-key' calls by others
that make the intentions clear, then it would be a lot easier/cleaner to
redefine key-bindings.

But if you look at the average quality of Elisp code, you'll quickly
learn that most authors have much better things to do than to worry
about such problems (i.e. their main worry is to get it to work for
the very specific Emacs they're currently using, with their current
.emacs).

Using `remap' is one way to express such an intention.
I would welcome patches that try to make intentions more clear
(e.g. eliminate the massive hardcoding of the "C-c" prefix all over the
place) and have myself replaced bindings to TAB and to M-q many times by
settings of indent-line-function and fill-paragraph-functions.  We can
keep improving in that direction, but the important part is that such
changes should be made in such a way that it's easy for coder to follow
the new style (ideally: easier than using the old inflexible style).

> it would go and compile the key bindings from all the sources, detect
> conflicts if necessary, and install the right set.

That's yet more difficult.  It means that the author and/or the user
needs to explicitly indicate when something should take precedence over
something else, and when not.  In most cases I know of, this tends to be
too heavy to use and instead the system is designed to use a default
precedence scheme (witness the "use first matching pattern" rule in
ML-style or Prolog pattern matching).
So I'd expect "conflict detection" to come with a lot of user complaints
(already we have occasional bug-reports about the errors signaled by
define-key when you define a binding for C-a C-b when C-a is already bound
to a command).


        Stefan

Re: Key bindings proposal

[Eric M. Ludlam]

On 07/27/2010 06:32 AM, Stefan Monnier wrote:
>> If Emacs did take key binding customization seriously, it would have
>> >  provided a whole bunch of*declarative*  methods for specifying key
>> >  bindings, along with rules for how they override each other or not
>> >  override, as the need may be.
> I understand what you want.  But, I'm not 100% sure what a good solution
> would look like, and I'm even less clear on how we could get to such
> a solution starting from Emacs's current system.
>
> The main problem is not whether the method is declarative or not, but
> rather the problem is to make intentions clear.
>
> The issue with "intentions" is typically along the lines of "do you want
> to bind `foo' to C-x C-x or do you want to bind it to the C-x key within
> the main prefix keymap, or do you want to bind it to the repetition of
> the key-sequence to which this main keymap is bound, or maybe only to
> the repetition of just the last key in this key-sequence, or maybe to
> the repetition of C-"the key above my "alt" key, or maybe you want to
> bind it to whichever key `foobar' is bound in such-and-such-mode, ..."

Hi,

While it may not cover the gamut of possible keybinding remapping, one 
way to express intention is to make all the commands that get bound into 
global maps be overridable in some way.  Some commands like 
beginning/end of line have this feature already.  Modes of all sorts 
would then override the behavior they want to change instead of binding 
their custom functions to keys.

This would then make it much easier to just move all the Emacs core 
commands around while allowing the modes to follow easily.

Using something like mode-local.el is one way to do this in a 
declarative way which I used extensively in CEDET.

Eric

Re: Key bindings proposal

[Stephen J. Turnbull]

Stefan Monnier writes:

 > The issue with "intentions" is typically along the lines of "do you want
 > to bind `foo' to C-x C-x or do you want to bind it to the C-x key within
 > the main prefix keymap, or do you want to bind it to the repetition of
 > the key-sequence to which this main keymap is bound, or maybe only to
 > the repetition of just the last key in this key-sequence, or maybe to
 > the repetition of C-"the key above my "alt" key, or maybe you want to
 > bind it to whichever key `foobar' is bound in such-and-such-mode,
 > ..."

In most cases the intention is "bind it to a short sequence I
personally don't use otherwise, and otherwise arbitrary," I would
expect.

 > Using `remap' is one way to express such an intention.

Not really.  Remap is about deprecating a command, not really about
key sequence choice.  People who are worried about mapping issues
define whole keymaps (viz Miles's caps-lock-mode, with *one* binding
in it).  People who aren't, don't.  The question here is whether
you're willing to make life painful for people who don't pay attention
to keymaps *as maps* to force them to pay attention to keymaps:

 > I would welcome patches that try to make intentions more clear
 > (e.g. eliminate the massive hardcoding of the "C-c" prefix all over
 > the place)

Heh.  Just make define-key error on any keysequence with a prefix
bound to a keymap, unless there's a nonnil FORCE argument.

Alternatively, you could have define-key normally recurse into keymaps
the way lookup-key and *-key-binding do, unless there's a non-nil
FORCE argument.

Re: Key bindings proposal

[Stefan Monnier]

> In most cases the intention is "bind it to a short sequence
> I personally don't use otherwise, and otherwise arbitrary,"
> I would expect.

Indeed, that's how it's been used, and it works OK for such uses.

>> Using `remap' is one way to express such an intention.
> Not really.  Remap is about deprecating a command, not really about
> key sequence choice.

Not at all.  `remap' is typically not used by the user in his .emacs but
by major/minor modes to locally/temporarily replace particular commands
by other ones (and to do so in a declarative way ;-), so that if the
user (or some other mode) has rebound this command elsewhere, the
remapping still works as intended.  Before that, packages used
substitute-key-definition for that purpose, but that was not as
declarative and it only adapted to changes in global bindings.


        Stefan

Re: Key bindings proposal

[Uday S Reddy]

Stefan Monnier writes:

> Not at all.  `remap' is typically not used by the user in his .emacs but
> by major/minor modes to locally/temporarily replace particular commands
> by other ones (and to do so in a declarative way ;-), so that if the
> user (or some other mode) has rebound this command elsewhere, the
> remapping still works as intended.  Before that, packages used
> substitute-key-definition for that purpose, but that was not as
> declarative and it only adapted to changes in global bindings.

Indeed.  Not only is it declarative, but it is also object-oriented
(or "subtyped" or "conformant").

When you bind [remap undo] to a mode-specific undo operation, you are
inheriting the key binding made for undo somewhere else.  At least for
this operation, you are conforming to some global theme that has been
established for the user.

The world outside Emacs is heavily object-oriented.  And, that has
brought a tremendous amount of order to the world of user interfaces.
We take it for granted that every application will have a suitable
implementation for generic operations like "open", "close", "refresh"
and "help".  Unfortunately, all of this civilizational progress is
passing Emacs by.  Just a few weeks ago, somebody here was bemoaning
how the inconsistency of "refresh" in Emacs modes drives him nuts.

However, I think we can do better than remap.  remap allows ad-hoc
inheritance to grow up in fits and sneezes wherever it feels like.  It
is not proper subtyping.  Oscar Fuentes had a proposal here on 7/17
which I am drawn to:

> I possible solution for this problem is to use `actions'. An action is a
> generic concept like `fordward-line', or `undo', or `save', or `yank'
> (`paste', if you prefer.)  `universal-argument',
> `execute-extended-command' and `C-x' (whatever is officially called on
> Emacs jargon) would be actions as well.
> 
> Currently a mode defines its keymap relating keys to functions. An
> action-aware mode relates actions to functions. At a higher level, there
> is a mapping of keys into actions. When a mode is activated for a
> buffer, the keymap is constructed looking up the corresponding keys
> assigned to the actions the mode implements. A mode inherits the
> key->action mapping from its parent mode, but can define its own actions
> that overrides its parent's.

It seems to me that these "actions" are a form of abstract operations.
The actions implemented by a mode can be regarded as its interface.
Some of these actions might have globally defined key bindings, some
might be local, and some might have no key bindings.  It might be
possible to invoke actions with the M-x prefix or something like it.
Emacs would immediately feel a lot more object-oriented than it
currently does.

Cheers,
Uday

Re: Key bindings proposal

[Miles Bader]

Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:
> It seems to me that these "actions" are a form of abstract operations.
> The actions implemented by a mode can be regarded as its interface.

I think it's a good idea (and have advocated it before), but no, it
won't solve the problem of re-skinning.  It would be nice for bringing a
bit of order to commonly used operations, treated as singular events,
but it does not do anything for uncommon operations -- which are
probably the _majority_ of bindings in emacs (as opposed to simple
editors like notepad) -- nor does it offer any help in avoiding
conflicts (the "whack-a-mole problem" as someone in this thread so aptly
put it) or preserving patterns which are an important feature of Emacs'
current bindings or [e.g. the "n/f type bindings go forward", etc].

The thing is, so far everybody advocating "binding change" has been
waving their hands, making vague feel-good statements, trotting out
buzzwords, etc -- but to _really_ do it, somebody has to sit down and
actually work out the painful details of how to handle the problems.

Hand-waving and buzzwords aren't enough.

-Miles

-- 
Any man who is a triangle, has thee right, when in Cartesian Space,
to have angles, which when summed, come to know more, nor no less,
than nine score degrees, should he so wish.  [TEMPLE OV THEE LEMUR]

Re: Key bindings proposal

[Stefan Monnier]

>> It seems to me that these "actions" are a form of abstract operations.
>> The actions implemented by a mode can be regarded as its interface.

> I think it's a good idea (and have advocated it before),

Yes, although we already do have something similar:
- the function-key-map can be used to map <key-sequence> to
  <logical-key>, where logical key is similar to <action>.  It is not
  used much in this way (mostly for TAB and DEL and a handful more at
  best).
- the key remapping (where the remapped command acts as the <action> as
  well as its default binding).
- things like fill-paragraph-function, line-indent-function, ...

The last one is usually the most effective (since it can affect several
related bindings at the same time, and do it in the right way).

> but no, it won't solve the problem of re-skinning.

Indeed.

> problem" as someone in this thread so aptly put it) or preserving
> patterns which are an important feature of Emacs' current bindings or
> [e.g. the "n/f type bindings go forward", etc].

For these, I think it would be good to be able to have "(de?)composed
bindings", where you could bind `n' and `f' to some special keymap-like
thingies and then therein bind C-, M-, and M-C- to other special thingies.

The intention would be to reflect the structure directly into
the keymap.  This would apply to several other cases.


        Stefan

Re: Key bindings proposal

[Stephen J. Turnbull]

Stefan Monnier writes:

 > >> Using `remap' is one way to express such an intention.
 > > Not really.  Remap is about deprecating a command, not really about
 > > key sequence choice.
 > 
 > Not at all.  `remap' is typically not used by the user in his .emacs but
 > by major/minor modes to locally/temporarily replace particular commands
 > by other ones

So what?  Presumably there is some mnemonic relationship between the
old command and the new one, otherwise it would make more sense to
choose a mnemonic key sequence and not use remap.  Ie, it's about the
commands, not the keys.

I don't see how this use of remap helps Uday or the
CUA-should-be-default crowd, since much of the time no such
relationship applies.  For example, `forward-sexp' is hardly useful in
VM Summary mode, but that doesn't mean that

(define-key vm-summary-map [remap 'forward-sexp] #'vm-summary-next)

makes any sense whatsoever.

(define-key vm-summary-map [remap next-line] #'vm-summary-next)

does make sense to me, but guess what?  #'next-line is a useful
command in VM Summary mode, even if much less useful than it is in
most modes.  So I'd be very bummed if Uday used [remap] instead of an
explicit keystroke binding there.

Re: Key bindings proposal

[Uday S Reddy]

Stephen J. Turnbull writes:

> I don't see how this use of remap helps Uday or the
> CUA-should-be-default crowd, since much of the time no such
> relationship applies.  

This is not a solution to the broad problem I posed.  I shouldn't
pretend that it is.  But it helps partially in the following sense.

The irritation for the user is that it is not enough to just rebind
keys at the global level, but he/she must go and rebind them for every
mode.  The latter is hard, and one needs to be reasonably expert at
the innards of Emacs to do it correctly.  The remap idea helps in that
the modes can piggy back on the global bindings at least to some
extent.  

But the applicability is limited.  I was just looking at dired-mode,
which seems to have some 100 odd key-bindings, but only 2 remap's.
Not much of a win.  To catch the majority of the other generic
bindings, something like the "action" idea seems necessary.

> (define-key vm-summary-map [remap next-line] #'vm-summary-next)
> 
> does make sense to me, but guess what?  #'next-line is a useful
> command in VM Summary mode, even if much less useful than it is in
> most modes.  So I'd be very bummed if Uday used [remap] instead of an
> explicit keystroke binding there.

You are right.  But, if there were action-based bindings, I could do:

(define-key vm-summary-map [action quick-next-line] #'vm-summary-next)

and the quick-next-line action might be bound to the key `n' (or `C-n'
or `M-n' or whatever else the user might wish).  Gnus, Dired,
buff-menu and a host of other modes that need "quick" actions could
all share their key bindings without having to do anything.

Cheers,
Uday

Re: Key bindings proposal

[Stephen J. Turnbull]

Uday S Reddy writes:
 > Stephen J. Turnbull writes:
 > 
 > > I don't see how this use of remap helps Uday or the
 > > CUA-should-be-default crowd, since much of the time no such
 > > relationship applies.  
 > 
 > This is not a solution to the broad problem I posed.  I shouldn't
 > pretend that it is.  But it helps partially in the following sense.
 > 
 > The irritation for the user is that it is not enough to just rebind
 > keys at the global level, but he/she must go and rebind them for every
 > mode.

IME, users just don't do this, or want to do it; I really don't
understand what you're talking about.  Please be more specific about
the use cases.

In any case, your claim is mostly false for the keys where any of the
redesign vaporware could apply.  In most modes, the mode keymap is
sparse; most of the shared bindings like self-insert-command, movement
commands, file opening commands, and buffer-switching commands are
*inherited* from the global map.  They don't need to be changed.  Most
of the remaining bindings are very specialized; it's likely that any
replacements will also be idiosyncratic.  IOW, remap only helps if the
user (or a minor mode) is already moving the command around in the
map.  Sure, occasionally it's useful or perhaps necessary.  But how
can that be a good idea on a regular basis?

 > The remap idea helps in that the modes can piggy back on the global
 > bindings at least to some extent.

They already do in a big way, of course -- at least, I'd like to say
"of course", but evidently you don't know about it. :-(

 > But the applicability is limited.  I was just looking at dired-mode,
 > which seems to have some 100 odd key-bindings, but only 2 remap's.
 > Not much of a win.  To catch the majority of the other generic
 > bindings, something like the "action" idea seems necessary.

Sure, but we already have a concept of `action' (ie, a symbol denoting
a function): most Emacs commands follow this pattern.  Most "generic"
bindings are simple enough to just inherit from the global map
*already*.  Complex generic bindings like "fill-paragraph" and
"revert-buffer" provide hooks *already* so that modes can augment or
even entirely replace default implementations.

 > You are right.  But, if there were action-based bindings, I could do:
 > 
 > (define-key vm-summary-map [action quick-next-line] #'vm-summary-next)

This extra indirection is *useless*; its entire functionality is
already subsumed by `defun' and `remap'.  You *must* defun
`vm-summary-next', doing so creates no extra work.  For the generic
version,

(defun next-line-and-operate ()
  "Move to the next line in a buffer and operate on the line.

Useful in modes that use buffer lines as a menu-like device."
  (interactive)
  ;; do something intuitive and possibly useful
  (next-line))

and finally in `vm-mode' or whatever

(define-key ACTION-MAP [remap next-line-and-operate] #'vm-summary-next)

(where ACTION-MAP might be the global map or some sort of sharable
map, maybe a minor mode map would do).

However, it's not at all obvious to me that this is a better idea than

(defvar operate-on-line-function nil)
(make-variable-buffer-local 'operate-on-line-function)

(defun next-line-and-operate ()
  (interactive)
  (when operate-on-line-function
    (funcall operate-on-line-function)))

and in vm-summary.el

(unless operate-on-line-function
  (setq operate-on-line-function #'vm-summary-recenter))

(or whatever it is that `vm-summary-next' does after `next-line').
The point is that the `operate-on-line' function can be shared among
next-, previous-, and goto-line-and-operate.  Possibly others
(`incremental-search-and-operate-on-line', anyone?)

 > or `M-n' or whatever else the user might wish).  Gnus, Dired,
 > buff-menu and a host of other modes that need "quick" actions could
 > all share their key bindings without having to do anything.

Uh, what's a "quick action"?  (I have no clue what you mean by that,
except "like vm-summary-next", which leaves a host of possibilities.)
Do you have a list of them?  Does your list agree with those of the
maintainers of Gnus, Dired, buff-menu, and a host of other
maintainers?  Do you all agree that you want these actions on the same
keys?

If you can get definition, list, and agreement with *some* modes for
*some* "actions", you can get started.  If you do actually make any
progress, let me know; I'll port/implement [remap] in XEmacs (and
SXEmacs if they don't have it yet).

Re: Key bindings proposal

[Uday S Reddy]

Stephen J. Turnbull writes:

> IME, users just don't do this, or want to do it; I really don't
> understand what you're talking about.  Please be more specific about
> the use cases.

I refer you to Teemu Likonen's post on the July 17, especially his
comment that "there's not enough abstraction on that front [the key
bindings of modes".  In fact, a good part of the discussion in the
"Emacs learning curve" was about the difficulty of changing key
bindings, why the CUA mode can't be made the default etc.

At least one use case that seems to be implemented in Gnu Emacs is to
bind [remap undo] in modes that need it.  So, if a user binds C-z to
undo, he/she gets the appropriate undo in all modes (as long as they
use remap for the key).

I don't know if remap helps for rebinding C-c and C-x.  That seems
like too hard a problem for remap.

The current practice is not necessarily indicative of what the users
want to do.  Many of us expected the key bindings of Emacs to be
customizable, tried it, found it to be too hard and gave up.  Some
people persist because it is really important to them.  It is their
exasperation that keeps this debate alive.

> In any case, your claim is mostly false for the keys where any of the
> redesign vaporware could apply.  In most modes, the mode keymap is
> sparse; most of the shared bindings like self-insert-command, movement
> commands, file opening commands, and buffer-switching commands are
> *inherited* from the global map.  They don't need to be changed.

It might have been Barbara Liskov that said that the inheritance of
implementation is not all that interesting, but the inheritance of
interface is the interesting one.  A have heard the comment from a lot
of other people too.  So, let us take inheritance of implementation
for granted.  There is nothing in particular to be said about it.

remap allows you to inherit the interface (key-binding) and plug in a
new implementation.  

> Most of the remaining bindings are very specialized; it's likely
> that any replacements will also be idiosyncratic.  IOW, remap only
> helps if the user (or a minor mode) is already moving the command
> around in the map.  Sure, occasionally it's useful or perhaps
> necessary.  But how can that be a good idea on a regular basis?

It is most helpful for people who want to move commands around the
map, and they might want to do it on a regular basis.  

But I am proposing that "actions" should also be usable with the M-x
prefix (or some similar prefix, since people will complain if the
semantics of M-x is changed).  So, one should also be able to do `M-x
undo' in a dired buffer and get `dired-undo', and get `vm-undo' in a
VM buffer and so on.  This doesn't seem too hard to implement, but it
requires us to separate the idea of actions/interfaces from keymaps.

[Why allow this?  Some people, me included, prefer to use memorable
function names instead of remembering zillion key bindings.  At the
moment, the long names are made longer by the mode name prefixes like
"dired-", "vm-" etc.  It would be preferable to have simpler, general
action names.  

If one uses speech recognition, key bindings are basically useless and
actually get in the way.  One would unbind all plain keys, and utter
function names instead.  Having to utter "dired blah" for every dired
command is extremely cumbersome.  So, we end up creating an additional
layer of indirection at the speech level, translating "blah" into
"dired blah".  I don't yet see how the "action" idea can help with
that.  But I am hopeful.]

Thirdly, I am proposing that interface inheritance need not only be
from the global-keymap, but it could also be from generic
local-keymaps.  So, there could be, for instance, a
generic-quick-actions keymap, which normally binds `n' to a
`quick-next-line' action, `x' to a `quick-expunge' action etc.  Both
dired and VM could use this keymap, so that the user gets uniformity
of key bindings.  Moreove, the user can rebind keys in this generic
keymap, e.g., move `quick-expunge' to `#' and leave `x' unbound.  That
would take effect in all modes that implement the
generic-quick-actions keymap.  That is a big win.

You asked what "quick" actions are.  They are the things that one
would normally bind to plain keys.  For example, `n' would be bound to
`quick-next-line' whereas `C-n' is bound to `next-line'.  How
`quick-next-line' is performed is for the modes to determine.  Dired
might just do `next-line' in response, but VM Summary mode might
display the next email message.

> Sure, but we already have a concept of `action' (ie, a symbol denoting
> a function): most Emacs commands follow this pattern.  Most "generic"
> bindings are simple enough to just inherit from the global map
> *already*.  Complex generic bindings like "fill-paragraph" and
> "revert-buffer" provide hooks *already* so that modes can augment or
> even entirely replace default implementations.

Actions are *not* symbols denoting functions.  They are symbols that
sit on their own.  They are bits of interfaces.

It is possible, as you note, to make interfaces just be ordinary
functions with dummy implementations.  Smalltalk did that, but I think
they found that the take-up was sporadic.  Most developers just did
implementation-inheritance and didn't bother with interface
inheritance.  On the other hand, when Java added interfaces as a first
class concept, it had better success with the take-up.

> Uh, what's a "quick action"?  (I have no clue what you mean by that,
> except "like vm-summary-next", which leaves a host of possibilities.)
> Do you have a list of them?  Does your list agree with those of the
> maintainers of Gnus, Dired, buff-menu, and a host of other
> maintainers?  Do you all agree that you want these actions on the same
> keys?

I am not too fussed about the "quick" keyword.  It was just the first
thing that came to mind.  Perhaps "modal" to mean that it depends on
the mode.

I am hoping that we all don't have to agree on the keys.  The whole
idea is to empower the user to allow for his/her favorite key
bindings.  But the actions, we would have to agree on, as far as the
common actions go.  That seems nontrivial, but not insurmountable.

> If you can get definition, list, and agreement with *some* modes for
> *some* "actions", you can get started.  If you do actually make any
> progress, let me know; I'll port/implement [remap] in XEmacs (and
> SXEmacs if they don't have it yet).

Ok, we have a deal!

Cheers,
Uday

Re: Key bindings proposal

[Stephen J. Turnbull]

Uday S Reddy writes:
 > Stephen J. Turnbull writes:

 > > IME, users just don't do this, or want to do it; I really don't
 > > understand what you're talking about.  Please be more specific
 > > about the use cases.
 > 
 > I refer you to Teemu Likonen's post on the July 17, especially his
 > comment that "there's not enough abstraction on that front [the key
 > bindings of modes".

That's not a use case.  A use case is a specific usage or programming
problem, typically with data, which can be addressed by providing code.

As much as I respect Teemu, as a matter of free software development
practice, theoretical claims of lack of abstraction are much more
likely to be lack of understanding on the claimant's part than of
actual language design deficiencies.  The only way to demonstrate it
is to give a concrete use case showing how the abstraction could be
used to do something that cannot be done concisely in the stock
language.  It's not your job to prove it can't be done, it's our job
to show how the use case can be addressed in idiomatic, stock elisp.
But conversely, it's your job, not ours, to provide the use case.

 > In fact, a good part of the discussion in the "Emacs learning
 > curve" was about the difficulty of changing key bindings, why the
 > CUA mode can't be made the default etc.

Sure, but this is not a user use case either.  It has nothing to do
with users specifying keymaps, it's about a lack of choice of keymap.
That is because developers don't provide keymaps.

I have seen zero evidence that "redesigning the key mapping system" is
anything but a hobgoblin of lazy folks who want work done but are
unwilling to bear the burden themselves.  It's true that laziness is
the Mother of Hackerly Invention, but this is the wrong kind of
laziness.  The Keymap Problem is a *combinatorial explosion* problem,
not a *data structures + algorithms* problem.

The only way to solve the Keymap Problem is to start enumerating the
combinations.

 > At least one use case that seems to be implemented in Gnu Emacs is to
 > bind [remap undo] in modes that need it.  So, if a user binds C-z to
 > undo, he/she gets the appropriate undo in all modes (as long as they
 > use remap for the key).

Right, so users don't need to know about [remap] (in the sense above,
it is NOT a user use case), and Emacs already has the necessary
structures.  The problem is identifying more of these use cases, and
changing modes to respect them.  (N.B. Stefan has been doing this for
years; I imagine he'd appreciate help.)

 > I don't know if remap helps for rebinding C-c and C-x.  That seems
 > like too hard a problem for remap.

Again, I have no clue what you're talking about.  Is this the CUA
bogeyman again?  Several people have pointed out that rebinding C-c
and C-x are actually (conceptually) easy because they're bound to
keymap variables (not even keymaps).  The pragmatic problem is that
many modes, especially minor modes, don't use those keymaps
(especially the C-c map) properly.  A SMOP.

It might be possible to change `define-key' so that it starts in the
indicated keymap, but instead of simply installing a mapping for a key
sequence in the indicated keymap, it recurses into subkeymaps bound to
prefixes of the sequence and changes only the ultimate binding.  This
is a bit delicate because of key sequences common across modes; you'd
need to be sure you're binding the in the mode-specific keymap.

 > The current practice is not necessarily indicative of what the
 > users want to do.  Many of us expected the key bindings of Emacs to
 > be customizable, tried it, found it to be too hard and gave up.

I'm not talking about current practice, I'm talking about what
questions users post.  What did you try to customize and find to be
too hard?  Maybe the particular task *is* hard (whacking the mole aka
enumerating all combinatorial possibilities).  Maybe it's just tedious
and you lost patience, but it could easy if you asked somebody like
Stefan or Miles to cook up a helper function (eg, to swap keys is a
nearly trivial example).  But if you don't ask *here*, why would you
expect these helper functions to exist?

And I don't understand what could be so hard about keymapping.
Keymaps are a little bit complex because of inheritance.  But you
asked for inheritance and object-orientation, so I assume you
understand them.  Is it that you don't understand keymaps as objects?
Is it that whacking the mole gets tedious?

 > Some people persist because it is really important to them.  It is
 > their exasperation that keeps this debate alive.

Let them stew in their exasperation if they refuse to learn or ask to
be taught.

 > It might have been Barbara Liskov that said that the inheritance of
 > implementation is not all that interesting, but the inheritance of
 > interface is the interesting one.  A have heard the comment from a lot
 > of other people too.  So, let us take inheritance of implementation
 > for granted.  There is nothing in particular to be said about it.

The keymap, not the individual keybinding, *is* the interface, and it
*does* provide inheritance of interface, in several ways, including
via [remap].

"The" Emacs keymap is a highly compressed and dynamic specification of
how to accomplish pretty much all personal information processing
tasks without ever resorting to a named command or menu.  Note
"compressed".  Just as there really is no good way to locally edit a
zipped file -- you need to decompress, edit, and recompress it --
there is not going to be a good *universal* way to "locally edit" the
keymap.  Not *-set-key, not define-key, and not [remap].

The keymap *does* have more structure than a zipfile, of course.  For
very minor (one new keystroke) additions, there is the reserved
personal bindings C-c <letter>.  Keymaps are recursive; ie, a
keystroke may be bound to a keymap.  If you respect this structure,
you *can* do local editing of the keymap; this is precisely how minor
modes work.

But making random changes and hoping the rest of the keymap will
pure-f'cking-magically rearrange itself, sorry, All Hope Abandon Ye.

 > But I am proposing that "actions" should also be usable with the M-x
 > prefix (or some similar prefix, since people will complain if the
 > semantics of M-x is changed).  So, one should also be able to do `M-x
 > undo' in a dired buffer and get `dired-undo', and get `vm-undo' in a
 > VM buffer and so on.  This doesn't seem too hard to implement, but it
 > requires us to separate the idea of actions/interfaces from
 > keymaps.

It does not.  It is *already* implemented, cf. fill-paragraph,
comment-region, etc. etc.  I showed how to implement this in
boilerplate for "quick actions", and even pointed out that this method
probably leads to internal simplification of modes like VM and Gnus,
as well as cross-mode code sharing between them!  You've got egg in
your beer right there, what do you want, a birthday cake too?

It already dramatically sucks that other commands with substantial
commonality across modes do not share code.  The proposal to define
actions would institutionalize a worst practice, don't you see?  It
would encourage modes to write completely independent implementations
(so much for quoting Liskov; inheriting implementation is *not*
trivial; it needs to be encouraged by interface!)

 > [Why allow this?

That's not the question.  It's already allowed and encouraged, it's
just that mode writers are too lazy to do it well.

 > It would be preferable to have simpler, general action names.

You already have them, via remap.  It's just a simple matter of going
through all the keymaps and identifying the generic actions, and
replacing mode-specific bindings with remaps.  This would have to be
done with a separate action feature, too.

 > Thirdly, I am proposing that interface inheritance need not only be
 > from the global-keymap, but it could also be from generic
 > local-keymaps.

Yes, [remap] gives you that, too.

 > You asked what "quick" actions are.  They are the things that one
 > would normally bind to plain keys.

Yeah, I kinda thought you'd say something like that.  The problem is
this:

 > Actions are *not* symbols denoting functions.  They are symbols that
 > sit on their own.  They are bits of interfaces.

Well, yes, symbols sit on their own, and are interfaces.  However,
there *must* be a common functional semantics for each symbol, or
there is no point in having a common interface.

 > It is possible, as you note, to make interfaces just be ordinary
 > functions with dummy implementations.  Smalltalk did that, but I think
 > they found that the take-up was sporadic.  Most developers just did
 > implementation-inheritance and didn't bother with interface
 > inheritance.  On the other hand, when Java added interfaces as a first
 > class concept, it had better success with the take-up.

Ah, I see.  Your true goal here is to make programming in Emacs LISP
at least as painful as programming in Java.  Good luck getting takeup
on that! :-)

The point is that unless you make actions *mandatory*, as Java does
(and as C++ does), you still won't get any takeup, because it's a
*rule*, and if there's one thing Emacs hackers have trouble doing,
it's following rules.

BTW, I'm not so sure about the success of Java interfaces.  From
comments on various VCS lists (!), I gather that arsing around with
interfaces is one of the most enthusiasm-draining tasks in Java.

 > I am not too fussed about the "quick" keyword.  It was just the first
 > thing that came to mind.  Perhaps "modal" to mean that it depends on
 > the mode.

I'm not fussed about the word, either (but "modal" is a terrible word,
since the point of having common actions is the commonality across
modes, not the differences).  I'm fussed about the ambiguity and the
lack of a list.  Don't you see, the whole problem is constructing the
list?  The rest is a SMOP.  And in this case the MOP truly is S.  It's
also VT (for very tedious).

 > I am hoping that we all don't have to agree on the keys.

For remap, there needs to be a default binding, or it won't work.

In the case of a separate set of actions, you don't need to agree on
keys, that's true.  The tradeoff is that the most likely outcome will
be that 3rd party modes will define their own actions rather than look
up the generic ones.  Cf. /usr/include/X11/*key*.h.  So you'll need to
do substantial work defining them, and educating mode hackers to use
them.  Cf. "Emacs hackers and rules" above.  I don't envy you that
task. ;-)

Note that you also have to define the interface to each action.  Users
will not be pleased to discover that C-u C-z means something quite
different (eg, redo vs. undo 4 times) when in VM than when in Gnus.
One advantage of the remap approach is that generally there will be
existing default implementations that can be overridden.

 > The whole idea is to empower the user to allow for his/her favorite
 > key bindings.

That idea is dead in the water, and sinking fast.  By your own
testimony, you weren't able to do that.  In general, the best that
users will be able to do is select from a menu of pre-designed
keymaps.  A few users will do things like swap bindings they use
frequently with more convenient keys whose bindings they don't use
much, but that's probably as far as it will go.

What *can* happen here is to make the task of designing keymaps a
little more attractive to developers, since setting up a new keymap
based on an existing group of generic commands or actions will work
for all modes using that group of generic commands.  Specifically, it
might make sense for somebody to design a quick-action-map as you
suggest, and then graft that on to VM, Gnus, dired, PCL-CVS, etc.

I suspect you will find that process a lot more painful than you
expect, though.

 > But the actions, we would have to agree on, as far as the common
 > actions go.  That seems nontrivial, but not insurmountable.

Agreed.

Re: Key bindings proposal

[Uday S Reddy]

Stefan Monnier writes:

> The main problem is not whether the method is declarative or not, but
> rather the problem is to make intentions clear.

The reason for asking for declarative methods is that they are easier
for users and/or third-party customizers to deal with.  The
whac-a-mole effect is hard enough for them to address.  Side-effects
would introduce unseen interactions which would make it even harder to
figure out what is going on.

The way X windows deals with X resources is a perfectly fine way to
provide customization information.  I don't see why we can't duplicate
that in Emacs.

> The issue with "intentions" is typically along the lines of "do you want
> to bind `foo' to C-x C-x or do you want to bind it to the C-x key within
> the main prefix keymap, or do you want to bind it to the repetition of
> the key-sequence to which this main keymap is bound, or maybe only to
> the repetition of just the last key in this key-sequence, or maybe to
> the repetition of C-"the key above my "alt" key, or maybe you want to
> bind it to whichever key `foobar' is bound in such-and-such-mode, ..."
> 
> If all Emacs packages could replace their `define-key' calls by others
> that make the intentions clear, then it would be a lot easier/cleaner to
> redefine key-bindings.

It is laudable goal, but I think it may be way too ambitious.  If you
can try and do it for one mode out there and demonstrate how it can be
done, then we could make some progress.

But I have a feeling that we have the key binding stuff blown way out
of proportion.  When RMS started Gnu Emacs, he seemed to have a clear
sense that the most important and frequently used functions would be
bound to keys, the rest would be done using M-x.  But that idea is
totally lost now.  Most Emacs coders today seem to think that every
function has to be on a key or people won't use it.  And the key
combinations keep getting weirder and weirder.  Like M-s a C-s to do
an isearch!  

It would be a good idea for us to question ourselves why we are so
obsessed with key bindings whereas the rest of the world gets by
perfectly fine with very few key bindings.  Here are two answers that
come to my mind (and perhaps there are others).

- In most modern OS's, one can navigate menus with keys.  Emacs
doesn't use this mode of usage at all.  The menu items don't have key
strokes associated with them, and the menus look totally
disorganized.  In principle, this can give us much more "real estate"
to work with, without having to memorize arcane key bindings that make
our fingers twist.

- We have totally ignored the potential of command names.  I can type
`M-x isearch' a lot faster than I can type `M-s a C-s', but the later
is supposed to a holy cow whereas "isearch" doesn't exist as a
concept.  Why can't we have two name spaces of global commands and
local commands, and bind them to functions?

I am not digressing.  If we can start exploring some of these other
options, they can reduce the burden that the key bindings are having
to carry at the moment.

> But if you look at the average quality of Elisp code, you'll quickly
> learn that most authors have much better things to do than to worry
> about such problems (i.e. their main worry is to get it to work for
> the very specific Emacs they're currently using, with their current
> .emacs).

Then let us discourage them from binding too many keys, and leave it
to the users to bind their own keys.  There is only a limited amount
of key space out there!  The predefined key bindings are even
defeating the remap-bindings as we have just discovered.

> That's yet more difficult.  It means that the author and/or the user
> needs to explicitly indicate when something should take precedence over
> something else, and when not.  In most cases I know of, this tends to be
> too heavy to use and instead the system is designed to use a default
> precedence scheme (witness the "use first matching pattern" rule in
> ML-style or Prolog pattern matching).
> So I'd expect "conflict detection" to come with a lot of user complaints
> (already we have occasional bug-reports about the errors signaled by
> define-key when you define a binding for C-a C-b when C-a is already bound
> to a command).

My feeling is that, if we have a decent infrastructure for developing
and exchanging keymaps, people will do the work for themselves.  (I
recall that when X Windows first started, people found it to be a
nightmare to customize them.  But, very quickly, people started
writing .Xdefaults files and exchanging them and the knowhow spread
around.  We can ask ourselves why people find it so much harder to do
keymaps as compared to Xdefaults.)

I guess we will discover what precedence rules are needed as we play
with these features.  For instance, it would have been much nicer if
remap had precedence over the hard-coded bindings whereas it is the
other way around at present.  I think it would be best if the user can
say which way the precedence should go.

I will continue playing with the features you mentioned and see how
well they work.

Cheers,
Uday

Re: Key bindings proposal

[Andreas Röhler]

Am 29.07.2010 17:28, schrieb Uday S Reddy:
> Stefan Monnier writes:
>
>    
>> The main problem is not whether the method is declarative or not, but
>> rather the problem is to make intentions clear.
>>      
> The reason for asking for declarative methods is that they are easier
> for users and/or third-party customizers to deal with.  The
> whac-a-mole effect is hard enough for them to address.  Side-effects
> would introduce unseen interactions which would make it even harder to
> figure out what is going on.
>
> The way X windows deals with X resources is a perfectly fine way to
> provide customization information.  I don't see why we can't duplicate
> that in Emacs.
>
>    
>> The issue with "intentions" is typically along the lines of "do you want
>> to bind `foo' to C-x C-x or do you want to bind it to the C-x key within
>> the main prefix keymap, or do you want to bind it to the repetition of
>> the key-sequence to which this main keymap is bound, or maybe only to
>> the repetition of just the last key in this key-sequence, or maybe to
>> the repetition of C-"the key above my "alt" key, or maybe you want to
>> bind it to whichever key `foobar' is bound in such-and-such-mode, ..."
>>
>> If all Emacs packages could replace their `define-key' calls by others
>> that make the intentions clear, then it would be a lot easier/cleaner to
>> redefine key-bindings.
>>      
> It is laudable goal, but I think it may be way too ambitious.  If you
> can try and do it for one mode out there and demonstrate how it can be
> done, then we could make some progress.
>
> But I have a feeling that we have the key binding stuff blown way out
> of proportion.  When RMS started Gnu Emacs, he seemed to have a clear
> sense that the most important and frequently used functions would be
> bound to keys, the rest would be done using M-x.  But that idea is
> totally lost now.  Most Emacs coders today seem to think that every
> function has to be on a key or people won't use it.  And the key
> combinations keep getting weirder and weirder.  Like M-s a C-s to do
> an isearch!
>
> It would be a good idea for us to question ourselves why we are so
> obsessed with key bindings whereas the rest of the world gets by
> perfectly fine with very few key bindings.  Here are two answers that
> come to my mind (and perhaps there are others).
>
> - In most modern OS's, one can navigate menus with keys.  Emacs
> doesn't use this mode of usage at all.  The menu items don't have key
> strokes associated with them, and the menus look totally
> disorganized.  In principle, this can give us much more "real estate"
> to work with, without having to memorize arcane key bindings that make
> our fingers twist.
>
> - We have totally ignored the potential of command names.

Hi,

thanks mentioning it. Also command names are mnemonic, while keys are not.
BTW Info should always start with the command name IMHO, delivering the 
default key-binding secondly only.

Andreas

--
https://code.launchpad.net/~a-roehler/python-mode
https://code.launchpad.net/s-x-emacs-werkstatt/


>    I can type
> `M-x isearch' a lot faster than I can type `M-s a C-s', but the later
> is supposed to a holy cow whereas "isearch" doesn't exist as a
> concept.  Why can't we have two name spaces of global commands and
> local commands, and bind them to functions?
>
> I am not digressing.  If we can start exploring some of these other
> options, they can reduce the burden that the key bindings are having
> to carry at the moment.
>
>    
>> But if you look at the average quality of Elisp code, you'll quickly
>> learn that most authors have much better things to do than to worry
>> about such problems (i.e. their main worry is to get it to work for
>> the very specific Emacs they're currently using, with their current
>> .emacs).
>>      
> Then let us discourage them from binding too many keys, and leave it
> to the users to bind their own keys.  There is only a limited amount
> of key space out there!  The predefined key bindings are even
> defeating the remap-bindings as we have just discovered.
>
>    
>> That's yet more difficult.  It means that the author and/or the user
>> needs to explicitly indicate when something should take precedence over
>> something else, and when not.  In most cases I know of, this tends to be
>> too heavy to use and instead the system is designed to use a default
>> precedence scheme (witness the "use first matching pattern" rule in
>> ML-style or Prolog pattern matching).
>> So I'd expect "conflict detection" to come with a lot of user complaints
>> (already we have occasional bug-reports about the errors signaled by
>> define-key when you define a binding for C-a C-b when C-a is already bound
>> to a command).
>>      
> My feeling is that, if we have a decent infrastructure for developing
> and exchanging keymaps, people will do the work for themselves.  (I
> recall that when X Windows first started, people found it to be a
> nightmare to customize them.  But, very quickly, people started
> writing .Xdefaults files and exchanging them and the knowhow spread
> around.  We can ask ourselves why people find it so much harder to do
> keymaps as compared to Xdefaults.)
>
> I guess we will discover what precedence rules are needed as we play
> with these features.  For instance, it would have been much nicer if
> remap had precedence over the hard-coded bindings whereas it is the
> other way around at present.  I think it would be best if the user can
> say which way the precedence should go.
>
> I will continue playing with the features you mentioned and see how
> well they work.
>
> Cheers,
> Uday
>
>
>    

Re: Key bindings proposal

[Mathias Dahl]

> function has to be on a key or people won't use it.  And the key
> combinations keep getting weirder and weirder.  Like M-s a C-s to do
> an isearch!

I just use C-s. In my Emacs the binding you mention does not exist, so it is
probably a quite new invention. And my guess is that it is there for
completeness, someone
decided (I did not even know about M-s until now and I have used Emacs
since 1997) to
keep all search related stuff on M-s and for completeness isearch was
placed there too.
I assume the idea is to type M-s to get into "search mode" and from
there type a few keys
to execute the particular search command you want. I agree that the
extra "a C-s" lacks a
good "flow". Why not just "a s" (what does the "a" stand for?). But,
again, isearch has its own
top level binding, so most will use that.

> It would be a good idea for us to question ourselves why we are so
> obsessed with key bindings whereas the rest of the world gets by
> perfectly fine with very few key bindings.

I have asked myself the same thing. I think in many other programs
users use the menus
(using the mouse) and/or the toolbar and other widgets. Around me, at
work, very few people
use the keybindings  that do exists in those other programs. They
limit themselves to cut,
paste, copy, save and new, at tops.

> - In most modern OS's, one can navigate menus with keys.  Emacs
> doesn't use this mode of usage at all.

I see very few navigating the menus by keys although I find this to be
an excellent replacement when
a command does not have its own keybinding. After some tries I learn
the path to the command I want
so that it in practice gets a keybinding (like M-f s, or whatever).

> ... and the menus look totally disorganized.

Oh come on. There might be some items that are not where you would
expect but to say
that the menus look totally disorganized is unfair. Why not suggest a
new structure in a new thread?

> In principle, this can give us much more "real estate"
> to work with, without having to memorize arcane key bindings that make
> our fingers twist.

M-x is right there, no one forces you to use arcane bindings (I agree
that some are, for example
those starting with C-@, which is very hard to type on a Swedish
keyboard layout) and you can use F10
to reach the menus, or M-x tmm to navigate the menus as text. Or use
the mouse (Gaaaah! :)

> - We have totally ignored the potential of command names.

Oh, have "we"? I use M-x all the time and have learned how to use
partial completion to more quickly
execute commands with long names.

>  I can type
> `M-x isearch' a lot faster than I can type `M-s a C-s'

Again, its there for completeness (my guess anyway). Use C-s instead
if this is something you do a lot.

Re: Key bindings proposal

[Uday S Reddy]

On 7/31/2010 8:16 AM, Mathias Dahl wrote:

> I just use C-s. In my Emacs the binding you mention does not exist, so it is
> probably a quite new invention.

I think we are talking at cross purposes.  This whole discussion has been about 
how to organize the key bindings for local keymaps set up by Emacs modes in 
such a way that users can modify them easily.  Modifying the global bindings is 
a piece of cake.  So, they are not under discussion.  (Well, not as far as they 
don't impinge on local keymaps.)

M-s a C-s is indeed a recent key binding.  The  ChangeLog.14 file gives a date 
of 2008-07-28, and grep shows that there are four modes that use it: buff-menu, 
dired, ibuffer and vc-dir.  I was giving this as an example of how Emacs 
developers feel *compelled* to put functions on keys.  The reasons could be (a) 
they believe that all commands are supposed to be on keys, or (b) they think 
the users won't use them otherwise, or (c) they think the users won't notice 
them otherwise.

The problem (a) is a policy issue.  I don't know if there is a policy that all 
commands are supposed to be on keys.  But, if there is one, it can be changed 
easily.  So, this is not a big deal.

The problem (b) is a real one.  Practically nobody is going to type M-x 
dired-do-isearch to invoke this function.  So, even these twisted key bindings 
will probably get used by those that need them.

My idea was why can't one type something like "M-x isearch" to get this 
function, instead of "M-x dired-do-isearch" which is too long-winded and "M-s a 
C-s" which is too twisted and unmemorable?  This requires a new concept for 
Emacs, bindable command names that can vary across modes.  (Stephen Turnbull is 
going to say that you can already get its effect through some other means. 
That is all well and good.  The discussion right now is really about how to set 
up an architecture that is functional for the users.  Not everything whose 
effect can be achieved by other means becomes part of the architecture unless 
we use it appropriately!)

The problem (c) is a real one too.  But the solution is self-defeating.  Once 
all the developers start scrambling for the limited keymap space in an effort 
to attract the users' attention, the keymaps grow and grow and they stop 
attracting anybody's attention.  To get to C-s a M-s in the dired-mode's doc 
string, I had to do some 12 page-downs!  Doubtless my attention has wandered 
off before then.

I stopped reading mode doc-strings somewhere around Emacs 19, when they started 
getting longer than Unix man pages.  (And, I stopped using Unix when its man 
pages became unreadable too.)  Fortunately, Emacs has info, which I use 
regularly.  But my impression is that the vast majority of Emacs users don't 
use info.  Xah Lee is right that the info manual has begun to read more and 
more like a PhD thesis than a user manual, and unfit to look up information 
quickly unless you already know its structure well.  But let me not go into 
that issue here.

Keyboard navigation of the menubar is a potential solution for both the 
problems (b) and (c).  But, as I mentioned earlier, this idea hasn't yet been 
taken seriously in Emacs.  The menu entries don't have key strokes associated 
with them.  At least on Windows, one can get to each menu item by typing the 
first letter of the item.  But this gets tedious if

- there are many menu items starting with the same letter (for example, look 
under the "Mark" menu in dired) and

- when there is no way to sort the menu items alphabetically.

On second thought, perhaps the menus are not as disorganized as I had imagined. 
  I haven't yet begun to use them seriously.  Since you seem to have first-hand 
experience with their use, I should go by your word that they work well.  I 
would personally prefer if the menu items had key strokes associated with them 
rather than the default first-letter-selection mechanism.  This would also be 
in line with all the well-designed GUI applications out there.

Coming back to the original issue, the over-reliance on key bindings gets in 
the way of users trying to move the key bindings around.  Even the remapping 
idea, which is good in concept, is defeated if the mode developers have 
hard-wired key bindings.  And, a lot of the time the mode developers have used 
up pretty much all the key space there is.  So, the remapping idea becomes useless.

To give a concrete example, let us say that a user wants to use i-j-k-m 
mnemonics for movement instead of p-b-f-n.  He can bind C-m to next-line etc at 
the top-level however hard it might be.  But then every mode will probably have 
some bindings that depend on the p-b-f-n mnemonics.  The dired mode had C-n 
bound to dired-next-line, which has now been changed to [remap next-line]. 
That helps the user.  But dired mode also has `n' bound to dired-next-line.  It 
is not possible to move it to `m' by remapping.  In some other modes (e.g., VM 
summary mode), C-n is not used, but just `n' for the mode-specific movement. 
Thus the user has to solve the same problem again and again.  This is not the 
whac-a-mole problem because it is the *same* mole that crops up in each mode, 
not a different one.

So, the more keys the developers bind, the harder it is for the users to move 
them around.  Getting away from the key binding culture will help such users.

Cheers,
Uday

Re: Key bindings proposal

[Alan Mackenzie]

Good afternoon, Uday!

On Sat, Jul 31, 2010 at 11:04:50AM +0100, Uday S Reddy wrote:
> On 7/31/2010 8:16 AM, Mathias Dahl wrote:

> >I just use C-s. In my Emacs the binding you mention does not exist, so it 
> >is probably a quite new invention.

> I think we are talking at cross purposes.  This whole discussion has been 
> about how to organize the key bindings for local keymaps set up by Emacs 
> modes in such a way that users can modify them easily.  Modifying the 
> global bindings is a piece of cake.  So, they are not under discussion.  
> (Well, not as far as they don't impinge on local keymaps.)

How often do users want to do a massive rebinding of keys?  Approximately
never is the answer.

> M-s a C-s is indeed a recent key binding.  The  ChangeLog.14 file gives a 
> date of 2008-07-28, and grep shows that there are four modes that use it: 
> buff-menu, dired, ibuffer and vc-dir.  I was giving this as an example of 
> how Emacs developers feel *compelled* to put functions on keys.  The 
> reasons could be (a) they believe that all commands are supposed to be on 
> keys, or (b) they think the users won't use them otherwise, or (c) they 
> think the users won't notice them otherwise.

Oh come on, get real!  Many, possibly most, commands are unusable by
typing M-x plus <command name>.  Not all commands have keybindings, not
by a long shot.  The scenario you've pictured is ludicrous.

> The problem (a) is a policy issue.  I don't know if there is a policy that 
> all commands are supposed to be on keys.  But, if there is one, it can be 
> changed easily.  So, this is not a big deal.

You're turning into something like a conspiracy theorist here.  It is
simply the case that typing a key sequence is easier and faster than M-x
+ name.  There is no policy involved such as you've sketched.

> The problem (b) is a real one.  Practically nobody is going to type M-x 
> dired-do-isearch to invoke this function.  So, even these twisted key 
> bindings will probably get used by those that need them.

Your (a), (b) and (c) aren't problems to anybody bar yourself.

> My idea was why can't one type something like "M-x isearch" to get this 
> function, instead of "M-x dired-do-isearch" which is too long-winded and 
> "M-s a C-s" which is too twisted and unmemorable?  This requires a new 
> concept for Emacs, bindable command names that can vary across modes.  

Well, for deity's sake stop flooding this mailing list with long screeds
and start hacking out a solution.  If you think you can show something is
a good idea, and expect "Somebody" (tm) to code it up for you, you're
mistaken.  That's not the way development groups work, at least not this
one.  If you really believe you've identified problems, fix them!

> (Stephen Turnbull is going to say that you can already get its effect 
> through some other means. That is all well and good.  The discussion right 
> now is really about how to set up an architecture that is functional for 
> the users.  Not everything whose effect can be achieved by other means 
> becomes part of the architecture unless we use it appropriately!)

Design and code up that architecture.  Post a patch on this mailing list.
Then, and only then, will your ideas get taken seriously.

> The problem (c) is a real one too.  But the solution is self-defeating.  
> Once all the developers start scrambling for the limited keymap space in an 
> effort to attract the users' attention, the keymaps grow and grow and they 
> stop attracting anybody's attention.  To get to C-s a M-s in the 
> dired-mode's doc string, I had to do some 12 page-downs!  Doubtless my 
> attention has wandered off before then.

> I stopped reading mode doc-strings somewhere around Emacs 19, when they 
> started getting longer than Unix man pages.  (And, I stopped using Unix 
> when its man pages became unreadable too.)  Fortunately, Emacs has info, 
> which I use regularly.  But my impression is that the vast majority of 
> Emacs users don't use info.  Xah Lee is right that the info manual has 
> begun to read more and more like a PhD thesis than a user manual, and unfit 
> to look up information quickly unless you already know its structure well.  
> But let me not go into that issue here.

OK, I will instead.  Yes, it takes time to learn to use Emacs's info
pages, but once you've learned how they work, they are a joy to use.  A
bit like Emacs itself.

> Keyboard navigation of the menubar is a potential solution for both the 
> problems (b) and (c).  But, as I mentioned earlier, this idea hasn't yet 
> been taken seriously in Emacs.

Well YOU start taking it seriously.  Or have you done so already?

> The menu entries don't have key strokes associated with them.  At least
> on Windows, one can get to each menu item by typing the first letter of
> the item.  But this gets tedious if

> - there are many menu items starting with the same letter (for example, 
> look under the "Mark" menu in dired) and

> - when there is no way to sort the menu items alphabetically.

Contribute such a sorting.

> On second thought, perhaps the menus are not as disorganized as I had 
> imagined. I haven't yet begun to use them seriously.  Since you seem to 
>  have first-hand experience with their use, I should go by your word that 
> they work well.  I would personally prefer if the menu items had key 
> strokes associated with them rather than the default first-letter-selection 
> mechanism.  This would also be in line with all the well-designed GUI 
> applications out there.

All, or nearly all, of the mouse ambages have keyboard equivalents.  What
I think you mean is that they are not all displayed in the menu.  I agree
with you that they probably should be, but I can't be bothered any more
than you can about implementing this; I don't even use menus in Emacs.

> Coming back to the original issue, the over-reliance on key bindings gets 
> in the way of users trying to move the key bindings around.  Even the 
> remapping idea, which is good in concept, is defeated if the mode 
> developers have hard-wired key bindings.  And, a lot of the time the mode 
> developers have used up pretty much all the key space there is.  So, the 
> remapping idea becomes useless.

Read the elips page on bindings.  The key bindings C-c C-<letter> are
allocated to major modes.  C-c <letter> are allocated to users.  Other
C-c bindings are allocated to minor modes.  Mode developers tend to stay
within these strictures.

> To give a concrete example, let us say that a user wants to use i-j-k-m 
> mnemonics for movement instead of p-b-f-n.  He can bind C-m to next-line 
> etc at the top-level however hard it might be.  But then every mode will 
> probably have some bindings that depend on the p-b-f-n mnemonics.  The 
> dired mode had C-n bound to dired-next-line, which has now been changed to 
> [remap next-line]. That helps the user.  But dired mode also has `n' bound 
> to dired-next-line.  It is not possible to move it to `m' by remapping.  In 
> some other modes (e.g., VM summary mode), C-n is not used, but just `n' for 
> the mode-specific movement. Thus the user has to solve the same problem 
> again and again.  This is not the whac-a-mole problem because it is the 
> *same* mole that crops up in each mode, not a different one.

> So, the more keys the developers bind, the harder it is for the users to 
> move them around.  Getting away from the key binding culture will help such 
> users.

Then get hacking, and sort this "problem" out!  I honestly can't see what
all the big fuss is about.  Your solution will involve an immense amount
of work amending Info pages and doc strings, for questionable benefit.

Just because Emacs is very configurable, it doesn't follow that extreme
customisation should be made very easy, at the cost of who knows what.
I've only seen one other person wanting this, his name's Xah Lee, and
he's forked Emacs to do this.  Search for "ergoemacs" to find it.

> Cheers,
> Uday

-- 
Alan Mackenzie (Nuremberg, Germany).

RE: Key bindings proposal

[Drew Adams]

I really do not want to go down the rat hole of this thread.  But I will make a
couple of comments.  Suffice it to say, beyond these comments, that I agree with
those old diehards ;-) who have been trying to say that this thread is misguided
in general.

> My idea was why can't one type something like "M-x isearch" 
> to get this function, instead of "M-x dired-do-isearch"
> which is too long-winded and "M-s a C-s" which is too
> twisted and unmemorable?  This requires a new concept

In many or most cases, the mode's specialized version of a command does not
simply replace that command in all situations or for all purposes.

That is the case here, for example.  You might well want to use the general
command `isearch' (e.g. `C-s') in a Dired buffer, in addition to wanting (for
other purposes) to use the more specialized command `dired-isearch-filenames'
(bound to `M-s f C-s').  The latter does not simply replace the former for
everything when in Dired.

You are wrong in assuming that a subtype/subclass analogy holds in general for
this kind of thing.  `dired-isearch-filenames' is not `isearch', and both can be
useful in Dired mode.

Not to mention `dired-do-isearch', which is the command that you mentioned.
That command is for searching within the marked files themselves.  It has
nothing to do with searching within the Dired buffer (`isearch').

(Did you notice the similarity: `M-s f C-s', `M-s a C-s'?  There is a
key-binding logic here.  You might prefer a different logic, but there is one.)

> To get to C-s a M-s in the dired-mode's doc string, I had
> to do some 12 page-downs!

Obviously, in a mode as rich as Dired, you should not expect to use `C-h m' as
your primary means of discovery of what is possible in Dired.

Menus.  Menus.  Menus.  Menus are your friend.  Menus are an excellent way to
_discover_ features, including command names and key bindings.

The menu for a mode tells you about its main features, organizes them in some
logical or pedagogical way, and gives you the keyboard shortcuts for the menu
items.

Menus are _organized_, and that is one of their main advantages for discovery
and memory (infrequent access).  What was that command/key that let me do
such-and-such?  You can try `apropos' and `C-h b', but you can also explore
menus to take advantage of their logical organization.  If you're not doing
this, then I suggest you're missing the boat.

Yes, Emacs menus are not always as good as they could be, partly because the
Emacs developers who add a feature have already discovered it. ;-)

In Dired, the `Operate' menu (the one for operating on marked files), has these
menu items:

 Isearch Files...                    M-s a C-s
 Isearch Regexp Files...             M-s a C-M-s

And the `Immediate' menu has these:

 Isearch in File Names...            M-s f C-s
 Isearch Regexp in File Names-...    M-s f C-M-s

[Personally (dired+.el), I put the latter items on the `Subdir' menu, not on the
`Immediate' menu - they are not actions that apply to a single file.  (And I
rename `Immediate' to `Single', `Operate' to `Multiple', and `Subdir' to
`Dir'.)]

Perhaps these same search items should also appear on the `Search' menu (under
`Edit').

But the point is that you should, like newbies everywhere (and we are all
newbies in some contexts) use _menus_, not just `C-h m' or `C-h b', to discover.
To discover, use menus, use the fine manual, and use `apropos'.

Wrt the key bindings for these commands: Again, there is a logic there - a logic
that facilitates discovery and memory.  And you can easily use your own,
personally superior, alternative bindings.

And you need not use any binding if you prefer to use a command or menu.  It is
trivial in Emacs to get the command name from the menu item (here, but not
always - e.g. easymenu): `C-h k'.  And it is trivial to provide a shorter
command name (alias) if you want to use `M-x my-foo' instead of `M-x
the-long-weird-obscure-fooish-command'.

Honestly, I do not know of an application where it is so easy to discover and
access commands as it is in Emacs.

Could discovery be even easier?  Yes, IMO.  Icicles users have the equivalent of
`apropos' available on the fly every time they use the minibuffer for anything.
Could the menus be improved?  Yes.  Could menu access from the keyboard be
improved?  Yes, IMO (though `tmm' is OK) - La Carte, especially together with
Icicles, gives you excellent menu access and menu discovery from the keyboard.

And other improvements are always possible.  But Emacs is _better_, not worse,
than most apps wrt command discovery and access.

The complaints here about weird Emacs keybindings are surprising to me, coming
from you, Uday, who are familiar with Emacs.  They sound like the superficial
comments of a vi'er or someone unfamiliar with Emacs - someone who has the
impression that one is _required_ to use `M-x a C-s' in order to search.  It is
trivial to use `M-x', trivial to use the menu, and trivial to bind a simpler key
to something that you use often.

> I stopped reading mode doc-strings somewhere around Emacs 19, 
> when they started getting longer than Unix man pages.

I'm the opposite.  I like a mode doc string that gives me almost a mini-manual
for the feature (mode).  People are different.  But a doc string is not intended
to _replace_ a manual.  That is why doc strings link to the manual (or they
should more often), as well as to Customize.

> (And, I stopped using Unix when its man pages became
> unreadable too.) 

Wow, that's quite extreme.  With GNU/Linux you can of course help improve the
man pages. ;-)

> Fortunately, Emacs has info, which I use regularly.

Amen.

> But my impression is that the vast majority of Emacs users don't 
> use info.

I do not have that impression.  What makes you think that?

> Xah Lee is right that the info manual has begun to read more
> and more like a PhD thesis than a user manual,

I disagree.  I use Emacs 20 often, and I do not see any special trend/change
from Emacs 20 to Emacs 24 that could be so characterized.  And I do not find
either the 20 or 24 manual to be thesis-like.  It is true that some sections are
more difficult to read than others - they are more reference-like.

The Emacs manual is not just a user manual in the sense of an intro,
guide-you-by-the-hand, user guide.  It is that to some extent, but it is also a
_reference_ manual.  Likewise (even more so), the Elisp manual.

> and unfit to look up information quickly unless you
> already know its structure well.

Dunno why you say that.  But there are ways to improve Info as well, and some of
them have recently been added to vanilla Emacs (mostly by Juri).  Virtual books,
history lists, etc. speak directly to the "structure".  If you use Icicles then
you have even more help navigating Info and dealing with its structure.  

> But let me not go into that issue here.

Yes, a separate thread please, if you really want to get into Info.

> Keyboard navigation... hasn't yet been taken seriously in
> Emacs.  The menu entries don't have key strokes associated 
> with them.

See above.  You're wrong on both counts, IMO: keyboard navigation of menus and
presence of keyboard-shortcut indications in menu items.

> At least on Windows, one can get to each menu 
> item by typing the first letter of the item.
> But this gets tedious if
> - there are many menu items starting with the same letter 
>   (for example, look under the "Mark" menu in dired) and
> - when there is no way to sort the menu items alphabetically.

Try Icicles and La Carte.  You can easily sort items on the fly and you can
easily get to any item, no matter where it is in the menu tree.

I'm not trying to pitch Icicles or La Carte here.  I'm trying to say that Emacs
can easily give excellent menu access and provide excellent menu discovery.  Out
of the box it is OK, and it could easily be made even better.

> On second thought, perhaps the menus are not as disorganized 
> as I had imagined. I haven't yet begun to use them seriously.

Please do.  You will thank yourself.  And you will no doubt file menu bugs or
enhancement requests or provide patches for improvements.  Welcome.

I agree that Emacs menus could be improved.  Emacs developers do not always take
them very seriously.  But you do - or will ;-).

> Coming back to the original issue, the over-reliance on key 
> bindings

That is a misconception.  Think of key bindings as an extra, if you like.  Use
commands and menus most of the time, if you like.  Emacs does not require anyone
to use keys all the time or even most of the time.

> the mode developers have used up pretty much all the
> key space there is.

It is trivial to define your own, preferred key bindings.  Think of the existing
bindings as a default, fallback behavior.  Or think of them as only suggestions.
Define your own, if you like.  As others have said here, there is a reason to
Emacs's key-binding madness, but you are free to ignore that organization,
especially in any given context/mode.

> So, the more keys the developers bind, the harder it is for 
> the users to move them around.  Getting away from the key
> binding culture will help such users.

I think you misunderstand the "key binding culture".  But I won't get into a
discussion about it with you.  I already wrote more than I intended to.  If what
I wrote helps, fine.  If not, ignore.  IMO, this discussion has not been and
will probably not be very fruitful.  But don't let that single opinion stop you.
;-)

And I do hope that you will help concretely to improve Emacs menus and manuals.
Dealing with a concrete problem/improvement is more likely to yield results than
is initiating a general or vague discussion about revamping Emacs.

Of course, for fundamental change we would need fundamental discussion.  But I
don't see that need the way you do.  I think you misunderstand some of the
existing design.  That doesn't mean that your observations can't be helpful.
But I suspect that if you attack more specific targets/needs then everyone will
learn more and there will be more improvement.  Just a suggestion.

RE: Key bindings proposal

[Uday S Reddy]

Drew Adams writes:

> I really do not want to go down the rat hole of this thread.  But I
> will make a couple of comments.  Suffice it to say, beyond these
> comments, that I agree with those old diehards ;-) who have been
> trying to say that this thread is misguided in general.

Dear Drew, the point of this thread is to explore possible technical
solutions to the problems that have been raised in the previous
threads: "emacs learning curve", "efforts to attract more users" etc.
Instead of having religious debates about which key bindings are
better and which bindings should be used and whether there is any need
to change key bindings at all etc., my idea is that, if Emacs provides
the right set of technical tools allowing users to rebind keys, then
more people will be satisfied.  So, this is a *technical* discussion.
If people want to continue the religious debates, they can go back to
the old threads and extend them.

> In many or most cases, the mode's specialized version of a command
> does not simply replace that command in all situations or for all
> purposes.

As I said in my reponse to Tassilo, there is no intent to replace the
global search commands.  `M-x isearch' is meant to represent a generic
operation that will be defined in specific modes like dired (and
Buffer menu, VM, Gnus etc.)  People that like to type `M-s a C-s' can
happily go on typing it.  But that doesn't have to be the only way to
invoke this function.

> Menus.  Menus.  Menus.  Menus are your friend.  Menus are an
> excellent way to _discover_ features, including command names and
> key bindings.

Glad we agree on something!

> Could discovery be even easier?  Yes, IMO.  Icicles users have the
> equivalent of `apropos' available on the fly every time they use the
> minibuffer for anything.  Could the menus be improved?  Yes.  Could
> menu access from the keyboard be improved?  Yes, IMO (though `tmm'
> is OK) - La Carte, especially together with Icicles, gives you
> excellent menu access and menu discovery from the keyboard.
> 
> And other improvements are always possible.  But Emacs is _better_,
> not worse, than most apps wrt command discovery and access.

Oh, that self-congratulation again!  At least on Windows, you don't
need any special libraries to access the stadard menubar by keyboard.
If you press the Alt-key once, the menubar gets selected.  Then you
type keys as follows (in the dired-mode menubar):

  o - goes to Options
  o - goes to Operate
  RET - selects the Operate menu
  i - goes to Isearch Files
  RET - selects Isearch Files

A Windows developer or Java developer that cares about access would
have also associated key strokes with each menu title and menu item.
These appear as underscored characters in the menus.  For instance,
one could have chosen `p' in `Operate' as the selected key
stroke. Then typing `p' would have taken you directly to `Operate'
without stopping at `Options'.  When there are unique key strokes
associated with the menu items, no RET character is needed for
selection.  So, in an accessible Windows application, the above
navigation could have been done with 2 keystrokes instead of the 5
that Emacs requires.  This is something like 10-15 year old
technology.  Just open Thunderbird and play with keys to navigate the
menus.  You will get the idea.

Do you still want to claim that Emacs is better than most apps for
access?

When I talk about associating key strokes with menu items, people here
don't even seem to know what I am talking about!

> The complaints here about weird Emacs keybindings are surprising to
> me, coming from you, Uday, who are familiar with Emacs.  They sound
> like the superficial comments of a vi'er or someone unfamiliar with
> Emacs - someone who has the impression that one is _required_ to use
> `M-x a C-s' in order to search.  It is trivial to use `M-x', trivial
> to use the menu, and trivial to bind a simpler key to something that
> you use often.

I didn't "complain" about the weird key bindings.  I gave the weird
bindings as an example to talk about the over-reliance of Emacs on key
bindings.  Obviously the developers went to the weird keys after all
the normal keys were exhausted.  But, unless there were idle normal
keys, the `remap' idea - proposed by Stefan as a possible solution for
local key bindings - is ineffective.  At best, it can protect the
global key bindings as you go down to modes.  But it doesn't help the
problem of local key bindings.

What I have been arguing for is the idea of abstract commands (a
variant of Oscar's "actions").  It is a clean solution,
well-understood in programming language theory, and I think it can be
made to work for Emacs modes.

> Try Icicles and La Carte.  You can easily sort items on the fly and
> you can easily get to any item, no matter where it is in the menu
> tree.

Can they match the 3-key stroke access (Alt p i) to "Isearch Files" in
the dired menu?

> > On second thought, perhaps the menus are not as disorganized as I
> > had imagined. I haven't yet begun to use them seriously.
> 
> Please do.  You will thank yourself.  And you will no doubt file
> menu bugs or enhancement requests or provide patches for
> improvements.  Welcome.

I will be quite happy to use menus if the menu items have keystrokes
associated with them like on Windows & Java applications.  Without
that, they are quite inefficient.  

I will check to see if La Carte and Icicles can help.

Cheers,
Uday

RE: Key bindings proposal

[Drew Adams]

> > Could discovery be even easier?  Yes, IMO.  Icicles users have the
> > equivalent of `apropos' available on the fly every time they use the
> > minibuffer for anything.  Could the menus be improved?  Yes.  Could
> > menu access from the keyboard be improved?  Yes, IMO (though `tmm'
> > is OK) - La Carte, especially together with Icicles, gives you
> > excellent menu access and menu discovery from the keyboard.
> > 
> > And other improvements are always possible.  But Emacs is _better_,
> > not worse, than most apps wrt command discovery and access.
> 
> Oh, that self-congratulation again!  At least on Windows, you don't
> need any special libraries to access the stadard menubar by keyboard.
> If you press the Alt-key once, the menubar gets selected.  Then you
> type keys as follows (in the dired-mode menubar):
> 
>   o - goes to Options
>   o - goes to Operate
>   RET - selects the Operate menu
>   i - goes to Isearch Files
>   RET - selects Isearch Files
> 
> A Windows developer or Java developer that cares about access would
> have also associated key strokes with each menu title and menu item.
> These appear as underscored characters in the menus.  For instance,
> one could have chosen `p' in `Operate' as the selected key
> stroke. Then typing `p' would have taken you directly to `Operate'
> without stopping at `Options'.  When there are unique key strokes
> associated with the menu items, no RET character is needed for
> selection.  So, in an accessible Windows application, the above
> navigation could have been done with 2 keystrokes instead of the 5
> that Emacs requires.  This is something like 10-15 year old
> technology.  Just open Thunderbird and play with keys to navigate the
> menus.  You will get the idea.

AFAIK, Lennart added support for the MS Windows menu navigation keystrokes (aka
menu accelerators) - see his library `menacc.el'.  And AFAIK La Carte supports
Lennart's addition.  I have not tried this feature myself because I am not
interested in using it.  But AFAIK it is available (though not in vanilla Emacs,
and only on Windows).

FYI, it was unclear to me that you were talking about this particular kind of
keyboard navigation of menus (menu accelerators).  You seemed also/instead to be
claiming that menu items were not associated with keyboard shortcuts, which is
not true for the most part.  But those keyboard shortcuts are something
different from menu accelerators.

> Do you still want to claim that Emacs is better than most apps for
> access?

Yep.  And I said "discovery and access", and most of what I wrote had to do with
_discovery_.  Why?  Because discovery is the strong point of menus, IMHO.

And yes, IMO Emacs beats "most apps" in both respects.  But I am no expert on
all available apps - I could be wrong. ;-)

Menu accelerators are one thing.  There you might have a point, though I'm not
sure how important such a feature is.  Perhaps they could be added to Emacs more
generally than just for Windows.  I'm no help for that.

However, I have a feeling (but again, I'm ignorant and unpracticed here) that
using menus via accelerators on a regular basis is not the way to go.

Menus are about organizing commands.  They are helpful for discovery (and
rediscovery of infrequently used commands).  Regularly using menus (e.g. via
accelerators) to access frequently used commands sounds like a bad habit - to
me.  But again, I do not really know what I'm talking about here. ;-)

That sounds like just substituting an alternative set of key bindings, one that
reflects the menu structure instead of another key organization.  And while menu
structure has a certain logic to it (which is why it can be helpful), that logic
is not necessarily the best key-binding logic.  It is a logic aimed at a
particular purpose, IMO: discovery (and rediscovery): finding the needle in the
haystack).

In any case, when it comes to keyboard access of menus in general (not menu
accelerators), Emacs is not lacking.  Likewise when it comes to discovery of
menu items.  As I said, Emacs is OK out of the box (`tmm'), and it shines with a
little extra help (e.g. La Carte, Icicles).

There is really no reason that an Emacs user, new or old, should not use menus
to discover Emacs functionality.  And thereby learn keyboard shortcuts (they are
indicated in the menus).  _That's_ why I introduced menus into the discussion:
because you were talking about discovery in Emacs without mentioning menus.

> > The complaints here about weird Emacs keybindings are surprising to
> > me, coming from you, Uday, who are familiar with Emacs.  They sound
> > like the superficial comments of a vi'er or someone unfamiliar with
> > Emacs - someone who has the impression that one is _required_ to use
> > `M-x a C-s' in order to search.  It is trivial to use `M-x', trivial
> > to use the menu, and trivial to bind a simpler key to something that
> > you use often.
> 
> I didn't "complain" about the weird key bindings.  I gave the weird
> bindings as an example to talk about the over-reliance of Emacs on key
> bindings.

That statement (claim) is all the talking you did about it, AFAICT.  I think you
did not give any argument or examples to support the claim of an "over-reliance"
on key bindings.  You did not even explain what you mean by that.

You seemed to suggest that users are _required_ to use the default key sequences
(whether seemingly weird ones such as `M-s a C-s' or not), or at least that they
are _required_ to use keyboard keys (as opposed to menus or `M-x').

I countered that there is no such over-reliance.  But you didn't make clear what
you mean by that, so my rebuttal can only guess.

If you mean that Emacs forces users to use keyboard key bindings, weird or not,
then I disagree.  And especially if you mean that Emacs forces users to use
particular key bindings (the defaults).

> > Try Icicles and La Carte.  You can easily sort items on the fly and
> > you can easily get to any item, no matter where it is in the menu
> > tree.
> 
> Can they match the 3-key stroke access (Alt p i) to "Isearch Files" in
> the dired menu?

AFAIK, they support Lennart's addition of `&' to menu items to support Windows
keyboard navigation of menus.  (I have not tested that.)  So if Lennart has
added menu accelerators for this menu item, and if those accelerators give you a
key sequence as short as `Alt p i', then yes.  Otherwise no.

But that's not why I pointed you to Icicles and La Carte.  You asked about
_sorting_, so I mentioned Icicles, which lets you change sort orders on the fly,
including to any sort orders you define yourself (which is simple).

And I mentioned _direct access_ to a menu item anywhere in the tree.  The entire
path to a menu item is matchable, so you can match a deep item directly.  And
you can use multiple simple match patterns (regexps, substrings, fuzzy
match,...) instead of using a single complex pattern.

(You can of course also drill down menu by menu, just as you do with your
Windows key navigation or with `tmm'.  That is simply a special case of prefix
matching.)

I do not mention direct access to a menu item in order to promote the use of
menus on a regular basis, as a substitute for the usual key bindings.  I mention
it in the context of discoverability.

You can _very_ easily discover what menu items there are that involve searching
files (or any other functionality) - regardless of what the menu organization
might be.  Just type `ear S-SPC file' to see all menu items that contain both
`ear' (for "search") and `file', in either order.  You can even filter to find
all menu items that do _not_ match some pattern, or that match this but not
that, where "this" and "that" are as complex as you like.

And you can check the doc strings for any of the matching menu items - on the
fly.  If you cycle among some or all of them, the first line of the doc string
is shown in the mode line of *Completions*.  And you can see (in *Help*) the
entire doc string for any of them (cycling or picking one or more directly).

I emphasize discovery because to me that is where menus come into their own.  If
you want to use menus on a regular basis to access everything, then menu
accelerators might be interesting to you.

To me, menus are interesting because they _organize_ commands.  And that
organization can help you (a) find something and (b) learn what commands are
available and (c) what keys they are bound to.

I would not recommend that organization as the best keyboard access - e.g. menu
accelerators, but I don't speak from practice here.

> > > On second thought, perhaps the menus are not as disorganized as I
> > > had imagined. I haven't yet begun to use them seriously.
> > 
> > Please do.  You will thank yourself.  And you will no doubt file
> > menu bugs or enhancement requests or provide patches for
> > improvements.  Welcome.
> 
> I will be quite happy to use menus if the menu items have keystrokes
> associated with them like on Windows & Java applications.  Without
> that, they are quite inefficient.  
> 
> I will check to see if La Carte and Icicles can help.

Whether or not La Carte and Icicles can help you personally is one thing.  The
point in mentioning them here was, as I said, to show "that Emacs can easily
give excellent menu access and provide excellent menu discovery.  Out of the box
it is OK, and it could easily be made even better."

Re: Key bindings proposal

[Lennart Borgman]

On Mon, Aug 2, 2010 at 7:59 PM, Drew Adams <drew.adams@oracle.com> wrote:
>
> AFAIK, Lennart added support for the MS Windows menu navigation keystrokes (aka
> menu accelerators) - see his library `menacc.el'.


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.

Re: Key bindings proposal

[Jan Djärv]

2010-08-02 20:10, Lennart Borgman skrev:
> On Mon, Aug 2, 2010 at 7:59 PM, Drew Adams<drew.adams@oracle.com>  wrote:
>>
>> AFAIK, Lennart added support for the MS Windows menu navigation keystrokes (aka
>> menu accelerators) - see his library `menacc.el'.
>
>
> Yes and we were also discussing adding this to GNU/Linux but it has
> not happened yet.
>

It would be a different implementation for native menus (probably not worth 
it), Lucid, Motif/Lesstif, Nextstep and Gtk+.
Motif doesn't have a marker character, you must at the C level tell the widget 
in question which letter to use.  The Emacs C level could perhaps translate a 
marker character to this.  Gtk+ has _ as marker character, and Lucid currently 
has no keyboard handling in menus except arrow keys.
I don't know what Nextstep uses.

> 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).
>

How do you handle buffer names (for the Buffer menu) that have the marker
character in them (& I think for W32)?  Wouldn't it be better to use a text
property at the lisp level and let each platform specific code sort this out?

	Jan D.

Re: Key bindings proposal

[Lennart Borgman]

On Tue, Aug 3, 2010 at 11:45 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> 2010-08-02 20:10, Lennart Borgman skrev:
>>
>> On Mon, Aug 2, 2010 at 7:59 PM, Drew Adams<drew.adams@oracle.com>  wrote:
>>>
>>> AFAIK, Lennart added support for the MS Windows menu navigation
>>> keystrokes (aka
>>> menu accelerators) - see his library `menacc.el'.
>>
>>
>> Yes and we were also discussing adding this to GNU/Linux but it has
>> not happened yet.
>>
>
> It would be a different implementation for native menus (probably not worth
> it), Lucid, Motif/Lesstif, Nextstep and Gtk+.
> Motif doesn't have a marker character, you must at the C level tell the
> widget in question which letter to use.  The Emacs C level could perhaps
> translate a marker character to this.  Gtk+ has _ as marker character, and
> Lucid currently has no keyboard handling in menus except arrow keys.
> I don't know what Nextstep uses.

Thanks for the info.

>> 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).
>>
>
> How do you handle buffer names (for the Buffer menu) that have the marker
> character in them (& I think for W32)?  Wouldn't it be better to use a text
> property at the lisp level and let each platform specific code sort this
> out?

Yes I think so (or perhaps rather a cons ("menu-string" . pos)). But
this would require some changes on a lower level and I do not want to
do that until it is moved into Emacs. (I have too many patches.)

RE: Key bindings proposal

[Stephen J. Turnbull]

Drew Adams writes:

 > However, I have a feeling (but again, I'm ignorant and unpracticed
 > here) that using menus via accelerators on a regular basis is not
 > the way to go.
 > 
 > Menus are about organizing commands.  They are helpful for discovery (and
 > rediscovery of infrequently used commands).  Regularly using menus (e.g. via
 > accelerators) to access frequently used commands sounds like a bad habit - to
 > me.  But again, I do not really know what I'm talking about here. ;-)

To you, Emacs is a professional tool, like a mechanic's wrench or an
eye surgeon's laser.  The class of users Uday wants Emacs to serve
better is quite different.  They're not interested in a tool that
allows them to do work well and efficiently (in a science of mechanics
sense).  They're interested in a tool that allows them to work without
*ever* thinking about the tool.  Ie, they are *not* the equivalent of
the surgeon who after 25 years of practice almost never thinks about
her fingers or the laser, just about the eye and where to cut and
where to weld.  They're the equivalent of the typical driver who after
10 hours of practice and passing the written test never thinks about
the car again.

There's nothing wrong with serving those users (what they're doing
makes economic sense, conserving their most valuable resource, and
unlike letting them drive, the odds are that there will be very few
fatalities due to Emacs use while intoxicated), but I think it would
be a terrible waste of Emacs developer time.  They won't thank us.
Not with words, and not with new Emacs features and bug fixes --
precisely because they're so busy *not* thinking about the tool.  And
they have no need for Emacs to serve them; any old thing will do for
them, and there are plenty of old things out there.

It's true that some of those users, given an Emacs comfortable for
them *now*, will *eventually* trip over Emacs itself and catch the
spirit.  But many of that type of user will anyway.  I had a 10-year
exclusive user of vi, and a vim hacker, contact me the other day
because there are some things that can't practically be done *in* vim,
and he wants his *editor*, not a separate script, to do them.  So he
wants to try Emacs.  It's not like the people with the skills we need
and the hacker spirit that will make them produce more tools for us
don't know where to find us.

If Uday et amis *want* to serve those users, that's a different story
-- more power to them.  I'm sure they'll come up with interesting
problems, and other Emacs hackers will want to help solve them.  But
they're going to have to do the scutwork and in the process discover
the interesting problems.  It's definitely possible to get started on
the scutwork -- Uday has admitted several times that everything he
wants can be done with current Emacs features, but it's inconvenient.
They shouldn't let that inconvenience stop them. ;-)

RE: Key bindings proposal

[Uday S Reddy]

Drew Adams writes:
 
> > Do you still want to claim that Emacs is better than most apps for
> > access?
> 
> Yep.  And I said "discovery and access", and most of what I wrote
> had to do with _discovery_.  Why?  Because discovery is the strong
> point of menus, IMHO.

Access is also a strong point of menus.  And, access is what this
thread is about.  So, I hope you won't mind if I ignore the issues of
discovery, though I think they are interesting.

> However, I have a feeling (but again, I'm ignorant and unpracticed
> here) that using menus via accelerators on a regular basis is not
> the way to go.
> 
> Menus are about organizing commands.  They are helpful for discovery
> (and rediscovery of infrequently used commands).  Regularly using
> menus (e.g. via accelerators) to access frequently used commands
> sounds like a bad habit - to me.  But again, I do not really know
> what I'm talking about here. ;-)

Menu navigation by keys is actually the best form of interaction for
me, having been an RSI sufferer, because both control keys and the
mouse tax my fingers.  somebody pointed out that the world out there
uses menus a lot more than key bindings.

But you jump the gun a bit here.  Not everything is a "frequently used
command".  Menu access is useful for such operations that might be
used occasionally.  This is not about discovery.  You might know there
is a command and you remember where it is on the menus.  But you don't
know or care to remember its key binding.  For such cases, menus are
your friend.

But I am glad that you are at least open to people that choose
different modes of interaction from you.  Many others here are rather
closed minded, quite disappointingly.

> That statement (claim) is all the talking you did about it, AFAICT.
> I think you did not give any argument or examples to support the
> claim of an "over-reliance" on key bindings.  You did not even
> explain what you mean by that.

What I mean is that Emacs hasn't explored and developed other modes of
interaction enough because of its belief that key bindings are enough.
A long function name such as dired-do-search doesn't bother Emacs
developers because they expect it to be used via its key binding.  The
fact that the menus don't have keyboard accelerators (which is 10-year
old technology in Windows and Java - don't know about Linux) doesn't
bother them because only idiots that can't remember key bindings will
be using the menus anyway.  So on.

So, while Emacs used to be a leader in user interaction when it
started, now it is a reluctant laggard that comes in kicking and
screaming only after the whole world has already moved on with
innovations.  No wonder that the Emacs user base has been shrinking.
(By the way, we in the Universities have known for a quite a while
that Emacs has been losing ground.  We don't need Google to tell us
that.  Some time around 2002 or 2003, we stopped recommend Emacs to
students because we appeared to be total nut cases to them.  Even if
we recommended it, it didn't serve any purpose.  They went home and
used JDeveloper.)

When new users come to using a tool like Emacs, their first mode of
interaction is via the menubar, used with the mouse.  The second might
be to use keyboard accelerators.  Only after they have settled down to
using the tool would they begin to learn some of its key bindings.
And, they will learn them selectively based on the frequency of use
and what they care about.  They almost definitely won't start by
reading the manual.  Whatever we might think about it, that is not the
way the world works any more.  They will look up the manual when they
are stuck on something or want to learn about some particular feature.
If the manual dwells on the fundamentals too much, it will get in the
way.

New users use Emacs in totally different ways to us.  For instance,
they almost never use the keyboard for find-file and save-file.  They
go to the menu.  And, they use the mouse and cut-and-paste the way
they are used to doing in other tools.  If and when they decide to use
the keyboard, they will try C-o and C-s (Windows key bindings), find
that they don't work, and give up.  As long as Emacs was the only game
in town, we could do things which ever way we pleased.  But now there
is a larger world out there.  And, Emacs has to fit in.

The way to fit in is to make Emacs flexible and customizable so that
the new users with completely different needs from us can do things
their own way.  If people like Xah Lee or Lennart have to fork Emacs
in order to make it suitable to groups of users, then Emacs hasn't
lived up to its challenge.  Ideally, they should be able to publish a
customization file, something along the lines of a .Xdefaults file,
which the users can customize and load.

I am hoping that this thread can move us in that direction.

Cheers,
Uday

Re: Key bindings proposal

[Juanma Barranquero]

On Tue, Aug 3, 2010 at 13:56, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote:

> If people like Xah Lee or Lennart have to fork Emacs
> in order to make it suitable to groups of users, then Emacs hasn't
> lived up to its challenge.

That's one possible interpretation. I don't think it is necessary to
fork Emacs to make it appealing to Windows users, for example.
Improvements can be made, of course.

    Juanma

Re: Key bindings proposal

[Lennart Borgman]

On Tue, Aug 3, 2010 at 4:04 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Tue, Aug 3, 2010 at 13:56, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote:
>
>> If people like Xah Lee or Lennart have to fork Emacs
>> in order to make it suitable to groups of users, then Emacs hasn't
>> lived up to its challenge.
>
> That's one possible interpretation. I don't think it is necessary to
> fork Emacs to make it appealing to Windows users, for example.
> Improvements can be made, of course.

My intention has not been to fork (though you seemed to believe that,
Juanma). Instead I have made quite a lot of patches to show it is
working. Then I thought the changes would be adopted (since there are
quite a few users of my patched version, at least before).

The problem is that it is very hard to get them accepted. Thousands of
users using them without trouble does not seem enough.

Another  problem is that this kind of trouble has taken too much time.
(Not only my time.)

Re: Key bindings proposal

[Juanma Barranquero]

On Tue, Aug 3, 2010 at 17:02, Lennart Borgman <lennart.borgman@gmail.com> wrote:

> My intention has not been to fork (though you seemed to believe that, Juanma).

No, I don't think that was your intention, though I think (and
apparently I'm not the only one) that's what you've done. I dislike
that, because it seems like a wasted effort. I'd rather see you
working on standard Emacs. Seems unlikely.

But anyway, my comment wasn't about your fork, just noting that it is
possible to serve the needs of the Windows users without forking.
Udday seemed to imply otherwise.

> The problem is that it is very hard to get them accepted. Thousands of
> users using them without trouble does not seem enough.

We've rehashed this many times, most recently a few weeks ago. There
are many reasons why the patches have not yet been accepted. "Thousand
of users using them without trouble" is a good start, but not a
conclusive argument per se.

    Juanma

Re: Key bindings proposal

[Lennart Borgman]

On Tue, Aug 3, 2010 at 5:16 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Tue, Aug 3, 2010 at 17:02, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>
>> My intention has not been to fork (though you seemed to believe that, Juanma).
>
> No, I don't think that was your intention, though I think (and
> apparently I'm not the only one) that's what you've done. I dislike
> that, because it seems like a wasted effort. I'd rather see you
> working on standard Emacs. Seems unlikely.

I am working on the standard Emacs. Though that does not always pass
this list. (I want to keep the discussions to a minimum.)

Re: Key bindings proposal

[David Kastrup]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Tue, Aug 3, 2010 at 4:04 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
>> On Tue, Aug 3, 2010 at 13:56, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote:
>>
>>> If people like Xah Lee or Lennart have to fork Emacs
>>> in order to make it suitable to groups of users, then Emacs hasn't
>>> lived up to its challenge.
>>
>> That's one possible interpretation. I don't think it is necessary to
>> fork Emacs to make it appealing to Windows users, for example.
>> Improvements can be made, of course.
>
> My intention has not been to fork (though you seemed to believe that,
> Juanma). Instead I have made quite a lot of patches to show it is
> working. Then I thought the changes would be adopted (since there are
> quite a few users of my patched version, at least before).
>
> The problem is that it is very hard to get them accepted. Thousands of
> users using them without trouble does not seem enough.

They are mostly orthogonal to code acceptance issues.  If people tell
you what problems keep your code from being mergeable, there is little
point in gathering street support rather than addressing the issues.

> Another problem is that this kind of trouble has taken too much time.
> (Not only my time.)

If you'd rather not have other Emacs developers' time wasted, there are
a few thread topics you could killfile, as your participance is not
likely improving the balance.

-- 
David Kastrup

Re: Key bindings proposal

[Lennart Borgman]

On Tue, Aug 3, 2010 at 5:18 PM, David Kastrup <dak@gnu.org> wrote:
>>
>> The problem is that it is very hard to get them accepted. Thousands of
>> users using them without trouble does not seem enough.
>
> They are mostly orthogonal to code acceptance issues.  If people tell
> you what problems keep your code from being mergeable, there is little
> point in gathering street support rather than addressing the issues.

So you say that if people like the way the patches work and developers
here say it is not worth the efforts then I should ... do what?

>> Another problem is that this kind of trouble has taken too much time.
>> (Not only my time.)
>
> If you'd rather not have other Emacs developers' time wasted, there are
> a few thread topics you could killfile, as your participance is not
> likely improving the balance.

I think it is. It is ok if you do not like it, but please do not
pretend that you know better.

If you think I am being unkind or that my arguments really are wrong
then I am glad if you tell me.

no forking relation (was: Key bindings proposal)

[Drew Adams]

> I should ... do what?

You should start a new thread. ;-)

You guys are no longer discussing any key-bindings proposal.

Re: Key bindings proposal

[Uday S Reddy]

Juanma Barranquero writes:

> That's one possible interpretation. I don't think it is necessary to
> fork Emacs to make it appealing to Windows users, for example.
> Improvements can be made, of course.

In that case, I would like to understand at least the key binding
aspects of this divergence.  How do you think Lennart could have
changed the key bindings for the needs of W32 users?  And, Lennart, if
you can follow up please.

Cheers,
Uday

Re: Key bindings proposal

[Juanma Barranquero]

On Thu, Aug 5, 2010 at 10:39, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote:

> In that case, I would like to understand at least the key binding
> aspects of this divergence.

I don't think they are the main reason behind the fork, but I could be wrong.

> How do you think Lennart could have
> changed the key bindings for the needs of W32 users?

What are the specific key bindings needs for W32 users that standard
Emacs does not support? We have CUA mode, and it's not hard to load a
package to rebind whatever is necessary. AFAIK, Lennart has code to
make using the Alt key as alt easier, but I'd like to know what are
the specific troubles that require so, and how necessary it really is.

Also, note that I've said "to make it appealing to Windows users", not
"to make it a clone of every Windows application". Of course if you
need that *everything* works in Emacs *exactly* as in Notepad, then
use Notepad.

    Juanma

Re: Key bindings proposal

[Lennart Borgman]

On Thu, Aug 5, 2010 at 11:22 AM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Thu, Aug 5, 2010 at 10:39, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote:
>
>> In that case, I would like to understand at least the key binding
>> aspects of this divergence.
>
> I don't think they are the main reason behind the fork, but I could be wrong.


Yes, it is.

There were three main things I wanted to work:
- Using the windows keys (or other key, for example shift-lock) as
Emacs META so that Alt key could be freed.
- Getting sticky keys (accessibility) to work.
- Getting menus to work. The events where handled in wrong order, but
I think it is hard to notice this unless you use the Alt keys to acces
the menus. (BTW Firefox had a similar bug.)

Later I have put some other patches there too.


And once again: I do not consider it a fork. Some people have indeed
asked me to make it a fork but I have stayed here, hoping things
should change.

In the beginning some of my libraries came only with my patched
version of Emacs. I did not think that was good so I instead created
nXhtml where nearly all my librarries now are. (The name is
unfortunate since there are quite a few things that is not about XHTML
or web development, but it is too much work to change it.) This can be
used everywhere where Emacs can be used (but requires often a newer
version).


>> How do you think Lennart could have
>> changed the key bindings for the needs of W32 users?
>
> What are the specific key bindings needs for W32 users that standard
> Emacs does not support? We have CUA mode, and it's not hard to load a
> package to rebind whatever is necessary. AFAIK, Lennart has code to
> make using the Alt key as alt easier, but I'd like to know what are
> the specific troubles that require so, and how necessary it really is.


Please excuse me, Juanma, but I find this a bit annoying. I have
explained this several times before here.

And I also find it a bit hopeful. Using the right and left windows
keys as Emacs META requires that a low level keyboard hook is used.
Just read the documentation at MS to see that. (I have given link to
it previously.)

This is actually a rather simple change. The other two changes above
are more complicated.


> Also, note that I've said "to make it appealing to Windows users", not
> "to make it a clone of every Windows application". Of course if you
> need that *everything* works in Emacs *exactly* as in Notepad, then
> use Notepad.


I would be glad if you (and others) did not try to make other people look silly.

Re: Key bindings proposal

[Juanma Barranquero]

On Thu, Aug 5, 2010 at 13:00, Lennart Borgman <lennart.borgman@gmail.com> wrote:

> Yes, it is.

I stand corrected.

> There were three main things I wanted to work:
> - Using the windows keys (or other key, for example shift-lock) as
> Emacs META so that Alt key could be freed.

Why is that *necessary* for Windows users?

> - Getting sticky keys (accessibility) to work.

Have you filed a bug report about the specific problems in standard
Emacs vs. sticky keys?

> - Getting menus to work. The events where handled in wrong order, but
> I think it is hard to notice this unless you use the Alt keys to acces
> the menus.

You discussed this on emacs-devel, but it was a long time ago, so I
don't remember which were the specific problems included in "getting
menus to work". Sorry.

> And once again: I do not consider it a fork. Some people have indeed
> asked me to make it a fork but I have stayed here, hoping things
> should change.

It's a matter of definition.

> Please excuse me, Juanma, but I find this a bit annoying. I have
> explained this several times before here.

There's a difference between "I would like for Emacs to work in
such-and-such way", and "Windows users do need such-and-such feature
to feel comfortable with Emacs". Obviously all of your changes fall
into the first category, but I'm not so sure about the second one. I
know of a few seasoned Windows users which apparently do not need
them. So stop trying to conflate both categories.

And, I'd like to note that I was answering Uday about the second
category; I have no saying in what *you* prefer or need for your
Emacs.

> And I also find it a bit hopeful. Using the right and left windows
> keys as Emacs META requires that a low level keyboard hook is used.
> Just read the documentation at MS to see that. (I have given link to
> it previously.)

Yes, but you need to use the Windows key as meta *because* you want to
use Alt for alt, and you want to use Alt for alt because some menu
troubles, isn't so? And the question is, are really these troubles so
big?  (And if they are, shouldn't you work to get the keyboard
handling patch into Emacs... and then we're back to the same old
discussion).

> I would be glad if you (and others) did not try to make other people look silly.

I would be glad if you (and others) did not try to make Emacs
developers look like old farts that do not accept your changes out of
sheer complacency or negligence.

    Juanma

Re: Key bindings proposal

[Lennart Borgman]

On Thu, Aug 5, 2010 at 1:24 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
>
>> There were three main things I wanted to work:
>> - Using the windows keys (or other key, for example shift-lock) as
>> Emacs META so that Alt key could be freed.
>
> Why is that *necessary* for Windows users?

Oh, I forget META-TAB too, which is used heavily in Emacs.

>> - Getting sticky keys (accessibility) to work.
>
> Have you filed a bug report about the specific problems in standard
> Emacs vs. sticky keys?

We have discussed it on this list.

>> And once again: I do not consider it a fork. Some people have indeed
>> asked me to make it a fork but I have stayed here, hoping things
>> should change.
>
> It's a matter of definition.

Rather bashing.

>> Please excuse me, Juanma, but I find this a bit annoying. I have
>> explained this several times before here.
>
> There's a difference between "I would like for Emacs to work in
> such-and-such way", and "Windows users do need such-and-such feature
> to feel comfortable with Emacs". Obviously all of your changes fall
> into the first category, but I'm not so sure about the second one. I
> know of a few seasoned Windows users which apparently do not need
> them. So stop trying to conflate both categories.

Have I done that? When? Perhaps you misunderstood something?

>> And I also find it a bit hopeful. Using the right and left windows
>> keys as Emacs META requires that a low level keyboard hook is used.
>> Just read the documentation at MS to see that. (I have given link to
>> it previously.)
>
> Yes, but you need to use the Windows key as meta *because* you want to
> use Alt for alt, and you want to use Alt for alt because some menu
> troubles, isn't so? And the question is, are really these troubles so
> big?

Yes, I thnink so. There is also the trouble with META-TAB.

(And if they are, shouldn't you work to get the keyboard
> handling patch into Emacs... and then we're back to the same old
> discussion).

They are there in my patched version. Just grab them.

>> I would be glad if you (and others) did not try to make other people look silly.
>
> I would be glad if you (and others) did not try to make Emacs
> developers look like old farts that do not accept your changes out of
> sheer complacency or negligence.

I hope I have not done that. (But I am not responsible for your
answers.) I know time is a big issue, but I have spent a lot of time
on this.

Re: Key bindings proposal

[Uday S Reddy]

Lennart Borgman writes:

> 
> > (And if they are, shouldn't you work to get the keyboard
> > handling patch into Emacs... and then we're back to the same old
> > discussion).
> 
> They are there in my patched version. Just grab them.

I am beginning to see why things haven't been working.  It would be
quite hard for the Emacs team to just take your patched version and
figure out what is what.  They would need a precise patch for each
feature.  After you give it to them, they will still have quite a bit
work to do: to test it, document it, and to figure out if there is any
interference with other stuff etc.

I understand that you have spent a lot of time in doing the coding.
Can't you spend a bit more in getting to the Emacs team in a usable
form?

Cheers,
Uday

Re: Key bindings proposal

[Lennart Borgman]

On Thu, Aug 5, 2010 at 3:59 PM, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote:
> Lennart Borgman writes:
>
>>
>> > (And if they are, shouldn't you work to get the keyboard
>> > handling patch into Emacs... and then we're back to the same old
>> > discussion).
>>
>> They are there in my patched version. Just grab them.
>
> I am beginning to see why things haven't been working.  It would be
> quite hard for the Emacs team to just take your patched version and
> figure out what is what.  They would need a precise patch for each
> feature.  After you give it to them, they will still have quite a bit
> work to do: to test it, document it, and to figure out if there is any
> interference with other stuff etc.

Unfortunately sending a precise patch is not enough. The patch can
sometimes be complicated (as for emacsclient) and we need time to
minimize that work. (And because of a lot of misunderstanding we have
not been able to move forward there.)

Other times it is the feature itself that has not been thought of as
important enough (as in the case of beeing able to move Emacs META or
accessibility).

I would be glad if we could move forward though. A problem is of
course that I have forgotten the details now since the code was
written several years ago. And that I have less time.

Re: Key bindings proposal

[Uday S Reddy]

Lennart Borgman writes:

> Yes, it is.
> 
> There were three main things I wanted to work:
> - Using the windows keys (or other key, for example shift-lock) as
> Emacs META so that Alt key could be freed.
> - Getting sticky keys (accessibility) to work.
> - Getting menus to work. The events where handled in wrong order, but
> I think it is hard to notice this unless you use the Alt keys to acces
> the menus. (BTW Firefox had a similar bug.)
> 
> Later I have put some other patches there too.

I agree with Juanma that these things do not seem to warrant a fork.
These are general features that Gnu Emacs can and should have for
supporting Windows.  There is no incompatibility.

(I don't know if you were around then, but the original development of
Emacs for Windows also happened in a sort-of fork, called NT Emacs.
That has now been integrated with Gnu Emacs.)

> And once again: I do not consider it a fork. Some people have indeed
> asked me to make it a fork but I have stayed here, hoping things
> should change.

I don't know the history, but I would encourage you to stay on and do
whatever is necessary to get the changes accepted.  There can be quite
a bit of work involved in getting there, to document, test, and fit
things into the existing structure.  I do some of such work for VM,
trying to integrate the add-ons that have been contributed over the
years.  It does involve quite a bit of work even when the packages are
quite straightforward.  There is quite a bit of distance between a
prototype (what is often contributed) and a finished product (what
goes into the system).

> And I also find it a bit hopeful. Using the right and left windows
> keys as Emacs META requires that a low level keyboard hook is used.
> Just read the documentation at MS to see that. (I have given link to
> it previously.)

Like Juanma, I also don't know why it is essential to use the Windows
key as meta.  I am able to use Alt as the meta key in Emacs and also
get Alt+TAB to switch W32 windows.  I can momentarily depress Alt to
activate the menubar.  

> > Also, note that I've said "to make it appealing to Windows users", not
> > "to make it a clone of every Windows application". Of course if you
> > need that *everything* works in Emacs *exactly* as in Notepad, then
> > use Notepad.
> 
> I would be glad if you (and others) did not try to make other people look
> silly.

Indeed, it would be good to drop the frequent references to Notepad.
As far as I know, the Notepad-users and Emacs-users are mutually
exclusive.  So, Notepad is not at issue.

Cheers,
Uday

Re: Key bindings proposal

[Juanma Barranquero]

On Thu, Aug 5, 2010 at 15:10, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote:

> As far as I know, the Notepad-users and Emacs-users are mutually exclusive.

Not so. I use Notepad quite frequently (though, to be fair, lately I
use Notepad2 instead).

    Juanma

Re: Key bindings proposal

[Lennart Borgman]

On Thu, Aug 5, 2010 at 3:10 PM, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote:
>
> I agree with Juanma that these things do not seem to warrant a fork.

I do not know if that is Juanmas position but I agree with you.

> I don't know the history, but I would encourage you to stay on and do
> whatever is necessary to get the changes accepted.  There can be quite
> a bit of work involved in getting there, to document, test, and fit
> things into the existing structure.

Those patches have been used quite a long time now and I have had no
complaints. (But part of it could be written better, perhaps.)

Unfortunately I do not have that much time to spend on this now. (I
have spent quite a lot of time on nXhtml. Parts of it are
complicated.)

> Like Juanma, I also don't know why it is essential to use the Windows
> key as meta.  I am able to use Alt as the meta key in Emacs and also
> get Alt+TAB to switch W32 windows.

You can not override Alt-TAB so that you can use it to switch w32
windows is because ms has decided it to work that way.

However in Emacs META-TAB is frequently used for completion functions.
That can not work on w32 (and with some other window managers if I
understood it correctly).

>I can momentarily depress Alt to activate the menubar.

Can you? Please give more details.

Re: Key bindings proposal

[Uday S Reddy]

Lennart Borgman writes:

> You can not override Alt-TAB so that you can use it to switch w32
> windows is because ms has decided it to work that way.
> 
> However in Emacs META-TAB is frequently used for completion functions.
> That can not work on w32 (and with some other window managers if I
> understood it correctly).

Indeed, I have gotten used to doing ESC-TAB for completion, which is a
bit of a chore I admit.  Ok, so, it is quite useful to remap the
Windows key but it doesn't seem criticial.

> >I can momentarily depress Alt to activate the menubar.
> 
> Can you? Please give more details.

I was trying to recall if I did anything special to get it but
couldn't.  So, I looked up O'Reilly's Windows XP in a Nutshell.  It
says under "Keyboard Accelerators", 

"In any any window that has a menu, press the Alt key or the F10 key
to active the manu bar, and use the cursor keys to move around.  Press
Enter to activate the currently selected item or Esc to cancel."

Then it goes on to talk about using Alt+letter to go directly to
a particular menu.

What I can't do in Emacs is the latter.  I can't press Alt+F to go the
File menu.  In Firefox/Thunderbird, I can.  To me personally, that is
not a big price to pay.  You might think otherwise.

Cheers,
Uday

Re: Key bindings proposal

[Lennart Borgman]

On Thu, Aug 5, 2010 at 3:48 PM, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote:
> Lennart Borgman writes:
>
>> You can not override Alt-TAB so that you can use it to switch w32
>> windows is because ms has decided it to work that way.
>>
>> However in Emacs META-TAB is frequently used for completion functions.
>> That can not work on w32 (and with some other window managers if I
>> understood it correctly).
>
> Indeed, I have gotten used to doing ESC-TAB for completion, which is a
> bit of a chore I admit.  Ok, so, it is quite useful to remap the
> Windows key but it doesn't seem criticial.

You can not use ESC-TAB if you are using Viper. (Which I and many others do.)

So it is critical.

>> >I can momentarily depress Alt to activate the menubar.
>>
>> Can you? Please give more details.
>
> I was trying to recall if I did anything special to get it but
> couldn't.  So, I looked up O'Reilly's Windows XP in a Nutshell.  It
> says under "Keyboard Accelerators",
>
> "In any any window that has a menu, press the Alt key or the F10 key
> to active the manu bar, and use the cursor keys to move around.  Press
> Enter to activate the currently selected item or Esc to cancel."
>
> Then it goes on to talk about using Alt+letter to go directly to
> a particular menu.
>
> What I can't do in Emacs is the latter.  I can't press Alt+F to go the
> File menu.  In Firefox/Thunderbird, I can.  To me personally, that is
> not a big price to pay.  You might think otherwise.

I can either press Alt and then F to open the file menu. Can you?

Re: Key bindings proposal

[Lennart Borgman]

On Thu, Aug 5, 2010 at 4:01 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> I can either press Alt and then F to open the file menu. Can you?

=> I can't either press Alt and then F to open the file menu.

Re: Key bindings proposal

[Uday S Reddy]

Lennart Borgman writes:

> 
> > I can either press Alt and then F to open the file menu. Can you?
> 
> => I can't either press Alt and then F to open the file menu.

After discussing this with Lennart, it turns out that he uses a
feature called "sticky keys" in Windows which allows him to type `Alt'
and `f' separately to send the Alt+F (or Alt-f) event.  Emacs is
currently not interpreting this type of an event (except by mapping it
to Meta-f via the w32-alt-is-meta setting).  

But the interpretation needed for a Windows user is to activate the
menubar item that begins with "f" (e.g., the File menu).  Pressing
`Alt' and `f' separately doesn't work for Lennart because he uses
sticky keys.

I hope that clarifies the conflusion.  Lennart needs the Alt+character
events interpreted by Emacs to access the menus via keyboard.

Cheers,
Uday

Re: Key bindings proposal

[Lennart Borgman]

On Thu, Aug 5, 2010 at 4:14 PM, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote:
> Lennart Borgman writes:
>
>> I can either press Alt and then F to open the file menu. Can you?
>
> Yes.  That is what I was talking about.  Alt+F doesn't work (because
> Emacs intercepts the event), but Alt and F pressed separately works.

That does not work for me (with the unpatched version).

Maybe it is because I am using sticky keys. (I think it is very
essential that sticky keys should work.)

Re: Key bindings proposal

[Jason Rumney]

On 05/08/2010 21:22, Lennart Borgman wrote:

> You can not override Alt-TAB so that you can use it to switch w32
> windows is because ms has decided it to work that way.
>    

When I search the web for information about Low Level Keyboard Hooks, 
about 80% of the results are about using them to override Alt-TAB 
behaviour.  I find it curious that you claim this cannot be done as part 
of your justification for moving Meta from Alt to the Windows key, when 
your solution involves what would be the solution to the Alt-TAB problem.

Re: Key bindings proposal

[Lennart Borgman]

On Fri, Aug 6, 2010 at 2:50 AM, Jason Rumney <jasonr@gnu.org> wrote:
> On 05/08/2010 21:22, Lennart Borgman wrote:
>
>> You can not override Alt-TAB so that you can use it to switch w32
>> windows is because ms has decided it to work that way.
>>
>
> When I search the web for information about Low Level Keyboard Hooks, about
> 80% of the results are about using them to override Alt-TAB behaviour.  I
> find it curious that you claim this cannot be done as part of your
> justification for moving Meta from Alt to the Windows key, when your
> solution involves what would be the solution to the Alt-TAB problem.

That is interesting. Something might have changed since I did this -
after all some years has passed and MS are now and then changing these
things. Can you please give some links?

Re: Key bindings proposal

[Jason Rumney]

On 06/08/2010 09:28, Lennart Borgman wrote:
> On Fri, Aug 6, 2010 at 2:50 AM, Jason Rumney<jasonr@gnu.org>  wrote:
>    
>> When I search the web for information about Low Level Keyboard Hooks, about
>> 80% of the results are about using them to override Alt-TAB behaviour.  I
>> find it curious that you claim this cannot be done as part of your
>> justification for moving Meta from Alt to the Windows key, when your
>> solution involves what would be the solution to the Alt-TAB problem.
>>      
> That is interesting. Something might have changed since I did this -
> after all some years has passed and MS are now and then changing these
> things. Can you please give some links?\
>    

http://support.microsoft.com/kb/226359
http://msdn.microsoft.com/en-us/magazine/cc302329.aspx
http://stackoverflow.com/questions/2490577/suppress-task-switch-keys-winkey-alt-tab-alt-esc-ctrl-esc-using-low-level-ke

Re: Key bindings proposal

[Lennart Borgman]

On Fri, Aug 6, 2010 at 3:35 AM, Jason Rumney <jasonr@gnu.org> wrote:
> On 06/08/2010 09:28, Lennart Borgman wrote:
>>
>> On Fri, Aug 6, 2010 at 2:50 AM, Jason Rumney<jasonr@gnu.org>  wrote:
>>
>>>
>>> When I search the web for information about Low Level Keyboard Hooks,
>>> about
>>> 80% of the results are about using them to override Alt-TAB behaviour.  I
>>> find it curious that you claim this cannot be done as part of your
>>> justification for moving Meta from Alt to the Windows key, when your
>>> solution involves what would be the solution to the Alt-TAB problem.
>>>
>>
>> That is interesting. Something might have changed since I did this -
>> after all some years has passed and MS are now and then changing these
>> things. Can you please give some links?\
>>
>
> http://support.microsoft.com/kb/226359
> http://msdn.microsoft.com/en-us/magazine/cc302329.aspx
> http://stackoverflow.com/questions/2490577/suppress-task-switch-keys-winkey-alt-tab-alt-esc-ctrl-esc-using-low-level-ke


Thanks. I will test the last one and see. That is a recent article.

Re: Key bindings proposal

[Lennart Borgman]

On Fri, Aug 6, 2010 at 3:41 AM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Fri, Aug 6, 2010 at 3:35 AM, Jason Rumney <jasonr@gnu.org> wrote:

>> http://stackoverflow.com/questions/2490577/suppress-task-switch-keys-winkey-alt-tab-alt-esc-ctrl-esc-using-low-level-ke
>
>
> Thanks. I will test the last one and see. That is a recent article.

This article code uses HasAltModifier to test for Alt in the low level
keyboard hook. It seems to be some c++ variant. What can I do instead
in Emacs?

Re: Key bindings proposal

[Óscar Fuentes]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Fri, Aug 6, 2010 at 3:41 AM, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>> On Fri, Aug 6, 2010 at 3:35 AM, Jason Rumney <jasonr@gnu.org> wrote:
>
>>> http://stackoverflow.com/questions/2490577/suppress-task-switch-keys-winkey-alt-tab-alt-esc-ctrl-esc-using-low-level-ke
>>
>>
>> Thanks. I will test the last one and see. That is a recent article.
>
> This article code uses HasAltModifier to test for Alt in the low level
> keyboard hook. It seems to be some c++ variant. What can I do instead
> in Emacs?

HasAltModifier is defined right there at the bottom, on the same code
example. If you want C examples for any OS version down to Windows 95
and NT 3.51, the first link on Jason's list shows the way.

BTW, intercepting Alt+Tab, Ctrl+Esc and even Ctrl-Alt-Del is a common
requirement. Have you ever seen a kiosk-mode application?

Re: Key bindings proposal

[Lennart Borgman]

On Fri, Aug 6, 2010 at 4:16 AM, Óscar Fuentes <ofv@wanadoo.es> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> On Fri, Aug 6, 2010 at 3:41 AM, Lennart Borgman
>> <lennart.borgman@gmail.com> wrote:
>>> On Fri, Aug 6, 2010 at 3:35 AM, Jason Rumney <jasonr@gnu.org> wrote:
>>
>>>> http://stackoverflow.com/questions/2490577/suppress-task-switch-keys-winkey-alt-tab-alt-esc-ctrl-esc-using-low-level-ke
>>>
>>>
>>> Thanks. I will test the last one and see. That is a recent article.
>>
>> This article code uses HasAltModifier to test for Alt in the low level
>> keyboard hook. It seems to be some c++ variant. What can I do instead
>> in Emacs?
>
> HasAltModifier is defined right there at the bottom, on the same code
> example. If you want C examples for any OS version down to Windows 95
> and NT 3.51, the first link on Jason's list shows the way.

Ah, thanks. I will never learn to read C.

> BTW, intercepting Alt+Tab, Ctrl+Esc and even Ctrl-Alt-Del is a common
> requirement. Have you ever seen a kiosk-mode application?

Yes, but it looks like maybe for those you instead toggle CoolSwitch
in the registry:


http://stackoverflow.com/questions/2970683/disable-windows-and-alt-tab-key-combos

But I am not sure, see my prev post.

Re: Key bindings proposal

[Lennart Borgman]

On Fri, Aug 6, 2010 at 3:58 AM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Fri, Aug 6, 2010 at 3:41 AM, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>> On Fri, Aug 6, 2010 at 3:35 AM, Jason Rumney <jasonr@gnu.org> wrote:
>
>>> http://stackoverflow.com/questions/2490577/suppress-task-switch-keys-winkey-alt-tab-alt-esc-ctrl-esc-using-low-level-ke
>>
>>
>> Thanks. I will test the last one and see. That is a recent article.
>
> This article code uses HasAltModifier to test for Alt in the low level
> keyboard hook. It seems to be some c++ variant. What can I do instead
> in Emacs?

I tested with code similar to this:

            case VK_TAB:
              /*
                Tip from Jason 2010-08-05 regarding suppressing
Alt-TAB in the hook:

http://stackoverflow.com/questions/2490577/suppress-task-switch-keys-winkey-alt-tab-alt-esc-ctrl-esc-using-low-level-ke

                For the computer user instead, using registry setting of
                [HKEY_CURRENT_USER\Control Panel\Desktop]
                "CoolSwitch"="0"

http://stackoverflow.com/questions/2970683/disable-windows-and-alt-tab-key-combos
              */

              {
                //if (HasAltModifier(pkbdllhook->flags))
                if ((pkbdllhook->flags & LLKHF_ALTDOWN) != 0)
                  {
                    // return new IntPtr(1);
                    return TRUE;
                  }
              }

It surprised me in several ways:

- It actually suppressed Alt-TAB, but for ALL RUNNING PROGRAMS! (That
make me think of that Eli once said that the low level keyboard hook
would affect all programs. It normally does not so there is something
strange here.)

So the code above can not be used in Emacs. Does someone has any idea
of what is wrong here?

Re: Key bindings proposal

[Lennart Borgman]

On Fri, Aug 6, 2010 at 4:34 AM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Fri, Aug 6, 2010 at 3:58 AM, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>> On Fri, Aug 6, 2010 at 3:41 AM, Lennart Borgman
>> <lennart.borgman@gmail.com> wrote:
>>> On Fri, Aug 6, 2010 at 3:35 AM, Jason Rumney <jasonr@gnu.org> wrote:
>>
>>>> http://stackoverflow.com/questions/2490577/suppress-task-switch-keys-winkey-alt-tab-alt-esc-ctrl-esc-using-low-level-ke
>>>
>>>
>>> Thanks. I will test the last one and see. That is a recent article.
>>
>> This article code uses HasAltModifier to test for Alt in the low level
>> keyboard hook. It seems to be some c++ variant. What can I do instead
>> in Emacs?
>
> I tested with code similar to this:
>
>            case VK_TAB:
>              /*
>                Tip from Jason 2010-08-05 regarding suppressing
> Alt-TAB in the hook:
>
> http://stackoverflow.com/questions/2490577/suppress-task-switch-keys-winkey-alt-tab-alt-esc-ctrl-esc-using-low-level-ke
>
>                For the computer user instead, using registry setting of
>                [HKEY_CURRENT_USER\Control Panel\Desktop]
>                "CoolSwitch"="0"
>
> http://stackoverflow.com/questions/2970683/disable-windows-and-alt-tab-key-combos
>              */
>
>              {
>                //if (HasAltModifier(pkbdllhook->flags))
>                if ((pkbdllhook->flags & LLKHF_ALTDOWN) != 0)
>                  {
>                    // return new IntPtr(1);
>                    return TRUE;

Removing "return TRUE" and instead doing

                    bHandle = NILP(Vw32_pass_alt_to_system);
                    break;

made this work as Jason suggested. I.e. it allows the use of Alt-TAB
as M-TAB on w32. (The back draw is that you then can not switch to
other applications using Alt-TAB when in Emacs.)

Other application will still respond the normal way to Alt-TAB.

I must say again I am surprised that this worked. I wonder though is
this is documented behavior. If it is, then maybe it is time to
include the low level keyboard hook in Emacs? (I myself does not like
this behavior, but others might want it.)


>                  }
>              }
>
> It surprised me in several ways:
>
> - It actually suppressed Alt-TAB, but for ALL RUNNING PROGRAMS! (That
> make me think of that Eli once said that the low level keyboard hook
> would affect all programs. It normally does not so there is something
> strange here.)
>
> So the code above can not be used in Emacs. Does someone has any idea
> of what is wrong here?
>

Re: Key bindings proposal

[Lennart Borgman]

On Fri, Aug 6, 2010 at 4:55 AM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
>
> made this work as Jason suggested. I.e. it allows the use of Alt-TAB
> as M-TAB on w32. (The back draw is that you then can not switch to
> other applications using Alt-TAB when in Emacs.)
>
> Other application will still respond the normal way to Alt-TAB.


If this should be usable at all then there must be a way to get into
the normal Alt-TAB behavior from withing Emacs. A possible solution is
maybe to treat Alt-Shift-Tab as usual.

Is there anyone who remember how to catch SHIFT in a low level keyboard hook?

Re: Key bindings proposal

[Jason Rumney]

On 06/08/2010 11:11, Lennart Borgman wrote:
> On Fri, Aug 6, 2010 at 4:55 AM, Lennart Borgman
> <lennart.borgman@gmail.com>  wrote:
>    
>> made this work as Jason suggested. I.e. it allows the use of Alt-TAB
>> as M-TAB on w32. (The back draw is that you then can not switch to
>> other applications using Alt-TAB when in Emacs.)
>>
>> Other application will still respond the normal way to Alt-TAB.
>>      
>
> If this should be usable at all then there must be a way to get into
> the normal Alt-TAB behavior from withing Emacs.
>    

Does the following still work after Alt-TAB is overridden?

(w32-send-sys-command #xf040)

This can be bound to whatever event the user wants.

Re: Key bindings proposal

[Lennart Borgman]

On Fri, Aug 6, 2010 at 8:05 AM, Jason Rumney <jasonr@gnu.org> wrote:
> On 06/08/2010 11:11, Lennart Borgman wrote:
>>
>> On Fri, Aug 6, 2010 at 4:55 AM, Lennart Borgman
>> <lennart.borgman@gmail.com>  wrote:
>>
>>>
>>> made this work as Jason suggested. I.e. it allows the use of Alt-TAB
>>> as M-TAB on w32. (The back draw is that you then can not switch to
>>> other applications using Alt-TAB when in Emacs.)
>>>
>>> Other application will still respond the normal way to Alt-TAB.
>>>
>>
>> If this should be usable at all then there must be a way to get into
>> the normal Alt-TAB behavior from withing Emacs.
>>
>
> Does the following still work after Alt-TAB is overridden?
>
> (w32-send-sys-command #xf040)
>
> This can be bound to whatever event the user wants.

Yes, it minimizes Emacs. Unfortunately it still seems to have focus so
you can not use Alt-TAB after that either.

Re: Key bindings proposal

[Lennart Borgman]

On Fri, Aug 6, 2010 at 5:07 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Fri, Aug 6, 2010 at 8:05 AM, Jason Rumney <jasonr@gnu.org> wrote:
>> On 06/08/2010 11:11, Lennart Borgman wrote:
>>>
>>> On Fri, Aug 6, 2010 at 4:55 AM, Lennart Borgman
>>> <lennart.borgman@gmail.com>  wrote:
>>>
>>>>
>>>> made this work as Jason suggested. I.e. it allows the use of Alt-TAB
>>>> as M-TAB on w32. (The back draw is that you then can not switch to
>>>> other applications using Alt-TAB when in Emacs.)
>>>>
>>>> Other application will still respond the normal way to Alt-TAB.
>>>>
>>>
>>> If this should be usable at all then there must be a way to get into
>>> the normal Alt-TAB behavior from withing Emacs.
>>>
>>
>> Does the following still work after Alt-TAB is overridden?
>>
>> (w32-send-sys-command #xf040)
>>
>> This can be bound to whatever event the user wants.
>
> Yes, it minimizes Emacs. Unfortunately it still seems to have focus so
> you can not use Alt-TAB after that either.
>

Incorrect. The frame is not minimized, but put at the bottom of the
w32 window list. It still has input focus though (both mouse and
keyboard).

Using #xf020 (minimize) works ok.

Re: Key bindings proposal

[Óscar Fuentes]

Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:

[snip]

> Like Juanma, I also don't know why it is essential to use the Windows
> key as meta.

+1. But maybe I'm missing something.

> I am able to use Alt as the meta key in Emacs and also get Alt+TAB to
> switch W32 windows.

Yep.

> I can momentarily depress Alt to activate the menubar.

Nope. Have you some setting in .emacs for that? It doesn't work with
emacs -Q (nor I'll appreciate that behavior.)

[snip]

Re: Key bindings proposal

[Uday S Reddy]

On 8/5/2010 9:33 PM, Óscar Fuentes wrote:

>> I can momentarily depress Alt to activate the menubar.
>
> Nope. Have you some setting in .emacs for that? It doesn't work with
> emacs -Q (nor I'll appreciate that behavior.)

Good guess! I was wondering the whole afternoon.  Setting 
w32-pass-alt-to-system to t does the trick.

The manual says:

Emacs compiled as a native Windows application normally turns off the Windows 
feature that tapping the <ALT> key invokes the Windows menu. The reason is that 
the <ALT> serves as <META> in Emacs. When using Emacs, users often press the 
<META> key temporarily and then change their minds; if this has the effect of 
bringing up the Windows menu, it alters the meaning of subsequent commands. 
Many users find this frustrating.

You can re-enable Windows' default handling of tapping the <ALT> key by setting 
w32-pass-alt-to-system to a non-nil value.

----

The first paragraph is a bit misleading.  But, more mysteriously there is no 
doc-string for this variable.  So, it is quite hidden.  I will file a bug report.

Cheers,
Uday

Re: Key bindings proposal

[Lennart Borgman]

On Thu, Aug 5, 2010 at 11:26 PM, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote:
> On 8/5/2010 9:33 PM, Óscar Fuentes wrote:
>
>>> I can momentarily depress Alt to activate the menubar.
>>
>> Nope. Have you some setting in .emacs for that? It doesn't work with
>> emacs -Q (nor I'll appreciate that behavior.)
>
> Good guess! I was wondering the whole afternoon.  Setting
> w32-pass-alt-to-system to t does the trick.
>
> The manual says:
>
> Emacs compiled as a native Windows application normally turns off the
> Windows feature that tapping the <ALT> key invokes the Windows menu. The
> reason is that the <ALT> serves as <META> in Emacs. When using Emacs, users
> often press the <META> key temporarily and then change their minds; if this
> has the effect of bringing up the Windows menu, it alters the meaning of
> subsequent commands. Many users find this frustrating.
>
> You can re-enable Windows' default handling of tapping the <ALT> key by
> setting w32-pass-alt-to-system to a non-nil value.


This does not work when sticky keys are enabled.

It does however in my patched Emacs. (Starting from "emacs -Q" and
just setting w32-pass-alt-to-system to t.)

RE: Key bindings proposal

[Drew Adams]

> there is no doc-string for this variable [`w32-pass-alt-to-system'].

I see this doc string for it:

"Non-nil if Alt key presses are passed on to Windows.
When non-nil, for example, Alt pressed and released and then space will
open the System menu.  When nil, Emacs processes the Alt key events, and
then silently swallows them."

Re: Key bindings proposal

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Thu, 5 Aug 2010 17:05:27 -0700
> Cc: 
> 
> > there is no doc-string for this variable [`w32-pass-alt-to-system'].
> 
> I see this doc string for it:
> 
> "Non-nil if Alt key presses are passed on to Windows.
> When non-nil, for example, Alt pressed and released and then space will
> open the System menu.  When nil, Emacs processes the Alt key events, and
> then silently swallows them."

I guess Uday was looking in Emacs 23, where this variable indeed was
not documented.

Re: Key bindings proposal

[Stephen J. Turnbull]

Óscar Fuentes writes:
 > Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:
 > 
 > [snip]
 > 
 > > Like Juanma, I also don't know why it is essential to use the Windows
 > > key as meta.
 > 
 > +1. But maybe I'm missing something.

It's not essential, but I really appreciate having Meta on the outside
(where my little finger can press it).  It's also nice in X because of
the number of window managers that willy-nilly steal Alt for their own
use.

Re: Key bindings proposal

[Lennart Borgman]

On Fri, Aug 6, 2010 at 5:21 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
>
> It's not essential, but I really appreciate having Meta on the outside
> (where my little finger can press it).  It's also nice in X because of
> the number of window managers that willy-nilly steal Alt for their own
> use.

Maybe using CapsLock as the default META would be good?

Re: Key bindings proposal

[Stephen J. Turnbull]

Lennart Borgman writes:
 > On Fri, Aug 6, 2010 at 5:21 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
 > >
 > > It's not essential, but I really appreciate having Meta on the outside
 > > (where my little finger can press it).  It's also nice in X because of
 > > the number of window managers that willy-nilly steal Alt for their own
 > > use.
 > 
 > Maybe using CapsLock as the default META would be good?

Dunno.  I wouldn't find that useful.  I use CapsLock as JapaneseLock,
and presumably the person who suggested it to me does it too, so it
might be common practice to bind it to an input method switcher.

Re: Key bindings proposal

[Tassilo Horn]

On Friday 06 August 2010 07:22:14 Stephen J. Turnbull wrote:

>  > Maybe using CapsLock as the default META would be good?
> 
> Dunno.  I wouldn't find that useful.

Ditto.

> I use CapsLock as JapaneseLock, and presumably the person who
> suggested it to me does it too, so it might be common practice to bind
> it to an input method switcher.

I use it as additional Control key (which is pretty common IMO), and
basically I don't use the left and right "real" Control keys at all, so
those would be free.  But the usual Alt seems more convenient to me.
(And for all things window manager related, I use the Super [windows]
key.)

I think it is much better to configure those things globally for X
instead of inside emacs.  I guess, anyone who wants to press C with
CapsLock wants to do that in all apps, and it's the same for Alt/Meta or
sticky modifier keys...

Bye,
Tassilo

Re: Key bindings proposal

[Miles Bader]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> It's not essential, but I really appreciate having Meta on the outside
> (where my little finger can press it).  It's also nice in X because of
> the number of window managers that willy-nilly steal Alt for their own
> use.

I'm a bit confused about how the alt-meta split actually happens in X,
because I've found it _extremely_ hard to get any kind of consistent
behavior (across systems, even those running the same OS / version, and
across apps).

In particular, it seems to depend on the type of keyboard you use (USB
vs. PS/2), and Emacs does not recognize modifier mappings that other
apps do, so I get the feeling Emacs may be using reading keyboard input
at a different level than most apps (e.g., logical vs. physical or
something?).

I dunno.  It's a mess in X generally, but it seems even more of a mess
in X+Emacs...  It's hard even to describe the problem well enough to
come up with a real bug report...

-Miles

-- 
History, n. An account mostly false, of events mostly unimportant, which are
brought about by rulers mostly knaves, and soldiers mostly fools.

Re: Key bindings proposal

[Stephen J. Turnbull]

Miles Bader writes:

 > I'm a bit confused about how the alt-meta split actually happens in
 > X, because I've found it _extremely_ hard to get any kind of
 > consistent behavior (across systems, even those running the same OS
 > / version, and across apps).
 > 
 > In particular, it seems to depend on the type of keyboard you use (USB
 > vs. PS/2), and Emacs does not recognize modifier mappings that other
 > apps do, so I get the feeling Emacs may be using reading keyboard input
 > at a different level than most apps (e.g., logical vs. physical or
 > something?).

Could be.

Another possibility is simply that Emacs tries to cater to broken
keyboard configurations, and (as you might expect) sometimes that
fails.  XEmacs will run, but bitches loudly about it (a behavior
inherited from Lucid Emacs).  The story is here,

    http://www.jwz.org/gruntle/autobogotification.html

the technical details about how Meta and Alt are *defined* by X11 are
here

    http://www.jwz.org/gruntle/autobogotification-b.html

Re: Key bindings proposal

[Uday S Reddy]

Stephen J. Turnbull wrote:

>  > > Like Juanma, I also don't know why it is essential to use the Windows
>  > > key as meta.
>  > 
>  > +1. But maybe I'm missing something.
> 
> It's not essential, but I really appreciate having Meta on the outside
> (where my little finger can press it).  It's also nice in X because of
> the number of window managers that willy-nilly steal Alt for their own
> use.

I agree.  After having thought about for a day, I realize that it is a 
perfectly logical thing to map Windows keys to Meta.  It is wasted keyboard 
real estate otherwise.

Juanma, can this go on the TODO list?

Cheers,
Uday

Re: Key bindings proposal

[Óscar Fuentes]

Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:

> I agree.  After having thought about for a day, I realize that it is a
> perfectly logical thing to map Windows keys to Meta.  It is wasted
> keyboard real estate otherwise.
>
> Juanma, can this go on the TODO list?

If that goes ahead, please make it easy to go back to the current
configuration. Some keyboards don't have the Windows key(s) on a
convenient place, if they have it at all.

Re: Key bindings proposal

[Uday S Reddy]

Óscar Fuentes wrote:

> If that goes ahead, please make it easy to go back to the current
> configuration. Some keyboards don't have the Windows key(s) on a
> convenient place, if they have it at all.

I am sure it will be controlled by an option, the same way as Alt is handled 
right now.

Cheers,
Uday

RE: Key bindings proposal

[Drew Adams]

> > I agree.  After having thought about for a day, I realize 
> > that it is a perfectly logical thing to map Windows keys to Meta.
> > It is wasted keyboard real estate otherwise.
> >
> > Juanma, can this go on the TODO list?
> 
> If that goes ahead, please make it easy to go back to the current
> configuration. Some keyboards don't have the Windows key(s) on a
> convenient place, if they have it at all.

That would certainly be the _least_ that we could hope for.  I have no objection
to such a feature as an option, but I would not like to see it become the
default for Emacs.

I think the default behavior on Windows is pretty good.  I think Emacs out of
the box should let users use the "Windows" keys (`lwindow', `rwindow') for
something other than Meta (including letting them use it in the regular MS
Windows way).

FWIW: For my personal use I also do this, to allow use of `M-TAB' by Emacs (as
opposed to needing to use `ESC TAB'): (w32-register-hot-key [M-tab])

I'm guessing this is less well known than the possibilities provided by options
`w32-alt-is-meta', `w32-pass-alt-to-system', and `w32-recognize-altgr'.
Sometimes I wonder if we shouldn't provide an option for this behavior, just to
help users find it easier.

Re: Key bindings proposal

[Juanma Barranquero]

On Fri, Aug 6, 2010 at 19:32, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote:

> Juanma, can this go on the TODO list?

It's not my decision. Send a wishlist bug report, and we'll see
whether someone steps forward to implement it.

    Juanma

Re: Key bindings proposal

[Chong Yidong]

Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:

>> It's not essential, but I really appreciate having Meta on the outside
>> (where my little finger can press it).  It's also nice in X because of
>> the number of window managers that willy-nilly steal Alt for their own
>> use.
>
> I agree.  After having thought about for a day, I realize that it is a
> perfectly logical thing to map Windows keys to Meta.  It is wasted
> keyboard real estate otherwise.

No, this is too idiosyncratic to make it the default.

Even for non-default usage, putting Emacs in charge of the Windows key
seems unacceptable.  This is the domain of the operating system.

Doesn't the Windows world have some equivalent of `xmodmap'?  That's the
conceptually correct way to handle this.

Re: Key bindings proposal

[Lennart Borgman]

On Mon, Aug 9, 2010 at 12:22 AM, Chong Yidong <cyd@stupidchicken.com> wrote:
> Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:
>
>>> It's not essential, but I really appreciate having Meta on the outside
>>> (where my little finger can press it).  It's also nice in X because of
>>> the number of window managers that willy-nilly steal Alt for their own
>>> use.
>>
>> I agree.  After having thought about for a day, I realize that it is a
>> perfectly logical thing to map Windows keys to Meta.  It is wasted
>> keyboard real estate otherwise.
>
> No, this is too idiosyncratic to make it the default.
>
> Even for non-default usage, putting Emacs in charge of the Windows key
> seems unacceptable.  This is the domain of the operating system.

I think the Alt key is far more important.

> Doesn't the Windows world have some equivalent of `xmodmap'?  That's the
> conceptually correct way to handle this.

No really. It tries to standardize instead (and I believe it got it
huge user base from that).

Re: Key bindings proposal

[David De La Harpe Golden]

Apart from anything else, on x11, the windows keys are nowadays 
conventionally "Super", so x11 emacs already tends to see them as, well, 
"Super".


Xorg with a PC keyboard tends to map the windoze keys to the 
Super_L/Super_R modifiers.  x11 emacs therefore sees them as "Super" 
("s-" in emacs, as opposed to shift which is "S-").

(w32 emacs apparently calls them lwindow/rwindow and binds them to ignore)

X.org maps that menu key to the right of the right windows key to 
"Menu", which x11 emacs considers to be "menu", bound to 
execute-extended-command (i.e. M-x), at least if it gets to see it (i.e. 
window manager or whatever hasn't already eaten it).

(w32 emacs apparently calls it "apps" when it sees it and doesn't bind 
it to anything)

[On x11, I therefore put my window manager's various keybindings on 
Super (they're windows keys, heh), freeing up x11 Alt for emacs' Meta. 
Yes, I realise doing that on w32 is far harder than on x11.]


For completeness:

ns emacs encounters *step-type keys, apparently interpreting them (by 
default) as:

step-"Control" => emacs Control,
step-"Alternate" => Alt -> emacs Meta,
step-"Command" => emacs Super,
step-"Help" => emacs Hyper.

GNUstep/x11 itself can also be told which _x11_ keys to consider
which *step keys with the "defaults" tool e.g. you might do

NSGlobalDomain GSFirstControlKey Control_L
NSGlobalDomain GSFirstCommandKey Super_L
NSGlobalDomain GSFirstAlternateKey Alt_L
NSGlobalDomain GSSecondHelpKey Super_R
NSGlobalDomain GSSecondControlKey Control_R
etc.

(those are not the current out-of-box gnustep settings, they're choices 
that meant gnustep/x11 emacs' default mapping wound up close to x11 emacs)

On a real macosx keyboard, though, physically, compared to a PC:
"Control" tends to be similarly positioned to PC Control
"Command" roughly where a PC has Alt.
"Alternate" (well, "Option") roughly where a PC has windows keys.

Re: Key bindings proposal

[Chong Yidong]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> I think the Alt key is far more important.

Why is it any more important than on any other platform?  Practically no
one uses a keyboard with separate Alt and Meta keys anymore, so it makes
sense to translate the alt key to a Meta event, as we do on GNU/Linux.

Re: Key bindings proposal

[Lennart Borgman]

On Mon, Aug 9, 2010 at 1:09 AM, Chong Yidong <cyd@stupidchicken.com> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> I think the Alt key is far more important.
>
> Why is it any more important than on any other platform?  Practically no
> one uses a keyboard with separate Alt and Meta keys anymore, so it makes
> sense to translate the alt key to a Meta event, as we do on GNU/Linux.


I really think you know:

- Alt-TAB is very important, at least on w32. It switches application
(or rather application level window).
- Alt+Letter (or Alt and then Letter) is used to open menus.

The Window key is of course also important, but:

- The most common use of it is to open the Start Menu. You can do that
with Ctrl-Esc too, at least on w32.
- Also, on other platforms Emacs commonly seem to bind the Windows key.
- On other platforms it is often used

Re: Key bindings proposal

[Chong Yidong]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> I really think you know:
>
> - Alt-TAB is very important, at least on w32. It switches application
> (or rather application level window).
> - Alt+Letter (or Alt and then Letter) is used to open menus.

Again, how is this different from other platforms?

Re: Key bindings proposal

[Lennart Borgman]

On Mon, Aug 9, 2010 at 1:42 AM, Chong Yidong <cyd@stupidchicken.com> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> I really think you know:
>>
>> - Alt-TAB is very important, at least on w32. It switches application
>> (or rather application level window).
>> - Alt+Letter (or Alt and then Letter) is used to open menus.
>
> Again, how is this different from other platforms?


I think you know the other platforms better.

But one important thing to notice is that on w32 there is one window
manager (with just small variations relevant here). This means that
most people on w32 expects the common standards to work, especially
those above. (I.e. if they are keyboard users and I guess those
interested in Emacs are that.)

What is unclear to you in this respect? I have not seen anything that
I would regard as seriously doubt here of what I wrote above.

Re: Key bindings proposal

[Uday S Reddy]

Lennart Borgman writes:

> >> I really think you know:
> >>
> >> - Alt-TAB is very important, at least on w32. It switches application
> >> (or rather application level window).
> >> - Alt+Letter (or Alt and then Letter) is used to open menus.
>
> But one important thing to notice is that on w32 there is one window
> manager (with just small variations relevant here). This means that
> most people on w32 expects the common standards to work, especially
> those above. (I.e. if they are keyboard users and I guess those
> interested in Emacs are that.)

I am not sure that this is a clincher argument.  The "common
standards" apply equally to the windows-key, which you are proposing
to give up.

The point is that one has to use one kind of modifier keys (either the
alt-keys or windows-keys) for the Emacs meta-key.  It would be good to
provide the users with a choice in this regard.  

Cheers,
Uday

RE: Key bindings proposal

[Drew Adams]

>> most people on w32 expects the common standards to work, especially
>> those above.

You privilege compatibility with Windows.  It is often better to privilege
compatibility with Emacs on other platforms.  One of the advantages of Emacs is
that it runs on multiple platforms.  A related advantage is that most of its
default behavior is the same across platforms.  This advantage is felt most, of
course, by users of more than one platform, but it is also an advantage
(simplification) for doc etc.

The Alt key is available on most platforms, and Emacs uses it by default for
Meta. The Window key is available on PC keyboards, but its "common standard"
behavior is generally MS Windows-specific.

It should be a no-brainer that the Emacs default would use Alt (not the Window
key) for Meta on Windows also.

> The point is that one has to use one kind of modifier keys (either the
> alt-keys or windows-keys) for the Emacs meta-key.  It would be good to
> provide the users with a choice in this regard.  

A choice is almost always a good thing.  I support that.  And I agree with you
that it would be bad to change the default to this.

Other things being equal(*), it is desirable to have the same defaults across
multiple platforms.

---
* "Other things being equal..." generally means, "IF other things are/were
equal...".  Yes, it is a bit misleading - it can seem to _assert_ that all other
things are in fact equal. http://en.wikipedia.org/wiki/Other_things_being_equal

RE: Key bindings proposal

[Stephen J. Turnbull]

Drew Adams writes:

 > Other things being equal(*),

Use "ceteris paribus".  Not only does it enhance the writer's image of
erudition (except among economists, where it's first year undergradate
required vocabulary), but it signals to real people that something
really weird and counterfactual is coming next. ;-)

Re: Key bindings proposal

[Chong Yidong]

Lennart Borgman <lennart.borgman@gmail.com> writes:

>>> - Alt-TAB is very important, at least on w32. It switches application
>>> (or rather application level window).
>>> - Alt+Letter (or Alt and then Letter) is used to open menus.
>>
>> Again, how is this different from other platforms?
>
> I think you know the other platforms better.
>
> What is unclear to you in this respect? I have not seen anything that
> I would regard as seriously doubt here of what I wrote above.

None of your points are Windows specific.  On POSIX platforms, Alt-TAB
is used commonly with to switch windows, and Alt-LETTER to open menus.
But your proposed solution is myopically focused on Windows, and I have
not seen a good explanation of why it should be so.

> But one important thing to notice is that on w32 there is one window
> manager (with just small variations relevant here). This means that
> most people on w32 expects the common standards to work, especially
> those above. (I.e. if they are keyboard users and I guess those
> interested in Emacs are that.)

Hijacking the Windows key is not exactly following the "common
standards".

Re: Key bindings proposal

[Andreas Schwab]

Chong Yidong <cyd@stupidchicken.com> writes:

> On POSIX platforms, Alt-TAB is used commonly with to switch windows,
> and Alt-LETTER to open menus.

POSIX does not have windows and menus.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Key bindings proposal

[Jan Djärv]

Andreas Schwab skrev 2010-08-12 17.46:
> Chong Yidong<cyd@stupidchicken.com>  writes:
>
>> On POSIX platforms, Alt-TAB is used commonly with to switch windows,
>> and Alt-LETTER to open menus.
>
> POSIX does not have windows and menus.
>

Not now, but there was a Motif and Openlook group in POSIX.  It was cancelled 
in 93.  Also GUI usability and Ada bindings to X had working groups.

	Jan D.

Re: Key bindings proposal

[Lennart Borgman]

On Thu, Aug 12, 2010 at 5:21 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>>>> - Alt-TAB is very important, at least on w32. It switches application
>>>> (or rather application level window).
>>>> - Alt+Letter (or Alt and then Letter) is used to open menus.
>>>
>>> Again, how is this different from other platforms?
>>
>> I think you know the other platforms better.
>>
>> What is unclear to you in this respect? I have not seen anything that
>> I would regard as seriously doubt here of what I wrote above.
>
> None of your points are Windows specific.  On POSIX platforms, Alt-TAB
> is used commonly with to switch windows, and Alt-LETTER to open menus.
> But your proposed solution is myopically focused on Windows, and I have
> not seen a good explanation of why it should be so.

I am glad they are not Windows specific (but wonder why you say I am
myopically focused on Windows).

As Andreas already have pointed out POSIX does not define those
things. So what I am interested in is how the different window
managers handles this - and you answered that. Your answer is a
repeating what others have said here before: the Alt key is commonly
used by the window managers.

And I think it is unfortunate that Emacs by default takes it since a
keyboard user might be very used to use it the way they are used
above.

>> But one important thing to notice is that on w32 there is one window
>> manager (with just small variations relevant here). This means that
>> most people on w32 expects the common standards to work, especially
>> those above. (I.e. if they are keyboard users and I guess those
>> interested in Emacs are that.)
>
> Hijacking the Windows key is not exactly following the "common
> standards".

This is in open door. I have never said that. What I have said is that
it seems better to use the windows key since I believe it is fair to
assume it is not used that frequently by most users.  (And I am quite
surprised that I have to tell this once again.)

Re: Key bindings proposal

[Juanma Barranquero]

On Thu, Aug 12, 2010 at 17:59, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> What I have said is that
> it seems better to use the windows key since I believe it is fair to
> assume it is not used that frequently by most users.

The following Windows-key combinations are reserved in one or more
Windows releases: b, ctrl-b, c, d, e, f, ctrl-f, g, h, l, m, shift-m,
p, r, t, u, v, f1, pause, shift, space, tab, ctrl-tab, 0-9, shift-0-9,
ctrl-0-9, alt-0-9, alt-enter, home, up, down, left, right, shift-up,
shift-left, shift-right, +.

And, when using some programs (like OneNote, etc.): x, esc,
kp-subtract, -, n, s.

Many of them do quite useful things, see for example
http://en.wikipedia.org/wiki/Features_new_to_Windows_7#Keyboard_shortcuts

So, in which world is the Windows key "not used that frequently"?

    Juanma

Re: Key bindings proposal

[Uday S Reddy]

Juanma Barranquero writes:

> Many of them do quite useful things, see for example
> http://en.wikipedia.org/wiki/Features_new_to_Windows_7#Keyboard_shortcuts

Hi guys, I am not sure where this discussion is headed.  Whether these
applications of the windows key are "useful" or not is for the users
to determine, is it not?

The same web page also mentions that, Linuxen call the key the "meta"
or "super" key.  So, it is not unreasonable to request that we should
have the option under Windows too?

We are talking about providing the users with a choice between

- keyboard access to Emacs's own menus, and

- the fancy applications for a pair of modifier keys that Microsoft
dreamt up of as justification for putting its own trademark on them.

Is that choice so hard to understand?

- Uday Perplexed

Re: Key bindings proposal

[Uday S Reddy]

Uday S Reddy writes:

> Juanma Barranquero writes:
> 
> > Many of them do quite useful things, see for example
> > http://en.wikipedia.org/wiki/Features_new_to_Windows_7#Keyboard_shortcuts
> 
> The same web page also mentions that, Linuxen call the key the "meta"
> or "super" key.

Sorry, it wasn't the same web page.  It was this one:

  http://en.wikipedia.org/wiki/Windows_key

Cheers,
Uday

Re: Key bindings proposal

[Juanma Barranquero]

On Thu, Aug 12, 2010 at 23:57, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote:

> Hi guys, I am not sure where this discussion is headed.  Whether these
> applications of the windows key are "useful" or not is for the users
> to determine, is it not?

Am I not a user? Can't I state that I wouldn't want Emacs to
forcefully hijack the Windows key for meta? (Having it as an option is
fine, though; I wouldn't set it up in a million years.)

> So, it is not unreasonable to request that we should
> have the option under Windows too?

Nobody has argued against the *option*, I think. Me, I deny the
*necessity* that Lennart posits.

> We are talking about providing the users with a choice between
>
> - keyboard access to Emacs's own menus, and

I can access Emacs' own menus quite well if I set `w32-pass-alt-to-system'.

> - the fancy applications for a pair of modifier keys that Microsoft
> dreamt up of as justification for putting its own trademark on them.

You don't find them useful. That does not make it "fancy applications".

> Is that choice so hard to understand?

It is a false choice.

IIUC, the trouble is using Alt with StickyKeys. If so, Lennart is
invited to try and find a fix for that which does not force every
Windows user to switch to "Windows is meta".

> - Uday Perplexed

Rhetorical  [http://www.unseelie.org/rpg/question.html]

    Juanma

Re: Key bindings proposal

[Lennart Borgman]

On Fri, Aug 13, 2010 at 12:12 AM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Thu, Aug 12, 2010 at 23:57, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote:
>
>> Hi guys, I am not sure where this discussion is headed.  Whether these
>> applications of the windows key are "useful" or not is for the users
>> to determine, is it not?
>
> Am I not a user? Can't I state that I wouldn't want Emacs to
> forcefully hijack the Windows key for meta? (Having it as an option is
> fine, though; I wouldn't set it up in a million years.)


We have only been talking about having it as an option. (If that
option should make it default is another question.)

This is already implemented in my patched version of Emacs. (The
default there is still using Alt as Emacs META since I did not want to
confuse new users.)


> IIUC, the trouble is using Alt with StickyKeys. If so, Lennart is
> invited to try and find a fix for that which does not force every
> Windows user to switch to "Windows is meta".


There are several troubles, but this is a main one, yes.

And it is already implemented in my patched version of Emacs.

Like the other patch above it has been there for several years now.

Re: Key bindings proposal

[Juanma Barranquero]

On Fri, Aug 13, 2010 at 01:02, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> We have only been talking about having it as an option. (If that
> option should make it default is another question.)

No, it is the same question as long as you insist that the reason you
use your keyboard changes in your fork is because they are necessary
to use alt on Windows (the wording varies among threads, but that's
the general idea).

> This is already implemented in my patched version of Emacs. (The
> default there is still using Alt as Emacs META since I did not want to
> confuse new users.)

Glad to hear that.

> And it is already implemented in my patched version of Emacs.
>
> Like the other patch above it has been there for several years now.

The operating word being "there", of course.

    Juanma

Re: Key bindings proposal

[Uday S Reddy]

Juanma Barranquero writes:

> Am I not a user? Can't I state that I wouldn't want Emacs to
> forcefully hijack the Windows key for meta?

Yes, sure.  But, I think you are joining in in a subthread where
Yidong has been pushing the view that treating the windows key as meta
is unreasonable.  On the other hand, the wikipedia page on the windows
key says that it is *freqently* done.

> > We are talking about providing the users with a choice between
> >
> > - keyboard access to Emacs's own menus, and
> 
> I can access Emacs' own menus quite well if I set `w32-pass-alt-to-system'.

We have been through this before.  The current Emacs provision is
sub-optimal for normal users like me, and it is unworkable for
sticky-keys uses like Lennart.

> > - the fancy applications for a pair of modifier keys that Microsoft
> > dreamt up of as justification for putting its own trademark on them.
> 
> You don't find them useful. That does not make it "fancy applications".

Well, those of us that depend on commercial products develop antennae
that can sense the difference between a marketing gimmick and a truly
engineered feature.  The Microsoft-branded windows keys (for which the
keyboard manufacturers have to pay a royalty to Microsoft!) seem to
fall in the former camp.  So, the more we can violate Microsoft's
designs, the better we feel.

By arguing for using the windows key the Microsoft way, you are
unwittingly championing the Microsoft gimmicry.

> > Is that choice so hard to understand?
> 
> It is a false choice.

Is it really?  The majority of the functions that have been put on the
windows key can already be obtained by other means.

Win = C+Esc
Win+Tab = Alt+Tab
Win+F1 = F1
Win+R = C+Esc R
Win+F = C+Esc f
Win+Pause = C+Esc R sysdm.cpl (ok, that one needed some research!)
Win+L = C+Alt+Delete
win+[up] = Alt+Space x

and so on.  Many other functions are quite infrequently used.  None of
them seems important enough to give up good keyboard access to Emacs's
own menus.

For the seasoned Emacs users, something like 90% of our work is done
inside Emacs and only around 10% in Windows.  So, it makes sense for
us to put as many resources as possible at Emacs's disposal rather
than Windows.  I am afraid the logic is on Lennart's side.

For better or worse, Microsoft has ended up providing us with a good
pair of modifier keys.  Now, let us put them to good use!

> > - Uday Perplexed
> 
> Rhetorical  [http://www.unseelie.org/rpg/question.html]

Ok, I plead guilty to that charge.  But I have a point as well.

Cheers,
Uday

RE: Key bindings proposal

[Drew Adams]

> the wikipedia page on the windows key says that [treating
> the windows key as meta] is *freqently* done.

On what basis does Wikipedia say that?
Do you believe it is true?  Why?

> For the seasoned Emacs users, something like 90% of our work is done
> inside Emacs and only around 10% in Windows.

My guess (just a guess) is that there are many, many of us Emacs users on
Windows who are *UN*seasoned according to that statement.  One at least: me.  I
use Windows applications (outside of Emacs) for most of what I do all day.  Call
me an Emacs newbie.

Like many Windows users (a guess, based on what I see), I use neither ALT for
Windows-specific features (e.g. ALT-TAB) nor the Window key for Windows-specific
features.  And that is the case regardless of whether I'm using Emacs.  (I've
used the Window key to bring up Windows Explorer - but generally only on other
people's desktops when they don't have a shortcut to it.)

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.

That's a lot of guesses ("many", "most") on my part, admittedly.  What does
Wikipedia say? ;-)

Of course it is not all-important what many or most Windows users do.  Even if
only 0.00001% of them use menu accelerators or whatever, it might still be a
good idea for Emacs to support such a feature - as an _option_.

Being able to use menu accelerators or use the Window key as Meta (or as Control
or Super or Hyper or...) as an _optional_ behavior is one thing.  AFAIK, no one
has objected to that, so if that is all you are arguing about then the story
should be over and done.  Send a patch for consideration to provide such
optional behavior.

But making Emacs give up ALT as Meta by default on some particular platform
would be quite another thing.  I do not see any good reason for that.  Other
things being equal, it is good for Emacs to have the same default keys across
platforms.

And ALT as Meta in Emacs is as old as the hills and as common as their
wildflowers.  What does Wikipedia say about that?  Does it tell you that using
ALT as Meta "is *frequently* done" in Emacs?

> So, it makes sense for us to put as many resources as possible at Emacs's
> disposal rather than Windows.

Which means what?  That's just as much an argument for keeping the defaults the
way they are, ALT for Meta and letting users bind the Window key in Emacs if
they like.

> I am afraid the logic is on Lennart's side.

Do not be afraid. ;-)  But do show the logic please, if there is any.

> For better or worse, Microsoft has ended up providing us with a good
> pair of modifier keys.  Now, let us put them to good use!

ALT as Meta key is definitely put to good use by Emacs.  On all platforms.  Out
of the box.  Always has been.  You can easily move among platforms and keyboards
and change nothing about how you use the ALT key.

Well, on Windows you might need to first set a variable or two to prevent
Windows from grabbing ALT for its own use in some cases.  But other than that
using ALT in Emacs is pretty transparent across platforms.

If you want to argue that Emacs should by default grab ALT for Meta in all cases
(including for example `(w32-register-hot-key [M-tab])', then go for it: make
the argument.  Personally, I probably would not object to such a change.

The Window key, on the other hand, is not available for non-PC keyboards.  There
is no special reason to give it any default behavior in Emacs.  Leave it open,
for users to bind as they wish.

Re: Key bindings proposal

[Lennart Borgman]

On Fri, Aug 13, 2010 at 4:42 PM, Drew Adams <drew.adams@oracle.com> wrote:
>
> 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.

RE: Key bindings proposal

[Drew Adams]

> > 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.

I say that my guess is that the percentage of Windows users that regularly use -
or even who have _ever_ tried to use - menu accelerators is very, very, _very_
small.  It simply is not a large part of the global Windows experience.  That's
my guess.

Do do guess differently?  Do you guess that _most_ Windows users use menu
accelerators?  Or even 10% of Windows users?  Or 1%?  What's your guess?

Do your mother, sister, cousin, neighbor, doctor, dentist, car mechanic, and
grocer (who all use Windows no doubt) use Windows menu accelerators?  Have they
even heard of such a thing?

No way.  That's _my_ guess.

Would they care to use accelerators if you told them about their existence and
how terribly handy they are?  Point them to the URL you passed along as proof of
the importance.  See how quickly they adopt this feature that you feel is so
vital to Windows.

No way.  That's _my_ guess.

Re: Key bindings proposal

[Lennart Borgman]

On Fri, Aug 13, 2010 at 6:09 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> > 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.

People who are mostly programmers or similar might never learn that
kind of things. 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.)

Re: Key bindings proposal

[David Robinow]

On Fri, Aug 13, 2010 at 12:15 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Fri, Aug 13, 2010 at 6:09 PM, Drew Adams <drew.adams@oracle.com> wrote:
>>> > 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.
The existence of documentation does not imply that people read it. I
use Word frequently and I've never seen that doc.
 I just looked at a copy of the Word 2003 textbook formerly used at
our local junior college (ISBN 1-4188-3911-6) and in over 600 pages I
see NO MENTION of Alt+Letter usage. I simply don't believe that is the
way most MS Word users are educated.
I've used Windows since 3.1 and I've never used that feature (except
during discussions such as this one where I've tried things just to
see if they work)
Menu accelerators are only useful when one's mouse is broken.
>
> People who are mostly programmers or similar might never learn that
> kind of things. 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.)
 Yes, many people use MS Word. That's one of the reasons Bill Gates is
a multi-billionaire. Most of them don't use Alt+Letter.

RE: Key bindings proposal

[Drew Adams]

> >> > 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
circles.

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
options).

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.

RE: Key bindings proposal

[Uday S Reddy]

Drew Adams writes:

> > the wikipedia page on the windows key says that [treating the
> > windows key as meta] is *freqently* done.
> 
> On what basis does Wikipedia say that?  Do you believe it is true?
> Why?

I am by no means an expert on the low-level keyboard issues.  So,
people can correct me if I am wrong.  

Alt is "hyper" and the windows key is "super".  PC keyboards don't
have a "meta".  Therefore, the systems that want a meta-key map one of
these to meta.  It looks like desktops such as KDE and Gnome map the
windows key as meta, and their users, who presumably contributed to
the Wikipedia article, say "windows key is also known as the
meta-key".  They are not exactly right, but I admire their diligence
in countering the Microsoft corporatization of the everyday keyboard.
Such spirit seems to be sadly lacking on this mailing list :-(

> 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.

I think the issues of "most Windows users" are not relevant here.
This is emacs-developers mailing list after all.  We are only
interested in Windows users that also use Emacs.  And, these users can
learn key bindings if they think they are useful.

> Being able to use menu accelerators or use the Window key as Meta
> (or as Control or Super or Hyper or...) as an _optional_ behavior is
> one thing.  AFAIK, no one has objected to that, so if that is all
> you are arguing about then the story should be over and done.

That is indeed what we are arguing about, because Yidong has said (on
8 Aug):

> Even for non-default usage, putting Emacs in charge of the Windows key
> seems unacceptable.  This is the domain of the operating system.

Both Lennart and I have clarified many times that we are not arguing
about defaults.  We are arguing about capabilities.  Emacs, at the
moment, does not have the capability to treat the windows key as
meta.  Lennart knows how to do it, and he can possibly be persuaded to
provide a patch, but welcoming his idea a bit more warmly on this
mailing list would be a good first step.

> And ALT as Meta in Emacs is as old as the hills and as common as
> their wildflowers.  What does Wikipedia say about that?  Does it
> tell you that using ALT as Meta "is *frequently* done" in Emacs?

Come on.  Meta keys existed before Bill Gates learnt to program, and
Emacs has existed long before the PC keyboards came on the scene.

Treating ALT as meta on PC keyboards was a natural choice because they
were free modifier keys.  Nobody is faulting Emacs for having done
that.  But, the current position is that enough keyboards have the
windows/super key and Microsoft has unlocked it on Windows, according
to Lennart.  And, using the windows/super key as meta provides
significant advantages in enabling keyboard access to the Emacs
menubar.

> Do not be afraid. ;-) But do show the logic please, if there is any.

I just stated it above, for the umpteenth time.  

The rest of your post is not relevant because it is talking about
defaults, which we are not.  You can read it again and note that it is
irrelevant.

Cheers,
Uday

> 
> > For better or worse, Microsoft has ended up providing us with a
> > good pair of modifier keys.  Now, let us put them to good use!
> 
> ALT as Meta key is definitely put to good use by Emacs.  On all
> platforms.  Out of the box.  Always has been.  You can easily move
> among platforms and keyboards and change nothing about how you use
> the ALT key.
> 
> Well, on Windows you might need to first set a variable or two to
> prevent Windows from grabbing ALT for its own use in some cases.
> But other than that using ALT in Emacs is pretty transparent across
> platforms.
> 
> If you want to argue that Emacs should by default grab ALT for Meta
> in all cases (including for example `(w32-register-hot-key
> [M-tab])', then go for it: make the argument.  Personally, I
> probably would not object to such a change.
> 
> The Window key, on the other hand, is not available for non-PC
> keyboards.  There is no special reason to give it any default
> behavior in Emacs.  Leave it open, for users to bind as they wish.
> 
> 

Re: Key bindings proposal

[Juanma Barranquero]

On Fri, Aug 13, 2010 at 18:07, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote:

> Lennart knows how to do it, and he can possibly be persuaded to
> provide a patch

Ha!

(Oops, sorry, did I speak out loud?)

    Juanma

RE: Key bindings proposal

[Drew Adams]

> Alt is "hyper" and the windows key is "super".  PC keyboards don't
> have a "meta".

The PC keyboards I've seen do not have a Hyper key or a Super key either - no
such key labels.  Maybe some PC keyboards do, but the average "everyday" one
does not.

If you want to call the ALT key "Hyper" and the Window key "Super", feel free.
In Emacs, by default we call the ALT key "Meta" (or rather we map the physical
key ALT to the logical key Meta).

> Therefore, the systems that want a meta-key map one of
> these to meta.
>
> It looks like desktops such as KDE and Gnome map the
> windows key as meta, and their users, who presumably contributed to
> the Wikipedia article, say "windows key is also known as the
> meta-key".

Sounds to me more like the KDE and Gnome crowd tried to fit in with Windows and
its users to some extent, by mirroring some of its use of ALT for the OS (window
mgr). ;-)

ALT is a very old key.  Its use by Emacs as Meta is nearly as old.  Use of ALT
by the OS (or window mgr) to do the kinds of things it does for KDE, Gnome, and
Windows is much more recent.

In the old days, before the Almighty Windows, ALT was not used for such things
by the OS or window mgr - at least not the ones I used back then (Control Data,
Univac, IBM, VAX/VMS, various UNIXen,...).  AFAIK, Windows was the one to spread
window-mgr use of ALT far and wide.  In this regard, KDE and Gnome are just
come-lately ugly ducklings waddling to keep up with their Microsoft mom.

If I had to guess (again), I'd guess that KDE & Gnome imitated (shudder!)
Windows to some extent, to try to "fit in" with its user base - precisely the
kind of argument we've been hearing here ("Gee Dad, everyone else is doing
it!").  So to now point to KDE and Gnome as desktops in the GNU/Linux camp that
also use ALT somewhat similar to how Windows uses it is a bit disingenuous.

> They are not exactly right, but I admire their diligence
> in countering the Microsoft corporatization of the everyday keyboard.

Hm.  You push for Windows-compatible behavior while spearheading the attack on
MS.  OK.  I do too sometimes.

To be clear, I have no problem with some of the positive UI ideas introduced by
Windows (i.e. by MS, although often originally by Xerox and others).  I've tried
to add some such features to Emacs myself.  But it does sound curious that you
trumpet KDE/Gnome's "countering of MS" while defending their imitating Windows'
use of ALT.

And you have the cart before the horse.  The PC keyboard does not risk
_becoming_ MS-corporatized.  Your "everyday keyboard" was _engendered_ by
Microsoft and its partner at the time, IBM.  You don't need to save the PC
keyboard from MS; you need to thank or blame MS for it in the first place.

The PC keyboard is the ubiquitous, everyday keyboard precisely _because_ of MS
and Windows and PCs.  Use of PC keyboards with anything other than MS (DOS and
then Windows) is a recent and still largely marginal development, albeit
welcome.

> Such spirit seems to be sadly lacking on this mailing list :-(

I really think you're out there on a limb sawing strong, if you think that this
mailing list is lacking in "diligence in countering the Microsoft
corporatization of the everyday keyboard" (or countering Microsoft tout court).
You want Emacs to roll over and adapt to MS's use of ALT, but somehow the rest
of us are caving in to MS?  What am I missing?

> > 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.
> 
> I think the issues of "most Windows users" are not relevant here.
> This is emacs-developers mailing list after all.  We are only
> interested in Windows users that also use Emacs.  And, these users can
> learn key bindings if they think they are useful.

OK, so what do we know about Windows users who are already Emacs users?  What
proportion of _them_ use menu accelerators or other Windows-specific uses of
ALT?  Do you know?

Personally, I do not limit the set of potential Emacs users to those who already
use it.  And I do not limit it to programmers either.  (I don't claim I am
typical in this regard.)  I see no reason why other, non-programmer users of
Windows might not become Emacs users.  There are some already.

> > Being able to use menu accelerators or use the Window key as Meta
> > (or as Control or Super or Hyper or...) as an _optional_ behavior is
> > one thing.  AFAIK, no one has objected to that, so if that is all
> > you are arguing about then the story should be over and done.
> 
> That is indeed what we are arguing about, because Yidong has said (on
> 8 Aug):
> 
> > Even for non-default usage, putting Emacs in charge of the 
> > Windows key seems unacceptable.  This is the domain of the
> > operating system.

Then you are arguing only with Yidong.  I have not seen anyone argue that Emacs
should not offer such an option.  On the contrary, I've seen several people who
disagree with many of your points agree that there is _no_ problem in principle
with Emacs offering such an option.  I'm one of them.

The devil might be in the details of design or implementation, however - dunno.

If the implementation were trivial, then there would be no hullaballoo.  Suppose
that you could send in a simple Lisp minor mode that let users use Windows
accelerators or use the Window key for Meta.  Piece of cake.  I doubt that even
Yidong would object in that case (but I do not know that).

But much more than that is involved apparently, and I suspect that might be
where Yidong's resistance in this regard is coming from.  If the ability to
provide this as an option involves reworking lots of important C code that no
one understands clearly, then that reworking had better be careful, correct, and
worth it.

> Both Lennart and I have clarified many times that we are not arguing
> about defaults.  We are arguing about capabilities.  Emacs, at the
> moment, does not have the capability to treat the windows key as
> meta.  Lennart knows how to do it, and he can possibly be persuaded to
> provide a patch, but welcoming his idea a bit more warmly on this
> mailing list would be a good first step.

I, for one, do welcome Lennart's idea warmly, if the idea is to provide such a
thing as an option.  Just as I warmly welcome his idea of letting Emacs users
take advantage of Windows menu accelerators.  (I adapted my own Lisp library
lacarte.el to fit that feature from his library menuacc.el many years ago.)
I've said this several times now.

And I really do not see _any_ opposition to such an idea.  But the code
providing such optional behavior needs to be clear - and truly optional.  No one
is going to immediately adopt a wholesale rewrite of lots of basic Emacs C code
without it being clear and complete and tested, and without the pros and cons
(of the implementation) being investigated closely.

Above all, the behavior needs to be truly optional.  With the option turned off
by default, the code changes, whatever they are, need to amount to a no-op.

I have not followed the implementation discussion, but from what I gathered
things are not so clear.  Others will have to judge that, not I.

> > And ALT as Meta in Emacs is as old as the hills and as common as
> > their wildflowers.  What does Wikipedia say about that?  Does it
> > tell you that using ALT as Meta "is *frequently* done" in Emacs?
> 
> Come on.  Meta keys existed before Bill Gates learnt to program, and
> Emacs has existed long before the PC keyboards came on the scene.

Precisely.  If by "Meta" you mean using ALT as a Meta key.  Yes, that predates
Bill and PCs.  That was the point of the text you quoted.  It is surely a lot
more "*frequently* done" to use ALT than the Window key for Meta.

> Treating ALT as meta on PC keyboards was a natural choice because they
> were free modifier keys.  Nobody is faulting Emacs for having done
> that.  But, the current position is that enough keyboards have the
> windows/super key and Microsoft has unlocked it on Windows, according
> to Lennart.  And, using the windows/super key as meta provides
> significant advantages in enabling keyboard access to the Emacs
> menubar.

Having any such key available provides significant advantages, no matter what
behavior is mapped to it.  I'm in favor of letting Emacs users bind the Window
key to whatever they want.  If it is "unlocked" then it should be easy for Emacs
users to bind it to whatever they want, no?

And if it is _not_ easy to do that out of the box, then I, for one, welcome code
that will help users do that.  Being able to bind the Window key to Meta, as one
possibility, one option, can only be a positive feature - IMO at least.

But the cost (e.g. implementation) has to be worth it.  I do not see opposition
to the _idea_ of such a feature.  I do see reluctance to simply gulp down
whatever brew Lennart has on tap.  Again, I cannot speak to the implementation.
Personally I am in favor of such an option, _other things being equal_.  And
that is so even though I will no doubt never use such an option myself.  I like
Emacs to offer everything to everyone - provided the cost is reasonable.

RE: Key bindings proposal

[Uday S Reddy]

Drew Adams writes:

> The PC keyboards I've seen do not have a Hyper key or a Super key
> either - no such key labels.  Maybe some PC keyboards do, but the
> average "everyday" one does not.
> 
> If you want to call the ALT key "Hyper" and the Window key "Super",
> feel free.  In Emacs, by default we call the ALT key "Meta" (or
> rather we map the physical key ALT to the logical key Meta).

I am not talking about the physical labels.  I am talking about the
low-level key codes that get sent in to the OS.  I don't know enough
about low-level key codes.  What I said is based on what I have seen
written here and there.  Perhaps that is Linux-specific.  I can't say.

> ALT is a very old key.  Its use by Emacs as Meta is nearly as old.
> Use of ALT by the OS (or window mgr) to do the kinds of things it
> does for KDE, Gnome, and Windows is much more recent.
> 
> In the old days, before the Almighty Windows, ALT was not used for
> such things by the OS or window mgr - at least not the ones I used
> back then (Control Data, Univac, IBM, VAX/VMS, various UNIXen,...).
> AFAIK, Windows was the one to spread window-mgr use of ALT far and
> wide.  In this regard, KDE and Gnome are just come-lately ugly
> ducklings waddling to keep up with their Microsoft mom.

I didn't know about the old history of the Alt key.  The IBM PC was
the first time I saw them.  Perhaps you can add some stuff to the
Wikipedia page on the Alt key so that the rest of us can know?

> > They are not exactly right, but I admire their diligence in
> > countering the Microsoft corporatization of the everyday keyboard.
> 
> Hm.  You push for Windows-compatible behavior while spearheading the
> attack on MS.  OK.  I do too sometimes.
> 
> ...
> 
> And you have the cart before the horse.  The PC keyboard does not
> risk _becoming_ MS-corporatized.  Your "everyday keyboard" was
> _engendered_ by Microsoft and its partner at the time, IBM.  You
> don't need to save the PC keyboard from MS; you need to thank or
> blame MS for it in the first place.

We are going off-topic here.  So, I will be brief.

I am not opposed to commerce.  If a company makes a product that is
useful to me and charges me money that I can afford, I am happy to buy
it and use it.  That is normal life in a capitalist society.

But I am opposed to commercialization.  The Windows keys were not on
the IBM PC keyboard.  Microsoft added them.  They are good modifier
keys.  So, I have no problem with Microsoft adding them.  My
opposition is to Microsoft branding them, charging royalty to the
keyboard manufacturers, and locking up the keys in Windows-specific
ways so that they are *not free*.  And, software freedom is what we
are here about.  So, it is a surprise to me that the people here don't
attack this violation of freedom as vigorously as possible.

The true free software people might say, "serves you right for using
commercial software."  But that is not right.  Violation of freedom
should be fought no matter what.  These are normal ways for consumers
in a capitalist economy to fight corporatization.  Free software
should ally with them.

In the present instance, that means that, for people like Lennart and
me who need to use the Win keys in ways that Microsoft did not intend,
Emacs should provide all support possible.  Asking us what proportion
of Windows users actually want to use Win keys this way etc., is
irrelevant.

> You want Emacs to roll over and
> adapt to MS's use of ALT, but somehow the rest of us are caving in
> to MS?  What am I missing?

The Alt is not at issue because Emacs can control how the Alt key gets
mapped via the standardard option settings.  It is not able to do so
for the Win key.  Accepting that as life would amount to caving in to
MS, yes.

> Having any such key available provides significant advantages, no
> matter what behavior is mapped to it.  I'm in favor of letting Emacs
> users bind the Window key to whatever they want.  If it is
> "unlocked" then it should be easy for Emacs users to bind it to
> whatever they want, no?
> 
> And if it is _not_ easy to do that out of the box, then I, for one,
> welcome code that will help users do that.  Being able to bind the
> Window key to Meta, as one possibility, one option, can only be a
> positive feature - IMO at least.

Good.  I am glad that we are on the same side!

> But the cost (e.g. implementation) has to be worth it.  I do not see
> opposition to the _idea_ of such a feature.  I do see reluctance to
> simply gulp down whatever brew Lennart has on tap.

Well, a good part of this thread has been spent on repeatedly asking
Lennart and me, "why you do you need to map the Windows key to meta,"
"why is it the best possible solution," "how many people want to do
things that way?" and so on.  Politically, at least, these are not the
right questions to ask.

It is perfectly fine to say, "let us do it outside of Emacs."  Then we
could have focused on what needs to be done and what programs are out
there that can do it, or whether we need to write new programs etc.
That is the kind of stuff that matters.

Cheers,
Uday

Re: Key bindings proposal

[Juanma Barranquero]

On Fri, Aug 13, 2010 at 10:57, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote:

> Yes, sure.  But, I think you are joining in in a subthread where
> Yidong has been pushing the view that treating the windows key as meta
> is unreasonable.

No, he doesn't. He says that making that at the Emacs level is
unreasonable. And I think that making this the default, or implying
that it's the only sane behavior for Windows users, or necessary
somehow, is unreasonable.

> On the other hand, the wikipedia page on the windows key says that it is *freqently* done.

On non-Windows environments. So what?

> We have been through this before.  The current Emacs provision is
> sub-optimal for normal users like me, and it is unworkable for
> sticky-keys uses like Lennart.

Please, reread my e-mail. I already know that. Making Windows to be
meta is much more subotimal to me.

> Well, those of us that depend on commercial products develop antennae
> that can sense the difference between a marketing gimmick and a truly
> engineered feature.

Please! What kind of argument is that? Some appeal to authority?

> The Microsoft-branded windows keys (for which the
> keyboard manufacturers have to pay a royalty to Microsoft!) seem to
> fall in the former camp.  So, the more we can violate Microsoft's
> designs, the better we feel.

Talk for yourself. I don't mind what company's logo is on the key,
just that it is useful to me.

> By arguing for using the windows key the Microsoft way, you are
> unwittingly championing the Microsoft gimmicry.

Even worse: by using Microsoft products I'm doing it too. As you do,
if you're using Windows.

> Is it really?  The majority of the functions that have been put on the
> windows key can already be obtained by other means.

"The majority" != "all".

And, C+Esc is much less convenient for me. I've never used any C+Esc
shortcut because I find them hard to type, while W+key are quite
natural.

> None of
> them seems important enough to give up good keyboard access to Emacs's
> own menus.

I'm glad to know you know what's important for all Windows users.

> For the seasoned Emacs users, something like 90% of our work is done
> inside Emacs and only around 10% in Windows.

I confess I've been using Emacs daily only for thirteen years, so I'm
not seasoned enough. But I certainly don't spend 90% of my time inside
Emacs.

> So, it makes sense for
> us to put as many resources as possible at Emacs's disposal rather
> than Windows.  I am afraid the logic is on Lennart's side.

Only if you define logic as "everyone needs the exact same things that
Lennart and me need, or they are not *really* Windows users".

> For better or worse, Microsoft has ended up providing us with a good
> pair of modifier keys.  Now, let us put them to good use!

I already do.

    Juanma

Re: Key bindings proposal

[Uday S Reddy]

Juanma Barranquero writes:

> > Yes, sure.  But, I think you are joining in in a subthread where
> > Yidong has been pushing the view that treating the windows key as meta
> > is unreasonable.
> 
> No, he doesn't. He says that making that at the Emacs level is
> unreasonable. 

Ok, that was a subtlety that I missed for while.  I have no trouble
using an external program to do key remapping.  But what is it that
you want it to do, to get the windows key act as meta?  I would
appreciate a clear specification.

> And I think that making this the default, or implying
> that it's the only sane behavior for Windows users, or necessary
> somehow, is unreasonable.

Sorry if I gave that impression.  I was only trying to demonstrate
that treating win as meta is *reasonable* (to counter Yidong's push
that it was unreasonable).

Come to think of it, my first PC keyboard probably didn't have the Win
key or had it at some awkward place.  So, I had begun to use Ctrl+Esc
and never paid attention to what the Win key does.  I have been
perfectly happy to use Ctrl+Esc and other combinations to serve all my
Windows needs.

I can well imagine that other users might have come through different
routes and might have different preferences.  I have no problem with
that, obviously.  Neither does Lennart.  Our only problem is that our
preferred solution is not supported by Emacs.  So, excuse me if I
shouted a bit too loudly!

Cheers,
Uday

Re: Key bindings proposal

[Chong Yidong]

Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:

> Hi guys, I am not sure where this discussion is headed.  Whether these
> applications of the windows key are "useful" or not is for the users
> to determine, is it not?

The problem is that Lennart's proposed solution seems to be the wrong
one.  If you want to rebind the Windows key to a modifier key, the
conceptually correct way to do it should be via a separate program,
separate from Emacs.  That is exactly how it is done on GNU/Linux (where
conventions like Alt-TAB are commonly respected, nowadays).

If there is any technical reason why this cannot be done on Windows, I
have not yet seen anyone argue it.

Re: Key bindings proposal

[Óscar Fuentes]

Chong Yidong <cyd@stupidchicken.com> writes:

> The problem is that Lennart's proposed solution seems to be the wrong
> one.  If you want to rebind the Windows key to a modifier key, the
> conceptually correct way to do it should be via a separate program,
> separate from Emacs.  That is exactly how it is done on GNU/Linux
> (where conventions like Alt-TAB are commonly respected, nowadays).
>
> If there is any technical reason why this cannot be done on Windows, I
> have not yet seen anyone argue it.

It is Emacs who is behaving idiosyncratically in Windows, so the fix
must come from Emacs, not from a system-wide change.

Not that I have any problem with the current behavior...

Re: Key bindings proposal

[Chong Yidong]

Óscar Fuentes <ofv@wanadoo.es> writes:

> It is Emacs who is behaving idiosyncratically in Windows, so the fix
> must come from Emacs, not from a system-wide change.

The current standard is used on all platforms: the key labelled "Alt" on
the keyboard is handled internally by Emacs as Meta.

If this is an idiosyncracy, it is a very simple, uniform, and
consistently-applied one.  I don't see a well-reasoned argument for
deviating from it specifically for the Windows port, given that the
de-facto desktop standards (such as the use of Alt-TAB for window
switching) are identical between Windows and modern UNIX-like systems
such as GNU/Linux.

Re: Key bindings proposal

[Óscar Fuentes]

Chong Yidong <cyd@stupidchicken.com> writes:

>> It is Emacs who is behaving idiosyncratically in Windows, so the fix
>> must come from Emacs, not from a system-wide change.
>
> The current standard is used on all platforms: the key labelled "Alt" on
> the keyboard is handled internally by Emacs as Meta.

Windows users couldn't care less about what Emacs does on all the other
platforms.

> If this is an idiosyncracy, it is a very simple, uniform, and
> consistently-applied one.  I don't see a well-reasoned argument for
> deviating from it specifically for the Windows port, given that the
> de-facto desktop standards (such as the use of Alt-TAB for window
> switching) are identical between Windows and modern UNIX-like systems
> such as GNU/Linux.

On standard Windows applications, if you press and release Alt, the menu
is activated. Not so on KDE (most likely KDE has an option for enabling
that behvior, but it is not the default.) Alt+SPC on Windows activates
the window's system menu, used for moving, resizing, minimizing,
closing, etc. Not so on KDE. That feature is valued by people that tend
to avoid using the mouse. Possibly there are more instances.

But if the "problem" affects the other platforms too, that's a good
reason for allowing using the Windows key as Meta on all of them too,
right?

Re: Key bindings proposal

[Juanma Barranquero]

On Fri, Aug 13, 2010 at 22:32, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Windows users couldn't care less about what Emacs does on all the other
> platforms.

Don't try to speak for all Windows users, please.

> On standard Windows applications, if you press and release Alt, the menu
> is activated.

Including Emacs, if you set w32-pass-alt-to-system.

    Juanma

Re: Key bindings proposal

[Óscar Fuentes]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Fri, Aug 13, 2010 at 22:32, Óscar Fuentes <ofv@wanadoo.es> wrote:
>
>> Windows users couldn't care less about what Emacs does on all the other
>> platforms.
>
> Don't try to speak for all Windows users, please.

Are we going the all-or-nothing route here? Again?

Try explaining to someone that a tool he is supposed to use for hours
every day doesn't follow his platform's standards because it supports on
other platforms too. Do you think that would be an unfair response from
him to say "so what? I'm working on *this* platform"

>> On standard Windows applications, if you press and release Alt, the menu
>> is activated.
>
> Including Emacs, if you set w32-pass-alt-to-system.

What's the variable enabling the usual Windows behavior of Alt+SPC?

Seriously, on this topic I'm happy with what Emacs does now, but this is
not about my personal preferences, but about if adding an option for
turning the Windows key into Meta would be appreciated by some users.

Re: Key bindings proposal

[Juanma Barranquero]

On Sat, Aug 14, 2010 at 01:30, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Try explaining to someone that a tool he is supposed to use for hours
> every day doesn't follow his platform's standards because it supports on
> other platforms too.

Do you use Emacs on Windows? How so? Were you able to overcome the
apparently unsurmountable problem of Emacs "not following [your]
platform's standards"?

The amount of problem, and the lack of adaptability of Windows users,
are being wildly overstated.

> Seriously, on this topic I'm happy with what Emacs does now, but this is
> not about my personal preferences, but about if adding an option for
> turning the Windows key into Meta would be appreciated by some users.

No. Nobody is against an *option*, so it's not about that.

    Juanma

Re: Key bindings proposal

[Óscar Fuentes]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Sat, Aug 14, 2010 at 01:30, Óscar Fuentes <ofv@wanadoo.es> wrote:
>
>> Try explaining to someone that a tool he is supposed to use for hours
>> every day doesn't follow his platform's standards because it supports on
>> other platforms too.
>
> Do you use Emacs on Windows? How so? Were you able to overcome the
> apparently unsurmountable problem of Emacs "not following [your]
> platform's standards"?

This is not a dialogue, but something else I'm not interested on
participating.

[snip]

Re: Key bindings proposal

[Juanma Barranquero]

On Sat, Aug 14, 2010 at 02:21, Óscar Fuentes <ofv@wanadoo.es> wrote:

> This is not a dialogue, but something else I'm not interested on
> participating.

It certainly is not a dialogue if you don't answer questions.

But that's OK.

    Juanma

RE: Key bindings proposal

[Drew Adams]

> > The current standard is used on all platforms: the key 
> > labelled "Alt" on the keyboard is handled internally by
> > Emacs as Meta.
> 
> Windows users couldn't care less about what Emacs does on all 
> the other platforms.

W r o n g .     That is sooooo silly.

Lots of people (including yours truly) use multiple platforms (including
Windows) to do their work.  And some of us use Emacs.

FWIW, at Oracle most developers use Windows to access remote GNU/Linux boxes on
farms somewhere out there in the ether.  Many of them use Emacs locally (running
on Windows) as well as remotely (running on GNU/Linux).  Many of them also
access remote files on the GNU/Linux boxes using Emacs running on Windows.

I wouldn't be surprised if the same were true for developers in some other large
companies.

Yes, no doubt that is not representative of most Windows users.  Most Windows
users are not even developers.

The point is that it is ridiculous to claim that "Windows users couldn't care
less about what Emacs does on other platforms."  You have only to look at Emacs
Wiki or help-gnu-emacs@gnu.org, or google for examples of user .emacs files, to
see that some people have init files that are adapted to multiple platforms.

And guess what?  It's _always_ been like that.  Long before there was a Windows
at all people used Emacs on multiple platforms.  And (trust me) they do care
that the default behavior be the same or at least similar on the platforms they
use.

Relative platform independence is an important Emacs feature.
And it's not just about byte code. 

Re: Key bindings proposal

[Óscar Fuentes]

"Drew Adams" <drew.adams@oracle.com> writes:

>> > The current standard is used on all platforms: the key 
>> > labelled "Alt" on the keyboard is handled internally by
>> > Emacs as Meta.
>> 
>> Windows users couldn't care less about what Emacs does on all 
>> the other platforms.
>
> W r o n g .     That is sooooo silly.
>
> Lots of people (including yours truly) use multiple platforms (including
> Windows) to do their work.  And some of us use Emacs.

Please note that I was referring to "Windows users." The part that
depicts them as users of other platforms too is your original addition.

[snip]

RE: Key bindings proposal

[Drew Adams]

> >> > The current standard is used on all platforms
> >> 
> >> Windows users couldn't care less about what Emacs does on all 
> >> the other platforms.
> >
> > W r o n g .     That is sooooo silly.
> >
> > Lots of people (including yours truly) use multiple 
> > platforms (including Windows) to do their work.
> > And some of us use Emacs.
> 
> Please note that I was referring to "Windows users." The part that
> depicts them as users of other platforms too is your original 
> addition.

But that's the point.  The "standard is used on all platforms".  Emacs is
similar, if not the same, on all platforms.  And that's important, including to
some Emacs users.

Why, you say? What do "Windows users" care about other platforms?

Well one reason it is important that a common standard be used across platforms
is that "Windows users" are not necessarily users of Windows _only_.

When you say "Windows users" without qualification that means _all_ Windows
users or Windows users as a class, Windows users in general, as others have
pointed out.

You seemed to be speaking for all Windows users and missing the point that
having similar behavior across platforms could be useful to at least some
Windows users.

This might be mainly an English problem - dunno.  But you can see from the
reactions your assertion provoked that it was taken as a clear statement that no
Windows users (or hardly any) would care about Emacs behavior on other
platforms.  And nothing could be farther from the truth.

RE: Key bindings proposal

[Jeff Clough]

On Fri, 2010-08-13 at 19:05 -0700, Drew Adams wrote:
> > >> > The current standard is used on all platforms
> > >> 
> > >> Windows users couldn't care less about what Emacs does on all 
> > >> the other platforms.
> > >
> > > W r o n g .     That is sooooo silly.
> > >
> > > Lots of people (including yours truly) use multiple 
> > > platforms (including Windows) to do their work.
> > > And some of us use Emacs.
> > 
> > Please note that I was referring to "Windows users." The part that
> > depicts them as users of other platforms too is your original 
> > addition.
> 
> But that's the point.  The "standard is used on all platforms".  Emacs is
> similar, if not the same, on all platforms.  And that's important, including to
> some Emacs users.
> 
> Why, you say? What do "Windows users" care about other platforms?
> 
> Well one reason it is important that a common standard be used across platforms
> is that "Windows users" are not necessarily users of Windows _only_.

Another reason is that the vast majority of third-party Emacs tutorials,
wikis, how-tos, etc. aren't written by Windows users.  So if it's three
in the morning and you're trying to set up foo package using the
customizations from someone using a *nix, the last thing you need is for
things to work differently for you because you're running Windows.

Jeff

-- 
web:  http://www.chaosphere.com
Author of Genesys, a Free Universal Paper and Pencil RPG.
http://www.chaosphere.com/genesys/

Re: Key bindings proposal

[Uday S Reddy]

On 8/13/2010 9:32 PM, Óscar Fuentes wrote:

>
> Windows users couldn't care less about what Emacs does on all the other
> platforms.

I wouldn't go that far.  Emacs is a cross-platform software and it is valuable 
that it is so.

The keyboard is a limited resource. Conflicts are likely to arise when 
cross-platform software is used on multiple platforms.  Emacs may not be able 
to look seamless on each and every platform.  That is life.

But, you and I probably agree that allowing Win key as meta can solve many of 
these problems.  That should be an available option on Emacs.  So, if Yidong 
and Juanma can come back and tell us how to make that happen, we would have 
made some progress.

Cheers,
Uday

Re: Key bindings proposal

[Jason Rumney]

  On 14/8/2010 3:48 PM, Uday S Reddy wrote:

> But, you and I probably agree that allowing Win key as meta can solve 
> many of these problems.  That should be an available option on Emacs.  
> So, if Yidong and Juanma can come back and tell us how to make that 
> happen, we would have made some progress.

Lennart has had advice on how to make such progress in the past, but for 
some reason this topic always seems to degenerate into an argument that 
puts him off following through:

http://lists.gnu.org/archive/html/help-emacs-windows/2007-10/msg00018.html
http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg01574.html

Please lets drop the arguing for and against until we see what his patch 
actually does.

Re: Key bindings proposal

[Juanma Barranquero]

On Sat, Aug 14, 2010 at 09:48, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote:

> So, if
> Yidong and Juanma can come back and tell us how to make that happen, we
> would have made some progress.

Sorry, but no. Lennart's the one that says that he's fixed the
problem, and he's the one saying that his fix is not accepted. But the
fix has not been sent to emacs-devel, or at least, if sent (a long
time, as in several years, ago) the usual procedure to get such a
patch accepted was not followed. So we're all waiting to see the patch
again...

    Juanma

Re: Key bindings proposal

[christian.lynbech]

>>>>> "Chong" == Chong Yidong <cyd@stupidchicken.com> writes:

Chong> The current standard is used on all platforms: the key labelled
Chong> "Alt" on the keyboard is handled internally by Emacs as Meta.

Is this really correct?

It would appear to me (though I have admittedly not checked the source)
that emacs (under X11) uses as meta whatever modifier is assigned the
Meta_* keysym, at least when present (probably there is some fallback
mechanism). It just so happens that the standard modifier layout in most
GNU/Linux distributions associates the Meta keysym with the key labelled
"Alt".

I have for a long time used the windows key as my meta key and that I
have realised that simply by reshuffling the modifier keysyms via
xmodmap.


------------------------+-----------------------------------------------------
Christian Lynbech       | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic@hal.com (Michael A. Petonic)

Re: Key bindings proposal

[Miles Bader]

<christian.lynbech@tieto.com> writes:
> Chong> The current standard is used on all platforms: the key labelled
> Chong> "Alt" on the keyboard is handled internally by Emacs as Meta.
>
> Is this really correct?
...
> I have for a long time used the windows key as my meta key and that I
> have realised that simply by reshuffling the modifier keysyms via
> xmodmap.

I think it's impossible to make any firm statements about the issue on
modern systems, there are just too many layers stepping on each others'
toes, too many vague system/device-dependent details, and too much
"helpful" tweaking by various parties (e.g., gnome-session).

[Currently on my home system, the Alt key maps to meta in Emacs, but the
"Windows" (really super) key maps to meta in most non-Emacs apps; on my
work system (with identical software/OS versions), this inconsistency
doesn't exist.  I have no idea why...]

-Miles

-- 
Learning, n. The kind of ignorance distinguishing the studious.

Re: Key bindings proposal

[Jason Rumney]

  On 13/8/2010 11:37 PM, Chong Yidong wrote:

> The problem is that Lennart's proposed solution seems to be the wrong
> one.  If you want to rebind the Windows key to a modifier key, the
> conceptually correct way to do it should be via a separate program,
> separate from Emacs.  That is exactly how it is done on GNU/Linux (where
> conventions like Alt-TAB are commonly respected, nowadays).
>
> If there is any technical reason why this cannot be done on Windows, I
> have not yet seen anyone argue it.

Such a program might theoretically be possible, but as far as I know it 
does not exist.

Re: Key bindings proposal

[Juanma Barranquero]

On Fri, Aug 13, 2010 at 18:01, Jason Rumney <jasonr@gnu.org> wrote:

>  On 13/8/2010 11:37 PM, Chong Yidong wrote:

>> If there is any technical reason why this cannot be done on Windows, I
>> have not yet seen anyone argue it.
>
> Such a program might theoretically be possible, but as far as I know it does
> not exist.

I haven't tried it, but shouldn't AutoHotKey be theoretically able to do it?

    Juanma

Re: Key bindings proposal

[Lennart Borgman]

On Sat, Aug 14, 2010 at 12:40 AM, Juanma Barranquero <lekktu@gmail.com> wrote:
>
> I haven't tried it, but shouldn't AutoHotKey be theoretically able to do it?

I might misremember, but I think that was not possible. That was one
of the reason I added the low level keyboard hook to my patched Emacs.

Re: Key bindings proposal

[Lennart Borgman]

On Fri, Aug 13, 2010 at 5:37 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
> Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:
>
>> Hi guys, I am not sure where this discussion is headed.  Whether these
>> applications of the windows key are "useful" or not is for the users
>> to determine, is it not?
>
> The problem is that Lennart's proposed solution seems to be the wrong
> one.  If you want to rebind the Windows key to a modifier key, the
> conceptually correct way to do it should be via a separate program,
> separate from Emacs.


??  Where did you get this from?

If that was the case then the "conceptually correct way to" rebind the
Alt key would also be a separate program, or?

Beside that it would not solve the problem that Emacs on w32 does not
allow people which needs sticky keys to use it, i.e. it does not allow
access for some disabled people.


> That is exactly how it is done on GNU/Linux


That is maybe how it is organized on GNU/Linux. That is not the way it
is organized on w32.


> (where conventions like Alt-TAB are commonly respected, nowadays).


Might be interesting. Exactly what do you mean by "commonly respected"?


> If there is any technical reason why this cannot be done on Windows, I
> have not yet seen anyone argue it.


??

Re: Key bindings proposal

[Chong Yidong]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> Beside that it would not solve the problem that Emacs on w32 does not
> allow people which needs sticky keys to use it, i.e. it does not allow
> access for some disabled people.

This is an appropriate issue, and the patch to handle it, independent of
the rebinding-the-Windows-key feature, would be welcome.

Re: Key bindings proposal

[Jason Rumney]

  On 14/8/2010 12:53 AM, Chong Yidong wrote:
> Lennart Borgman<lennart.borgman@gmail.com>  writes:
>
>> Beside that it would not solve the problem that Emacs on w32 does not
>> allow people which needs sticky keys to use it, i.e. it does not allow
>> access for some disabled people.
> This is an appropriate issue, and the patch to handle it, independent of
> the rebinding-the-Windows-key feature, would be welcome.

You misunderstand the purpose of Lennart's patch. The ability to rebind 
the windows and alt keys on w32 is already there, and has been since 
about 1996.  Lennart's patch allows the user to forcibly reclaim keys 
that are being used for system wide functions, in a way that works for 
all keys (we already have a function that can reclaim some of those, but 
not Alt-Tab or some of the Windows key bindings).  Lennart's patch is 
useful for users who continue to use the default of Alt bound to Meta as 
well as users who would prefer to move meta to one or both windows keys.

Re: Key bindings proposal

[Chong Yidong]

Jason Rumney <jasonr@gnu.org> writes:

>>> Beside that it would not solve the problem that Emacs on w32 does not
>>> allow people which needs sticky keys to use it, i.e. it does not allow
>>> access for some disabled people.
>> This is an appropriate issue, and the patch to handle it, independent of
>> the rebinding-the-Windows-key feature, would be welcome.
>
> You misunderstand the purpose of Lennart's patch. The ability to
> rebind the windows and alt keys on w32 is already there, and has been
> since about 1996.  Lennart's patch allows the user to forcibly reclaim
> keys that are being used for system wide functions, in a way that
> works for all keys (we already have a function that can reclaim some
> of those, but not Alt-Tab or some of the Windows key bindings).
> Lennart's patch is useful for users who continue to use the default of
> Alt bound to Meta as well as users who would prefer to move meta to
> one or both windows keys.

On X, Alt-TAB does not go to Emacs either; the window manager grabs it.
I don't understand why it's proper for Emacs to "reclaim" the key.  If
it's not desireable for Alt-TAB to switch windows, the logical solution
seems to be to tell the window manager to stop grabbing Alt-TAB, since
it's the window manager that's at "fault".

Also, I don't understand the relation between forcibly reclaiming
operating system keys and the claim about sticky keys not behaving
properly.  Sticky keys are handled by the operating system; Emacs should
not be able to tell (nor have to care) whether the `M-x' it received
came from a sticky key.  What am I missing?

Re: Key bindings proposal

[Jason Rumney]

  On 14/8/2010 9:24 AM, Chong Yidong wrote:

> On X, Alt-TAB does not go to Emacs either; the window manager grabs it.
> I don't understand why it's proper for Emacs to "reclaim" the key.  If
> it's not desireable for Alt-TAB to switch windows, the logical solution
> seems to be to tell the window manager to stop grabbing Alt-TAB, since
> it's the window manager that's at "fault".

That may well be the solution on X, but it is not a solution on Windows, 
so we have to provide solutions within Emacs.

RE: Key bindings proposal

[Drew Adams]

> we already have a function that can reclaim some of 
> those, but not Alt-Tab

What am I missing about that?  I use (w32-register-hot-key [M-tab]) and it lets
me use ALT-TAB for M-TAB just fine.  Did you mean something different from that?

Re: Key bindings proposal

[Juanma Barranquero]

On Fri, Aug 13, 2010 at 18:04, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> Beside that it would not solve the problem that Emacs on w32 does not
> allow people which needs sticky keys to use it, i.e. it does not allow
> access for some disabled people.

You've been invited several times to provide a patch. There's no
concerted attempt to keep this feature out of Emacs, as far as I know.
Just no one has fixed it yet, except, apparently, you.

    Juanma

Re: Key bindings proposal

[Jason Rumney]

  On 14/8/2010 12:04 AM, Lennart Borgman wrote:

> Beside that it would not solve the problem that Emacs on w32 does not
> allow people which needs sticky keys to use it, i.e. it does not allow
> access for some disabled people.

Can you please  point me to the bug report where you explained this in 
detail.  I have tried searching, and cannot find anything other than a 
report that the Alt key needs to be pressed twice to open the menu - 
which turned out to be the case for any program.  As far as I can tell, 
sticky keys work perfectly fine with Emacs, but I don't have much 
experience with using them, so maybe I am missing something subtle that 
would prevent disabled people from using them.

Re: Key bindings proposal

[Lennart Borgman]

On Sat, Aug 14, 2010 at 2:30 AM, Jason Rumney <jasonr@gnu.org> wrote:
>  On 14/8/2010 12:04 AM, Lennart Borgman wrote:
>
>> Beside that it would not solve the problem that Emacs on w32 does not
>> allow people which needs sticky keys to use it, i.e. it does not allow
>> access for some disabled people.
>
> Can you please  point me to the bug report where you explained this in
> detail.  I have tried searching, and cannot find anything other than a
> report that the Alt key needs to be pressed twice to open the menu - which
> turned out to be the case for any program.  As far as I can tell, sticky
> keys work perfectly fine with Emacs, but I don't have much experience with
> using them, so maybe I am missing something subtle that would prevent
> disabled people from using them.

I will try to, but can you please tell me first where you found this
"pressed twice to open the menu"? Is this in a bug report, or?

Re: Key bindings proposal

[Jason Rumney]

  On 14/8/2010 8:07 PM, Lennart Borgman wrote:
> On Sat, Aug 14, 2010 at 2:30 AM, Jason Rumney<jasonr@gnu.org>  wrote:
>> Can you please  point me to the bug report where you explained this in
>> detail.  I have tried searching, and cannot find anything other than a
>> report that the Alt key needs to be pressed twice to open the menu - which
>> turned out to be the case for any program.  As far as I can tell, sticky
>> keys work perfectly fine with Emacs, but I don't have much experience with
>> using them, so maybe I am missing something subtle that would prevent
>> disabled people from using them.
> I will try to, but can you please tell me first where you found this
> "pressed twice to open the menu"? Is this in a bug report, or?

http://lists.gnu.org/archive/html/bug-gnu-emacs/2004-08/msg00296.html

Re: Key bindings proposal

[Juanma Barranquero]

On Mon, Aug 9, 2010 at 01:19, Lennart Borgman <lennart.borgman@gmail.com> wrote:

> - The most common use of it is to open the Start Menu. You can do that
> with Ctrl-Esc too, at least on w32.

I almost never use the Windows key to open the Start menu (strangely
enough I tend to use the mouse for that). But I use it a lot for Run
(W+r), Explorer (W+e), W+tab and the many Windows 7 W+cursor
functions.

    Juanma

Re: Key bindings proposal

[Uday S Reddy]

Juanma Barranquero writes:

> I almost never use the Windows key to open the Start menu (strangely
> enough I tend to use the mouse for that). But I use it a lot for Run
> (W+r), Explorer (W+e), W+tab and the many Windows 7 W+cursor
> functions.

That is nice.  I never expected to be learning so much about Windows
on the emacs-developers list!

However, if everybody can recall the reason we got to this point,
Lennart and I think that keyboard access to the Emacs menubar is
important.  Alt+letter is the normal mechanism on Windows to provide
such keyboard access.

One objection to making Alt+letter available in Emacs is that Alt is
normally used as the Meta-key, which is important for Emacs use.

So, those of us that find keyboard access to menubar important have to
use some other key as the Meta-key.  Windows logo key is the natural
choice.  We might have to give up the standard Windows key
functionality in doing so.  But we think that the other two needs,
viz., (a) keyboard access to menus and (b) the Emacs meta-key
functionality, take priority.

Emacs doesn't have to many any decisions for us.  It is just being
asked to provide two options

  w32-lwindow-as-meta, w32-rwindow-as-meta

which can be used to treat Windows keys as meta-keys.

It that can be agreed, that would end this part of the discussion.
(Phew!) 

Cheers,
Uday

Re: Key bindings proposal

[Uday S Reddy]

Chong Yidong writes:

> > I agree.  After having thought about for a day, I realize that it is a
> > perfectly logical thing to map Windows keys to Meta.  It is wasted
> > keyboard real estate otherwise.
> 
> No, this is too idiosyncratic to make it the default.

I don't think I ever said that the Windows keys should be made
meta-keys by "default".  I am only suggesting it as an option.

Whether it is idiosyncratic, I don't know.  As far as I know the only
function of the Windows keys on Win32 is to invoke the start menu,
which can already be done using C-Esc.  

I myself never use the Windows keys for anything and find them
annoying because they are located at a strategic place on the
keyboard, next to the Alt-keys.  I end up pressing them often while
trying to press an Alt-key.  I have thought of disabling them many
times, but I haven't invested the time to figure out how.

If Lennart knows how to make them turn into Meta-keys, it seems like
it is worthwhile doing it.

> Doesn't the Windows world have some equivalent of `xmodmap'?  That's the
> conceptually correct way to handle this.

I will look into that.

It seems possible to map the Windows key to an Alt-key using key
remapping (which can be done via Windows registry).  But that might
not achieve much, because Emacs will end up interpreting both sets of
Alt-keys as Meta-keys.  There is still work to do at the Emacs end.

Cheers,
Uday

Re: Key bindings proposal

[Uday Reddy]

On 8/8/2010 11:22 PM, Chong Yidong wrote:

>> I agree.  After having thought about for a day, I realize that it is a
>> perfectly logical thing to map Windows keys to Meta.  It is wasted
>> keyboard real estate otherwise.
>
> No, this is too idiosyncratic to make it the default.

There seems to be some amount of confusion here.  Wikipedia

    http://en.wikipedia.org/wiki/Meta_key

says that the Meta key is emulated on modern keyboards by either the Alt or 
Windows keys.  The statement was written by "Cate" 
(http://en.wikipedia.org/wiki/User:Cate) and has been there since 2005.

The Emacs manual says, "We refer to <Alt> as <Meta> for historical reasons" 
(Section 2.)  Is Emacs imagining a strict connection between <Alt> and <Meta> 
which doesn't actually exist?

Cheers,
Uday

Re: Key bindings proposal

[Uday S Reddy]

Chong Yidong writes:

> Even for non-default usage, putting Emacs in charge of the Windows key
> seems unacceptable.  This is the domain of the operating system.
> 
> Doesn't the Windows world have some equivalent of `xmodmap'?  That's the
> conceptually correct way to handle this.

I have been able to successfully use the Sharpkeys program 

  http://www.randyrants.com/sharpkeys/

to remap

  Left windows (E0_5B) to Left Alt (00_38)
  Right windows (E0_5C) to Right Alt (E0_38)

Works like a peach!

Is there something else I can do to remap the windows keys to meta
keys instead?

Cheers,
Uday

RE: Key bindings proposal

[Stephen J. Turnbull]

Uday S Reddy writes:

 > When new users come to using a tool like Emacs, their first mode of
 > interaction is via the menubar, used with the mouse.  The second might
 > be to use keyboard accelerators.

Seems unlikely to me.  If keyboard accelerators were so important,
those users would all at least try XEmacs, which has integrated
keyboard accelerators for a decade or so.  In fact, a *lot* of effort
was put into making XEmacs look and feel more familiar to the "new new
user crowd" around the turn of the century: menu accelerators,
sticky modifiers, tab controls, progress gauges, shifted motion
extends selection, and on Windows, native dialogs for file selection,
antialiased fonts, copy/cut/paste integration with the Windows
clipboard, and a proper printer device.[1]

But I've never seen a huge flood of new XEmacs users, and *no* new
contributors, from that crowd.  The new users are mostly the kind of
folk who read software manuals for fun (or to pass the time when
they're sitting where the sun don't shine).  And the new contributors
all read the manuals.

 > And, Emacs has to fit in.

Why?

 > If people like Xah Lee or Lennart have to fork Emacs in order to
 > make it suitable to groups of users,

That's not why they "have to" fork Emacs.  They have to fork for other
reasons, then as long as they're forked anyway, they redo the UI in
their forks.

BTW, you forgot David Reitter, who must fork because Aquamacs is
dedicated to implementing features that make his proprietary platform
(the Mac) more attractive for users than free platforms -- and such
features are not allowed as a matter of Emacs policy.  Nevertheless,
he has over 50 credits in the Emacs ChangeLogs.  Lennart has half as
many.  Xah Lee has *none*.  Hmmm....


Footnotes: 
[1]  I *think* these are all in 21.4, which was released in April
2001.  But it's been a while since I used 21.4 regularly.

RE: Key bindings proposal

[Uday S Reddy]

Stephen J. Turnbull writes:

> Seems unlikely to me.  If keyboard accelerators were so important,
> those users would all at least try XEmacs, which has integrated
> keyboard accelerators for a decade or so.  In fact, a *lot* of effort
> was put into making XEmacs look and feel more familiar to the "new new
> user crowd" around the turn of the century: menu accelerators,
> sticky modifiers, tab controls, progress gauges, shifted motion
> extends selection, and on Windows, native dialogs for file selection,
> antialiased fonts, copy/cut/paste integration with the Windows
> clipboard, and a proper printer device.[1]

And, believe me that all of these features were indeed quite useful to
the new users.  I recall now that it was XEmacs that we had set up in
the labs and it was this that I had observed the students using in
ways quite different from me.  I had tried to get a few of the smarter
ones to use the key bindings, and they tried things like C-o and C-s
and gave up.

If you already had keyboard accelerators of menus in 2001, well, thank
you very much for it!  But, it still requires extra RET key strokes to
confirm selections.  That is what I characterized as inefficient in my
previous post, i.e., it is not good enough to serve as a substitute
for key bindings.

Coming back to the students, the vast majority of them switched to
IDEs by the time they reached their final year.  So, while we had done
our bit by introducing them to Emacs, Emacs wasn't able to retain them
due to its limitations.  In this sense, the previous thread was right
in focusing on the IDE support.

> But I've never seen a huge flood of new XEmacs users, and *no* new
> contributors, from that crowd.  The new users are mostly the kind of
> folk who read software manuals for fun (or to pass the time when
> they're sitting where the sun don't shine).  And the new contributors
> all read the manuals.

You are obviously right about that.  However, I don't agree with the
conclusion.  The user base is still needed to motivate contributors to
find it worthwhile to come forward.  Mozilla and Eclipse have armies
of contributors, not because they have great manuals but because they
have large user bases.

>  > And, Emacs has to fit in.
> 
> Why?

Because, otherwise, you raise the barrier to entry so high that only a
small minority of potential users will be able to get through.

Cheers,
Uday

PS: Sorry that I haven't gotten around to replying to your other
posts.  But I am thinking...

Re: Key bindings proposal

[joakim]

Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:

> Stephen J. Turnbull writes:
>
>> Seems unlikely to me.  If keyboard accelerators were so important,
>> those users would all at least try XEmacs, which has integrated
>> keyboard accelerators for a decade or so.  In fact, a *lot* of effort
>> was put into making XEmacs look and feel more familiar to the "new new
>> user crowd" around the turn of the century: menu accelerators,
>> sticky modifiers, tab controls, progress gauges, shifted motion
>> extends selection, and on Windows, native dialogs for file selection,
>> antialiased fonts, copy/cut/paste integration with the Windows
>> clipboard, and a proper printer device.[1]
>
> And, believe me that all of these features were indeed quite useful to
> the new users.  I recall now that it was XEmacs that we had set up in
> the labs and it was this that I had observed the students using in
> ways quite different from me.  I had tried to get a few of the smarter
> ones to use the key bindings, and they tried things like C-o and C-s
> and gave up.
>
> If you already had keyboard accelerators of menus in 2001, well, thank
> you very much for it!  But, it still requires extra RET key strokes to
> confirm selections.  That is what I characterized as inefficient in my
> previous post, i.e., it is not good enough to serve as a substitute
> for key bindings.

I dont understand this. I normaly have menus disabled, but I enabled
them now to see. In the File menu I have an entry like:

  "Visit new file... C-x C-f"

Isn't that a "keyboard accelerator"? I note that Firefox does the same
thing for this menu entry:

 "bookmarks/organize bookmarks ctrl+shif+o"

Or do you mean there is no obvious way to traverse the menus from the
keyboard? Could we then promote the use of F10 already in the menu bar
text? (f10 is bound to menu-bar-open here)

perhaps like the 1st line of the help menu or something:

  "Use F10 to start traversing menus with kbd"

>
> Coming back to the students, the vast majority of them switched to
> IDEs by the time they reached their final year.  So, while we had done
> our bit by introducing them to Emacs, Emacs wasn't able to retain them
> due to its limitations.  In this sense, the previous thread was right
> in focusing on the IDE support.
>
>> But I've never seen a huge flood of new XEmacs users, and *no* new
>> contributors, from that crowd.  The new users are mostly the kind of
>> folk who read software manuals for fun (or to pass the time when
>> they're sitting where the sun don't shine).  And the new contributors
>> all read the manuals.
>
> You are obviously right about that.  However, I don't agree with the
> conclusion.  The user base is still needed to motivate contributors to
> find it worthwhile to come forward.  Mozilla and Eclipse have armies
> of contributors, not because they have great manuals but because they
> have large user bases.
>
>>  > And, Emacs has to fit in.
>> 
>> Why?
>
> Because, otherwise, you raise the barrier to entry so high that only a
> small minority of potential users will be able to get through.
>
> Cheers,
> Uday
>
> PS: Sorry that I haven't gotten around to replying to your other
> posts.  But I am thinking...
>
-- 
Joakim Verona

Re: Key bindings proposal

[Lennart Borgman]

On Wed, Aug 4, 2010 at 12:20 PM,  <joakim@verona.se> wrote:
>
> I dont understand this. I normaly have menus disabled, but I enabled
> them now to see. In the File menu I have an entry like:
>
>  "Visit new file... C-x C-f"
>
> Isn't that a "keyboard accelerator"?

Yes, but it is not menu accelerators. Those are underlined chars in
the menus. (At least on w32 all applications I know of have them,
except Emacs.)

> Or do you mean there is no obvious way to traverse the menus from the
> keyboard? Could we then promote the use of F10 already in the menu bar
> text? (f10 is bound to menu-bar-open here)
>
> perhaps like the 1st line of the help menu or something:
>
>  "Use F10 to start traversing menus with kbd"

That is not the standard way to access menus (at least not on w32).
You normally use the Alt key to access them. (Here too it is important
to notice that with all applications I know of on w32 you can access
menus that way. Except Emacs.)

Maybe it is still good to tell about f10 since most non-Emacs users
are not aware of that.

Re: Key bindings proposal

[joakim]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Wed, Aug 4, 2010 at 12:20 PM,  <joakim@verona.se> wrote:
>>
>> I dont understand this. I normaly have menus disabled, but I enabled
>> them now to see. In the File menu I have an entry like:
>>
>>  "Visit new file... C-x C-f"
>>
>> Isn't that a "keyboard accelerator"?
>
> Yes, but it is not menu accelerators. Those are underlined chars in
> the menus. (At least on w32 all applications I know of have them,
> except Emacs.)

But did you snip the part about how firefox does it here?

Firefox does the same thing as emacs, it only uses "menu accelerators"
when it doesnt provide a specific keybinding.

see the "organize bookmarks" example.

Anyway, I'm not expressing an opinion on the merits of the various menu
systems as I never use them. I just tried to add a data point.

(As a side-note I always want to try to emacsify a program rather than
programify emacs, so I do understand the urge to arrive at a consistent
overall environment)


>> Or do you mean there is no obvious way to traverse the menus from the
>> keyboard? Could we then promote the use of F10 already in the menu bar
>> text? (f10 is bound to menu-bar-open here)
>>
>> perhaps like the 1st line of the help menu or something:
>>
>>  "Use F10 to start traversing menus with kbd"
>
> That is not the standard way to access menus (at least not on w32).
> You normally use the Alt key to access them. (Here too it is important
> to notice that with all applications I know of on w32 you can access
> menus that way. Except Emacs.)
> Maybe it is still good to tell about f10 since most non-Emacs users
> are not aware of that.

I wasnt either. I sort of just stumbled about the keyboard to see if
something activated menu traversal :)

Anyway, what would you do with emacs normal use of alt then?

Should alt be an emacs event in itself? Maybe this is possible already?

As another related side-note I would like to experiment with modal keybindings
in Emacs, to implement something like ctrl-lock functionality. That
would I suppose be similar to your use-case for the alt key.

-- 
Joakim Verona

Re: Key bindings proposal

[Lennart Borgman]

On Wed, Aug 4, 2010 at 1:11 PM,  <joakim@verona.se> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> On Wed, Aug 4, 2010 at 12:20 PM,  <joakim@verona.se> wrote:
>>>
>>> I dont understand this. I normaly have menus disabled, but I enabled
>>> them now to see. In the File menu I have an entry like:
>>>
>>>  "Visit new file... C-x C-f"
>>>
>>> Isn't that a "keyboard accelerator"?
>>
>> Yes, but it is not menu accelerators. Those are underlined chars in
>> the menus. (At least on w32 all applications I know of have them,
>> except Emacs.)
>
> But did you snip the part about how firefox does it here?
>
> Firefox does the same thing as emacs, it only uses "menu accelerators"
> when it doesnt provide a specific keybinding.

No. At least on w32 it normally shows both keyboard and menu
accelerators in the menus. See the "View" submenu for example.

> see the "organize bookmarks" example.

That is a bit special since it is a list of your bookmarks.

(Also a lot of add-ons in Firefox does not add menu accelerators the
way the are supposed. Some add them when they should not and others
omit them when they should add them.)

> (As a side-note I always want to try to emacsify a program rather than
> programify emacs, so I do understand the urge to arrive at a consistent
> overall environment)

Is not that quite a lot more work ... ;-)

>>> Or do you mean there is no obvious way to traverse the menus from the
>>> keyboard? Could we then promote the use of F10 already in the menu bar
>>> text? (f10 is bound to menu-bar-open here)
>>>
>>> perhaps like the 1st line of the help menu or something:
>>>
>>>  "Use F10 to start traversing menus with kbd"
>>
>> That is not the standard way to access menus (at least not on w32).
>> You normally use the Alt key to access them. (Here too it is important
>> to notice that with all applications I know of on w32 you can access
>> menus that way. Except Emacs.)
>> Maybe it is still good to tell about f10 since most non-Emacs users
>> are not aware of that.
>
> I wasnt either. I sort of just stumbled about the keyboard to see if
> something activated menu traversal :)
>
> Anyway, what would you do with emacs normal use of alt then?

In my patched version of Emacs on w32 you can use the left and/or
right window keys as alt instead.

Some people here has said that this is just as bad since that
overrides the normal use of those keys. I do not agree for two
reasons:

- microsoft has made it possible to override those keys totally, while
you can not totally override the alt key.
- using the alt key is far more common than using the windows key.

> Should alt be an emacs event in itself? Maybe this is possible already?

See above.

> As another related side-note I would like to experiment with modal keybindings
> in Emacs, to implement something like ctrl-lock functionality. That
> would I suppose be similar to your use-case for the alt key.

Except that the window manager does not let you handle all key
combinations with the Alt key. (You can not override for example
Alt-Tab on w32. And that is a good thing in my opinion.)

Re: Key bindings proposal

[joakim]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Wed, Aug 4, 2010 at 1:11 PM,  <joakim@verona.se> wrote:
>> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>
>>> On Wed, Aug 4, 2010 at 12:20 PM,  <joakim@verona.se> wrote:
>>>>
>>>> I dont understand this. I normaly have menus disabled, but I enabled
>>>> them now to see. In the File menu I have an entry like:
>>>>
>>>>  "Visit new file... C-x C-f"
>>>>
>>>> Isn't that a "keyboard accelerator"?
>>>
>>> Yes, but it is not menu accelerators. Those are underlined chars in
>>> the menus. (At least on w32 all applications I know of have them,
>>> except Emacs.)
>>
>> But did you snip the part about how firefox does it here?
>>
>> Firefox does the same thing as emacs, it only uses "menu accelerators"
>> when it doesnt provide a specific keybinding.
>
> No. At least on w32 it normally shows both keyboard and menu
> accelerators in the menus. See the "View" submenu for example.
>
>> see the "organize bookmarks" example.
>
> That is a bit special since it is a list of your bookmarks.
>
> (Also a lot of add-ons in Firefox does not add menu accelerators the
> way the are supposed. Some add them when they should not and others
> omit them when they should add them.)
>
>> (As a side-note I always want to try to emacsify a program rather than
>> programify emacs, so I do understand the urge to arrive at a consistent
>> overall environment)
>
> Is not that quite a lot more work ... ;-)
>
>>>> Or do you mean there is no obvious way to traverse the menus from the
>>>> keyboard? Could we then promote the use of F10 already in the menu bar
>>>> text? (f10 is bound to menu-bar-open here)
>>>>
>>>> perhaps like the 1st line of the help menu or something:
>>>>
>>>>  "Use F10 to start traversing menus with kbd"
>>>
>>> That is not the standard way to access menus (at least not on w32).
>>> You normally use the Alt key to access them. (Here too it is important
>>> to notice that with all applications I know of on w32 you can access
>>> menus that way. Except Emacs.)
>>> Maybe it is still good to tell about f10 since most non-Emacs users
>>> are not aware of that.
>>
>> I wasnt either. I sort of just stumbled about the keyboard to see if
>> something activated menu traversal :)
>>
>> Anyway, what would you do with emacs normal use of alt then?
>
> In my patched version of Emacs on w32 you can use the left and/or
> right window keys as alt instead.
>
> Some people here has said that this is just as bad since that
> overrides the normal use of those keys. I do not agree for two
> reasons:
>
> - microsoft has made it possible to override those keys totally, while
> you can not totally override the alt key.
> - using the alt key is far more common than using the windows key.
>
>> Should alt be an emacs event in itself? Maybe this is possible already?
>
> See above.
>
>> As another related side-note I would like to experiment with modal keybindings
>> in Emacs, to implement something like ctrl-lock functionality. That
>> would I suppose be similar to your use-case for the alt key.
>
> Except that the window manager does not let you handle all key
> combinations with the Alt key. (You can not override for example
> Alt-Tab on w32. And that is a good thing in my opinion.)

My particular interest is not in making Emacs fit a particular WM such
as W32 or Metacity or Compiz. My interest is making Emacs be able to do
things a WM does, but more, for example "m-x
inkscape-set-object-fill-color". Anyway, that is stuff for another
thread, so I bow out of this thread now.

-- 
Joakim Verona

Re: Key bindings proposal

[Jason Rumney]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> In my patched version of Emacs on w32 you can use the left and/or
> right window keys as alt instead.
>
> Some people here has said that this is just as bad since that
> overrides the normal use of those keys. I do not agree for two
> reasons:
>
> - microsoft has made it possible to override those keys totally, while
> you can not totally override the alt key.
> - using the alt key is far more common than using the windows key.

Your opinion differs from many people on both accounts.

To override the Windows keys, you have had to use a low level keyboard
hook to catch the key before the normal Windows input event handling
takes place.  This is required to catch about half a dozen bindings that
Windows does not let you override in the officially supported way (which
is used by w32-register-hot-key).

OTOH, the only Alt keybinding that requires such hackery is Alt-TAB.

Re: Key bindings proposal

[Lennart Borgman]

On Wed, Aug 4, 2010 at 3:24 PM, Jason Rumney <jasonr@gnu.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> In my patched version of Emacs on w32 you can use the left and/or
>> right window keys as alt instead.
>>
>> Some people here has said that this is just as bad since that
>> overrides the normal use of those keys. I do not agree for two
>> reasons:
>>
>> - microsoft has made it possible to override those keys totally, while
>> you can not totally override the alt key.
>> - using the alt key is far more common than using the windows key.
>
> Your opinion differs from many people on both accounts.

I think ms agree with me on both...

> To override the Windows keys, you have had to use a low level keyboard
> hook to catch the key before the normal Windows input event handling
> takes place.  This is required to catch about half a dozen bindings that
> Windows does not let you override in the officially supported way (which
> is used by w32-register-hot-key).

The low level keyboard hook is the only supported way as far as I
know. There were other ways before, but I think ms dropped them since
they were not secure. (Is not hot keys for a different situation?)

> OTOH, the only Alt keybinding that requires such hackery is Alt-TAB.

No. Alt-TAB can not be overrided by low level keyboard hooks on w32.
That is stated in ms documentation. (I have sent links to this long
ago.)

Re: Key bindings proposal

[Jan Djärv]

2010-08-04 12:52, Lennart Borgman skrev:
> On Wed, Aug 4, 2010 at 12:20 PM,<joakim@verona.se>  wrote:

>
>> Or do you mean there is no obvious way to traverse the menus from the
>> keyboard? Could we then promote the use of F10 already in the menu bar
>> text? (f10 is bound to menu-bar-open here)
>>
>> perhaps like the 1st line of the help menu or something:
>>
>>   "Use F10 to start traversing menus with kbd"
>
> That is not the standard way to access menus (at least not on w32).

F10 on W32 does start keyboard traversal on menus on Microsoft applications 
and others, and it is listed here: http://support.microsoft.com/kb/301583. 
How more standard does it get?  The difference between for example Gnome is 
that Gnome opens the first menu, but W32 does not.

>
> Maybe it is still good to tell about f10 since most non-Emacs users
> are not aware of that.

If they used Gnome or W32 they should be.  Don't know about KDE though.

	Jan D.

Re: Key bindings proposal

[Lennart Borgman]

On Wed, Aug 4, 2010 at 1:19 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> 2010-08-04 12:52, Lennart Borgman skrev:
>>
>> On Wed, Aug 4, 2010 at 12:20 PM,<joakim@verona.se>  wrote:
>
>>
>>> Or do you mean there is no obvious way to traverse the menus from the
>>> keyboard? Could we then promote the use of F10 already in the menu bar
>>> text? (f10 is bound to menu-bar-open here)
>>>
>>> perhaps like the 1st line of the help menu or something:
>>>
>>>  "Use F10 to start traversing menus with kbd"
>>
>> That is not the standard way to access menus (at least not on w32).
>
> F10 on W32 does start keyboard traversal on menus on Microsoft applications
> and others, and it is listed here: http://support.microsoft.com/kb/301583.
> How more standard does it get?  The difference between for example Gnome is
> that Gnome opens the first menu, but W32 does not.

OK, I should of course have written "normal way". Most users on w32
never ever use f10 to access the menus. They use the Alt key.

Re: Key bindings proposal

[Jason Rumney]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> OK, I should of course have written "normal way". Most users on w32
> never ever use f10 to access the menus. They use the Alt key.

Have you polled them?

Most users on w32 that I've met only ever use the mouse. But that is
just anecdotal evidence, and I wouldn't pretend to guess what proportion
of those who use the keyboard use F10 vs Alt vs the Ctrl shortcuts.

Re: Key bindings proposal

[Lennart Borgman]

On Wed, Aug 4, 2010 at 3:27 PM, Jason Rumney <jasonr@gnu.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> OK, I should of course have written "normal way". Most users on w32
>> never ever use f10 to access the menus. They use the Alt key.
>
> Have you polled them?

No, of course not.

> Most users on w32 that I've met only ever use the mouse. But that is
> just anecdotal evidence, and I wouldn't pretend to guess what proportion
> of those who use the keyboard use F10 vs Alt vs the Ctrl shortcuts.

Yes, but keyboard users might prefer Alt since that is easier to reach than f10.

Re: Key bindings proposal

[Uday S Reddy]

joakim@verona.se writes:

> I dont understand this. I normaly have menus disabled, but I enabled
> them now to see. In the File menu I have an entry like:
> 
>   "Visit new file... C-x C-f"
> 
> Isn't that a "keyboard accelerator"? 

No, that is what I have been calling a "key binding".

The "keyboard acceleration" (Stephen's term) is what you get by
menu-bar-open.  (Sorry, I didn't realize that it was bound to <F10>.
I had disabled <F10> for some reason.)

So, "<F10> f v" gets you to find file, and you don't need to remember
C-x C-f.  There, "f" is for "File" and "v" is for "Visit...".

The problem I am pointing out is that using the first letter of the
menu titles/entries is kind of a "poor man's keyboard acceleration".
It breaks whenever there are other titles and entries beginning with
the same letter.  Then the user has to repeat the key stroke to get to
the right entry and hit RET to confirm a selection.

Lennart's menu accelerators, which are standard on Windows
applications, provide designated key strokes as the access points for
each menu title and entry.  In the Firefox file menu, for instance,
you will find:

N underlined in       New Window  C+N
T underlined in       New Tab     C+T

The developers chose different keys as the access points for these two
menu items so that there is no conflict between.  If Gnu Emacs were to
do the same menu, there would be conflict.

I made a mistake in my previous response to Stephen, it seems.  XEmacs
does provide menu accelerators and it probably did it since 2001.  So,
the infrastructure has been there.  However, the menus don't seem to
have been designed all that carefully to avoid conflicts.  (I got
fooled because the examples that I tried all had conflicts.)

When menus are designed carefully to avoid conflict, keyboard
accelerators become competitive with key bindings.  Then one doesn't
need to remember key bindings any more.  That can make a BIG
difference.

Cheers,
Uday

Re: Key bindings proposal

[Andreas Schwab]

Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:

> When menus are designed carefully to avoid conflict, keyboard
> accelerators become competitive with key bindings.  Then one doesn't
> need to remember key bindings any more.

So you have to remember menu entries.  Big deal.  Key bindings don't
change with the text in the menu entries, and are customizable.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Key bindings proposal

[Uday S Reddy]

Andreas Schwab writes:

> So you have to remember menu entries.  Big deal.  Key bindings don't
> change with the text in the menu entries, and are customizable.

That is exactly the kind of resistance that people are complaining
about.  It may not be a big deal for you, but it might be for others.  

Further, I don't think the argument has validity.  You don't have to
"remember" the menu entries.  You can see them!

At least in Emacs, menubars are just as customizable as key bindings
are.  Or, did I get it wrong?

Cheers,
Uday

Re: Key bindings proposal

[Andreas Schwab]

Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:

> Further, I don't think the argument has validity.  You don't have to
> "remember" the menu entries.  You can see them!

You have to remember where to search, and do search for them.  And if
you change the language you are screwed.  What a stupid concept.

> At least in Emacs, menubars are just as customizable as key bindings
> are.  Or, did I get it wrong?

In Emacs you have key bindings and M-x, no need for menus.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Key bindings proposal

[Lennart Borgman]

On Wed, Aug 4, 2010 at 2:03 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:
>
>> Further, I don't think the argument has validity.  You don't have to
>> "remember" the menu entries.  You can see them!
>
> You have to remember where to search, and do search for them.  And if
> you change the language you are screwed.  What a stupid concept.

When someone says "stupid" I always get interested. What have that
person got wrong?

There is always a reason. Look for that. A lot of users thinks the
current behavior in other applications is good and wants it.

Re: Key bindings proposal

[Andreas Schwab]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> There is always a reason. Look for that. A lot of users thinks the
> current behavior in other applications is good and wants it.

They only know what they are offered.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Key bindings proposal

[Lennart Borgman]

On Wed, Aug 4, 2010 at 2:13 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> There is always a reason. Look for that. A lot of users thinks the
>> current behavior in other applications is good and wants it.
>
> They only know what they are offered.

That does not mean that they do not have a good reason to like it.

And isn't there research behind this?

Re: Key bindings proposal

[Uday S Reddy]

Andreas Schwab writes:

> You have to remember where to search, and do search for them.  And if
> you change the language you are screwed.  What a stupid concept.

People seem good at doing that kind of search.

Yes, I agree that menus have to be designed for each language.  That
is a drag.  I wonder why people use different languages '-).

> In Emacs you have key bindings and M-x, no need for menus.

Yes, that is one "language".  Nobody denies that!

Cheers,
Uday

Re: Key bindings proposal

[Tom]

Uday S Reddy <u.s.reddy <at> cs.bham.ac.uk> writes:
> 
> > In Emacs you have key bindings and M-x, no need for menus.
> 
> Yes, that is one "language".  Nobody denies that!
> 

Which brings the question: is Emacs only targeted to English-speaking 
users? Internationalization is a natural feature of modern software.

Re: Key bindings proposal

[Stuart Hacking]

On 4 Aug 2010, at 17:19, Tom wrote:

> Uday S Reddy <u.s.reddy <at> cs.bham.ac.uk> writes:
>> 
>>> In Emacs you have key bindings and M-x, no need for menus.
>> 
>> Yes, that is one "language".  Nobody denies that!
>> 
> 
> Which brings the question: is Emacs only targeted to English-speaking 
> users? Internationalization is a natural feature of modern software.
> 
> 
> 


Just a few thoughts:

Won't we encounter problems due to much of Emacs' UI being closely tied to the underlying source code?

Even in software that is localised, the source code is usually in English. Emacs goes a step further by 
having much documentation written inline with the code.

A lot of the emacs documentation comes from source code doc-strings, command names, arguments. As I see it, we 
could at best hope for partial localisation. It would be a large effort 
 to achieve 100%.

Tasks (and issues):

* Translate Info Files

	There's a lot of this type of documentation for the manuals, but translating it wouldn't impact 
functionality.

* Translate function documentation

	Documentation strings are inline with the actual code. Thus, translation would 
mean either duplicating all the libraries (no), separating the documentation from the 
code (no), or keeping the English documentation with the code, but translating it and implementing
a build process that will do the compile time substitution?

* Translate the function names

	Probably not even necessary.

* Translate the menu items and other UI strings

	Are any of these generated from function names? For inline strings, perhaps they could be 
extracted - but would this make it harder to read the code? Perhaps the same suggestion as the
inline documentation applies? (leaving the english, but implementing a string substitution process)

I think there would be not insignificant changes to the build process and possibly some re-architecturing where 
string management is concerned. Is there a big demand for localisation?

--Stuart

Re: Key bindings proposal

[Stephen J. Turnbull]

Stuart Hacking writes:
 > On 4 Aug 2010, at 17:19, Tom wrote:

 > > Which brings the question: is Emacs only targeted to English-speaking 
 > > users? Internationalization is a natural feature of modern software.

No, it's not "natural".  Look at Wikipedia, which grows "naturally" --
and with separation of language at the top level.  Localization, ie,
compartmentalization, is easy and natural.  But the infrastructure
needs to be internationalized, which is unnatural and a lot of work.

Fortunately most of that work can be done incrementally.

 > Just a few thoughts:
 > 
 > Won't we encounter problems due to much of Emacs' UI being closely
 > tied to the underlying source code?

Yes.  But UI internationalization is a solved problem.  There are some
Emacs-specific problems such as "Russian Ctrl-X" (on a Cyrillic
keyboard, the user doesn't think of the key as "X" -- is C-x defined
by the row/column position on the keyboard, or by the label on the
key?)  But these are basically at the level of inconvenience (even to
the Russian users, according to what I've read).

The real problems are in getting LISP to be internationalized, ie,
integrating string-handling with gettext.  Should concat look up
strings?  Should the LISP interpreter do it when passing args?  etc.
That is a fairly delicate design problem.

 > Even in software that is localised, the source code is usually in
 > English. Emacs goes a step further by having much documentation
 > written inline with the code.
 > 
 > A lot of the emacs documentation comes from source code
 > doc-strings, command names, arguments. As I see it, we could at
 > best hope for partial localisation. It would be a large effort to
 > achieve 100%.

Docstrings are a solved problem, by gettext.  Even translating them is
a solved problem, there are several projects which will help, and it
can be done incrementally.

Ditto Info files and the like.

 > I think there would be not insignificant changes to the build
 > process and possibly some re-architecturing where string management
 > is concerned. Is there a big demand for localisation?

I don't think either the build process or string storage is a big
issue.  There may be technical issues in the latter due to string
compaction in garbage collection, but they're probably pretty
straighforward.

Yes, there is a big demand for localization.  Most Japanese and
Chinese programmers speak English very poorly, and read it only with a
fair amount of effort.  Even a surprisingly large number of Indians
have some trouble with English.  If Uday Reddy is right that many
users means many recruits, well, there are probably 50 million
potential users Emacs could reach with better localization.

Re: Key bindings proposal

[Stuart Hacking]

On 5 August 2010 03:39, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> Yes.  But UI internationalization is a solved problem.
>

> Docstrings are a solved problem, by gettext.  Even translating them is
> a solved problem, there are several projects which will help, and it
> can be done incrementally.
>
> Ditto Info files and the like.
>

I wasn't aware of this, thanks for the reading suggestions. :)

> Yes, there is a big demand for localization.  Most Japanese and
> Chinese programmers speak English very poorly, and read it only with a
> fair amount of effort.  Even a surprisingly large number of Indians
> have some trouble with English.  If Uday Reddy is right that many
> users means many recruits, well, there are probably 50 million
> potential users Emacs could reach with better localization.
>

I'd say that makes it more than worthwhile.

Re: Key bindings proposal

[Andreas Schwab]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> The real problems are in getting LISP to be internationalized, ie,
> integrating string-handling with gettext.  Should concat look up
> strings?  Should the LISP interpreter do it when passing args?  etc.

Of course not.  Strings are to be translated when they are presented to
the user, which is a high level concept.  Translatable strings must be
explicitly marked.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Key bindings proposal

[Stephen J. Turnbull]

Andreas Schwab writes:
 > "Stephen J. Turnbull" <stephen@xemacs.org> writes:

 > > The real problems are in getting LISP to be internationalized, ie,
 > > integrating string-handling with gettext.  Should concat look up
 > > strings?  Should the LISP interpreter do it when passing args?  etc.
 > 
 > Of course not.  Strings are to be translated when they are presented to
 > the user, which is a high level concept.  Translatable strings must be
 > explicitly marked.

Marked, yes.  That's the way gettext works from the programmer's
standpoint.  In C, that translates to a function call.  Cheap.
Function calls are not so cheap in LISP, though, nor is allocating
strings.  And while you perhaps might be happy with code like

(defun parental-warning (dependents)
  (format (gettext "It's %s %s; do you know where your %s are?")
          (format-time-string "%I")  ; URK URK URK! is this right?
                                     ; not everybody uses Arabic numerals!
          (gettext (format-time-string "%p")) ; or is this f-t-s's job?
          (gettext dependents)))

I sure hope Emacs can do better.  Eg, it might make sense to have
either the interpreter or certain subrs call gettext on marked strings
(where the marking is done by the LISP reader on literals).  Or it
might make sense to have *un*marked strings automatically translated
in those contexts.

And "high-level"?  Maybe, maybe not.  In some important cases it may
make sense to assemble a large variable string from many pieces.  It
is not at all obvious to me that passing all strings to top level,
where they are translated then concatenated, is always possible, let
alone always a sane way to organize a program.

P.S. (defsubst _ (s) (gettext s)) doesn't cut it, except as a last
resort.

Re: Key bindings proposal

[Andreas Schwab]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> In some important cases it may make sense to assemble a large variable
> string from many pieces.

Not if you want to be i18n friendly.

> It is not at all obvious to me that passing all strings to top level,
> where they are translated then concatenated, is always possible

Almost never (unless the parts are independent, full sentences).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Key bindings proposal

[Stephen J. Turnbull]

Andreas Schwab writes:
 > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
 > 
 > > In some important cases it may make sense to assemble a large variable
 > > string from many pieces.
 > 
 > Not if you want to be i18n friendly.

Friends are as friends do.  "I18N" is a computer program, it should
dance to *my* tune, not vice versa.

Re: Key bindings proposal

[Andreas Schwab]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Friends are as friends do.  "I18N" is a computer program, it should
> dance to *my* tune, not vice versa.

i18n is about natural languages, not programming languages.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Key bindings proposal

[Chong Yidong]

Tom <levelhalom@gmail.com> writes:

> Which brings the question: is Emacs only targeted to English-speaking
> users?  Internationalization is a natural feature of modern software.

It's impractical to internationalize the docstrings; there's too much.
Internationalizing the menu-bar is doable.

We could have a set of packages on elpa.gnu.org, each consisting of an
elisp file that changes the strings in menu-bar-*-menu to a different
language.

Contributions welcome.

Re: Key bindings proposal

[Stephen J. Turnbull]

Chong Yidong writes:

 > It's impractical to internationalize the docstrings; there's too much.

No no no!  Internationalizing the documentation is enthusiasm
generating; it brings in new contributors who feel they're not able to
do anything else.

Label the incomplete state "Emacs's Cathedral of the Sagrada Familia"
and it might even get registered as a world treasure. :-)

Re: Key bindings proposal

[Uday S Reddy]

On 8/5/2010 4:14 AM, Stephen J. Turnbull wrote:

> No no no!  Internationalizing the documentation is enthusiasm
> generating; it brings in new contributors who feel they're not able to
> do anything else.

Good idea.  But, how will the translations be kept uptodate?

Cheers,
Uday

Re: Key bindings proposal

[David Kastrup]

Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:

> On 8/5/2010 4:14 AM, Stephen J. Turnbull wrote:
>
>> No no no!  Internationalizing the documentation is enthusiasm
>> generating; it brings in new contributors who feel they're not able to
>> do anything else.
>
> Good idea.  But, how will the translations be kept uptodate?

Prefixing them with a comment indicating the corresponding commit/line
pair of the source.  An automated process picks up all translation that
have gotten out of date, sees whether it suffices to update the comment
(since the line has not changed), and commits the string to the
translation task list otherwise.

-- 
David Kastrup

Re: Key bindings proposal

[Stephen J. Turnbull]

Uday S Reddy writes:
 > On 8/5/2010 4:14 AM, Stephen J. Turnbull wrote:
 > 
 > > No no no!  Internationalizing the documentation is enthusiasm
 > > generating; it brings in new contributors who feel they're not able to
 > > do anything else.
 > 
 > Good idea.  But, how will the translations be kept uptodate?

That's the whole point.  On the technical side, there are tools for
identifying changes in the translatables.

On the manpower side, just for the ones I'm familiar with, there are
whole organizations of translators at Debian and Ubuntu who volunteer
to do these things, and probably at GNOME and KDE and others.  When
Emacs goes into prerelease freeze, one of the things you freeze is the
translatable content.  Then you tell the translators that they can
work without fear that their translations will be obsoleted before
release.

There also must be thousands of Emacs users who are uncomfortable
contributing code, but if there was a serious effort on I18N would
consider translating to their own language an important and fulfilling
task.  Maintaining the sense of fulfilment requires proper respect
from the developers (cf. the description of the release cycle above,
plus as RMS imples some help from  developers on where the priorities
are so the translators can be confident their work is important).

Even if their primary interest was translating, such folks are more
likely to convert to Emacs developers (typically via a patch to
po-mode, you see?) than other users, since Emacs is a tool they use in
translation (remember, they're volunteers so there's some reason they
*want* to work on Emacs; it's a good bet they're already users).

I haven't been in close touch with the translator community for years,
but I believe that emacs/po-mode is still one of the most popular
tools for them (although web-based tools have been gaining ground
rapidly).

Emacs will probably not be fully translated until machine translation
becomes acceptable.  But that's no reason to give up in advance.

Re: Key bindings proposal

[Jan Djärv]

Stephen J. Turnbull skrev 2010-08-06 05.12:
>
> On the manpower side, just for the ones I'm familiar with, there are
> whole organizations of translators at Debian and Ubuntu who volunteer
> to do these things, and probably at GNOME and KDE and others.

Not to forget GNU itself:

http://translationproject.org/html/welcome.html

Buth the size of the translation project matters.  Larger packages tend to be 
less often translated than smaller.

	Jan D.

Re: Key bindings proposal

[Stephen J. Turnbull]

Jan Djärv writes:
 > Stephen J. Turnbull skrev 2010-08-06 05.12:

 > > On the manpower side, just for the ones I'm familiar with, there are
 > > whole organizations of translators at Debian and Ubuntu who volunteer
 > > to do these things, and probably at GNOME and KDE and others.
 > 
 > Not to forget GNU itself:
 > 
 > http://translationproject.org/html/welcome.html

Crap, I had GNU in there, along with a bunch of off-thread-topic
stuff, and edited it all out.  :-(  Thanks for the correction.  :-)

 > Buth the size of the translation project matters.  Larger packages
 > tend to be less often translated than smaller.

That's an important point.  That's another reason why it's important
to prioritize, to make the immediate task feel smaller and do-able.

Another way to address the size issue: With some judicious negotiation
among stakeholders, the various packages (which are bite-size by
comparison) could take turns asking for help from the translation
project(s).

Re: Key bindings proposal

[Richard Stallman]

    It's impractical to internationalize the docstrings; there's too much.
    Internationalizing the menu-bar is doable.

It would be a lot of work, but that need not be an obstacle, because
it doesn't need to be complete to be useful.  If a team of translators
adopts sensible priorities for which doc strings to work on first,
their work could be useful even if they have covered only 1% of the
doc strings.

Re: Key bindings proposal

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Thu, 05 Aug 2010 10:01:21 -0400
> Cc: levelhalom@gmail.com, emacs-devel@gnu.org
> 
>     It's impractical to internationalize the docstrings; there's too much.
>     Internationalizing the menu-bar is doable.
> 
> It would be a lot of work, but that need not be an obstacle, because
> it doesn't need to be complete to be useful.  If a team of translators
> adopts sensible priorities for which doc strings to work on first,
> their work could be useful even if they have covered only 1% of the
> doc strings.

I agree.  But some initial design is necessary, because the issues are
subtle, but non-trivial.

This was discussed a few times in the past, see, for example the
following two large threads:

    http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg01464.html
    http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg01525.html

    http://lists.gnu.org/archive/html/emacs-devel/2001-11/msg00945.html
    http://lists.gnu.org/archive/html/emacs-devel/2001-12/msg00200.html

Re: Key bindings proposal

[Stephen J. Turnbull]

Andreas Schwab writes:
 > Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:
 > 
 > > Further, I don't think the argument has validity.  You don't have to
 > > "remember" the menu entries.  You can see them!
 > 
 > You have to remember where to search, and do search for them.  And if
 > you change the language you are screwed.  What a stupid concept.

If you're depending on muscle memory, indeed.

But as George Carlin put it, "They ask me what I think of the dope
problem.  I think we definitely have too many dopes!"  There are
dope-y users, or, more precisely, users who (think they) have better
use for time and brain cells (or even peripheral ganglia aka muscle
memory) than memorizing Emacs keystrokes.  I think those users should
be served.

Where I differ from Uday is that it is my considered opinion (subject
to change given good evidence, but I don't expect to encounter such
:-) that there's no particular reason for *Emacsen* to do so.  It
happens that Ben Wing disagreed with me and put in many hours to
implement accelerators and reorganize the menus, so (IMO) I not only
won the argument (it didn't bring more developer or that many new
users), but got a nice feature for XEmacs, too.  Without spending my
own time on it! :-)

Maybe Uday will do the same for Emacs. :-)

Re: Key bindings proposal

[Stephen J. Turnbull]

Uday S Reddy writes:

 > I made a mistake in my previous response to Stephen, it seems.  XEmacs
 > does provide menu accelerators and it probably did it since 2001.  So,
 > the infrastructure has been there.  However, the menus don't seem to
 > have been designed all that carefully to avoid conflicts.  (I got
 > fooled because the examples that I tried all had conflicts.)

That's possibly true in XEmacs 21.4 (then, and now).  I think Ben's
big push on the menus was later, and probably only made it into 21.5.

Anyway, in 21.5 I don't see any conflicts.  I think if there are
conflicts, it starts randomly assigning accelerators.  (Well, not
entirely randomly; it uses numbers, which normally are not used that
way.)

Re: Key bindings proposal

[Jason Rumney]

joakim@verona.se writes:
>
> I dont understand this. I normaly have menus disabled, but I enabled
> them now to see. In the File menu I have an entry like:
>
>   "Visit new file... C-x C-f"
>
> Isn't that a "keyboard accelerator"? I note that Firefox does the same
> thing for this menu entry:
>
>  "bookmarks/organize bookmarks ctrl+shif+o"

The Bookmarks menu is not a good example, as it doesn't have
accelerators, but if you look at the File menu in Firefox for example,
you'll see that many of the commands in there have a letter underlined,
in addition to the global keybinding that is printed to the right.  Some
people prefer navigating the menu with Alt-F N for New Window instead of
Ctrl-N, as the underlined letter for each step is always visible (you
have to open the File menu to see the Ctrl-N, by which time you have
lost the advantage of the shorter key sequence).

Although Emacs supports menu navigation with F10, you then have to use
the arrow keys, which is cumbersome.

RE: Key bindings proposal

[Stephen J. Turnbull]

Uday S Reddy writes:

 > If you already had keyboard accelerators of menus in 2001, well, thank
 > you very much for it!  But, it still requires extra RET key strokes to
 > confirm selections.

I'm not sure what extra RET key strokes you're talking about.  In
XEmacs, you hold down the appropriate modifier with a menubar
accelerator key.  This pulls down that menu.  Then you navigate to the
desired item by pressing the appropriate item accelerators, which take
effect immediately, either popping a submenu or running a command.  Of
course if it's something like find-file which takes a string input,
you'll need to terminate the string with RET.  But other than key
order, it's no different from the ordinary keymap[1] (except for being
a lot slower for me :-).

Maybe you're just using the wrong Emacs for your purposes. :-)

 > Coming back to the students, the vast majority of them switched to
 > IDEs by the time they reached their final year.  So, while we had done
 > our bit by introducing them to Emacs, Emacs wasn't able to retain them
 > due to its limitations.  In this sense, the previous thread was right
 > in focusing on the IDE support.

I don't understand "in this sense."  As Bill Clinton didn't say, "It's
the apps, stupid."  IDE is *really* important to Java programmers as I
understand it because of restrictions of the language.  WYSIWYG and
multimedia content is really important to non-programmers.  Emacs
provides neither very well, and CEDET, while very nice, is unlikely to
ever catch up to Eclipse.  Multimedia is pretty much hopeless for the
forseeable future, too.

 > The user base is still needed to motivate contributors to find it
 > worthwhile to come forward.  Mozilla and Eclipse have armies of
 > contributors, not because they have great manuals but because they
 > have large user bases.

That's the "post hoc" fallacy.  IMO, Eclipse has armies of
contributors because programming in Java sucks, and Eclipse is the
best available way to make it suck less (certified by Big Blue, no
less).  And Mozillla?  Yes, when you have hundreds of millions of
users, even an 0.00001% annual user-to-developer conversion rate is
enough to produce plenty of cannon fodder.  But there's no way Emacs
can compete with Mozilla in terms of sheer numbers of users, unless it
becomes a browser.  And I don't see that happening.

 > >  > And, Emacs has to fit in.
 > > 
 > > Why?
 > 
 > Because, otherwise, you raise the barrier to entry so high that only a
 > small minority of potential users will be able to get through.

If it's the minority of users who will become contributors, that's a
big win. :-)

Footnotes: 
[1]  There is a known XEmacs weirdness that the use of the modifier is
restricted to the initial pulldown menu.  Items and submenus *must* be
selected with an *unmodified* key.  This is stupid, of course. ;-)
Maybe that's the problem you're thinking of?

RE: Key bindings proposal

[Uday S Reddy]

Stephen J. Turnbull writes:

> I'm not sure what extra RET key strokes you're talking about.  In
> XEmacs, you hold down the appropriate modifier with a menubar
> accelerator key.  This pulls down that menu.  

As I mentioned in my previous message, I got fooled because the
examples I tried all had conflicts.

I went to a dired buffer and tried

m to get to Cmds, but it conflicted with Mark
s to get to Subdir, but it conflicted with Sort
l to get to Look, but it conflicted with "Load emacs" 

Then I generalized, wrongly!

But 3 conflicts in the titles of a single menubar is rather much, I
think.

Cheers,
Uday

RE: Key bindings proposal

[Stephen J. Turnbull]

Uday S Reddy writes:

 > As I mentioned in my previous message, I got fooled because the
 > examples I tried all had conflicts.
 > 
 > I went to a dired buffer and tried [...]

Aha.  I see what's happening here; that's stunningly bad, or at least
unfortunate, design.  It's now issue725, and offtopic for this list.
Reply-To set to xemacs-beta.  (Not that I expect any, but just in case.)

Re: Key bindings proposal

[Óscar Fuentes]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

[snip]

> IDE is *really* important to Java programmers as I understand it
> because of restrictions of the language.

No. IDEs are becoming more and more important for developers because
they are improving productivity through smart completion, refactoring
support, live checks, tight integration with other tools (debuggers,
analyzers of various sorts) etc. Java/Eclipse was one of the first to
get there, because the language is specially amenable to that sort of
features and has lots of money backing it, but others are following
suit.

[snip]

> Emacs provides neither very well, and CEDET, while very nice, is
> unlikely to ever catch up to Eclipse.

This is not necessarily so. As the author of CEDET explained a few hours
ago, the package can interface with external tools for providing all
sorts of information. Build an open interface to Eclipse internals
(maybe there is already one?) and you have all the potential of Eclipse
in Emacs. Once achieved that, you only need to do the UI work (which is
not trivial, but certainly doable.)

[snip]

Re: Key bindings proposal

[joakim]

Óscar Fuentes <ofv@wanadoo.es> writes:

> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
>
> [snip]
>
>> IDE is *really* important to Java programmers as I understand it
>> because of restrictions of the language.
>
> No. IDEs are becoming more and more important for developers because
> they are improving productivity through smart completion, refactoring
> support, live checks, tight integration with other tools (debuggers,
> analyzers of various sorts) etc. Java/Eclipse was one of the first to
> get there, because the language is specially amenable to that sort of
> features and has lots of money backing it, but others are following
> suit.
>
> [snip]
>
>> Emacs provides neither very well, and CEDET, while very nice, is
>> unlikely to ever catch up to Eclipse.
>
> This is not necessarily so. As the author of CEDET explained a few hours
> ago, the package can interface with external tools for providing all
> sorts of information. Build an open interface to Eclipse internals
> (maybe there is already one?) and you have all the potential of Eclipse
> in Emacs. Once achieved that, you only need to do the UI work (which is
> not trivial, but certainly doable.)

There is lots of library type functionality for this sort of thing in
Java. Some of it is used in the JDE. The JDE already uses Cedet.

An similar aproach I worked on a bit was this:

- Make EDE realice a pom.xml is a Maven project file 

- Hook up Cedet to the Maven via Clojure

EDE is a project support facility in Cedet. Maven is a project
dependency and build tool facility for Java. Clojure is a lisp-like
interpreter on top of Java.

The thing I wanted to achieve was:

- user downloads emacs

- installs "java-maven-cedet-adaptor.el" (or whatever) from elpa

- opens a random src file in his existing java project shared with
eclipse developers also using maven

- experiences the bliss of instant working completion and tag navigation
in Emacs, thus stunning eclipse users, otherwise accustomed to Emacs
users mumbling and pretending completion and navigation is only for n00bs.

It is entirely doable and not so far off. 

> [snip]
>
-- 
Joakim Verona

Re: Key bindings proposal

[Stefan Monnier]

> Menu navigation by keys is actually the best form of interaction for

Regardless or whether that's the case, I fully agree that it is
a feature we're sorely lacking (IIUC it works on w32 if you separate
Alt from Meta, or something like it).


        Stefan

Re: Key bindings proposal

[Stuart Hacking]

On 31 July 2010 11:04, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote:
>
> [snip]
>
> My idea was why can't one type something like "M-x isearch" to get this
> function, instead of "M-x dired-do-isearch" which is too long-winded and
> "M-s a C-s" which is too twisted and unmemorable?  This requires a new
> concept for Emacs, bindable command names that can vary across modes.

To me, this sounds a lot like personal preference. I already have an
emacs-lisp file full of global and mode specific keybindings and
another with some convenience defaliases. These make sense for the way
I work, but I'm sure they would be completely inappropriate for
certain other users.

Is your suggestion to automatically alias functions by the current
major mode? (by, for example, removing the prefix? (dired-do-isearch
-> isearch))

Or, do you want a simple method of aliasing commands across modes? How
would this work?

(define-multi-alias 'isearch
  ('dired-mode 'dired-do-isearch)
  ...
  ...
  (t 'isearch))


>  (Stephen Turnbull is going to say that you can already get its effect
> through some other means. That is all well and good.  The discussion right
> now is really about how to set up an architecture that is functional for the
> users.  Not everything whose effect can be achieved by other means becomes
> part of the architecture unless we use it appropriately!)

the 'architecture' that I use is a combination of `defalias',
`add-hook', and `define-key' in my personal init files. Am I doing
something wrong?

>
> [snip]
>
> Cheers,
> Uday

Best regards,
--Stuart

Re: Key bindings proposal

[Uday S Reddy]

Stuart Hacking writes:

> To me, this sounds a lot like personal preference. I already have an
> emacs-lisp file full of global and mode specific keybindings and
> another with some convenience defaliases. These make sense for the way
> I work, but I'm sure they would be completely inappropriate for
> certain other users.

Excellent.  The only "personal" thing I see about it is that you might
have picked aliases based on personal preference.  But there is no
reason why the concept of giving such aliases is personal.  That is a
generally useful idea.

> Is your suggestion to automatically alias functions by the current
> major mode? (by, for example, removing the prefix? (dired-do-isearch
> -> isearch))

Indeed, that is one part of the suggestion.  The part 2 of the
suggestion is to allow key bindings for such aliases, which would then
be widely applicable across several modes.

> Or, do you want a simple method of aliasing commands across modes? How
> would this work?
> 
> (define-multi-alias 'isearch
>   ('dired-mode 'dired-do-isearch)
>   ...
>   ...
>   (t 'isearch))

Do you mean you already have such an aliasing scheme?  I suppose one
can dispatch on the major mode.  That is neat!

It is not a general solution, of course, since it is based on a closed
world assumption about what modes one needs to deal with.  But it is a
good starting point.

> the 'architecture' that I use is a combination of `defalias',
> `add-hook', and `define-key' in my personal init files. Am I doing
> something wrong?

So, I suppose you will let dired-mode do all its self-righteous key
bindings and then use a hook to overwrite all of them with your own
key bindings?  I think I am beginning to like this
software-as-the-enemy principle!

Cheers,
Uday

Re: Key bindings proposal

[Stuart Hacking]

On 2 August 2010 11:58, Uday S Reddy <u.s.reddy@cs.bham.ac.uk> wrote:
> Stuart Hacking writes:
>
>> To me, this sounds a lot like personal preference. I already have an
>> emacs-lisp file full of global and mode specific keybindings and
>> another with some convenience defaliases. These make sense for the way
>> I work, but I'm sure they would be completely inappropriate for
>> certain other users.
>
> Excellent.  The only "personal" thing I see about it is that you might
> have picked aliases based on personal preference.  But there is no
> reason why the concept of giving such aliases is personal.  That is a
> generally useful idea.

Then Emacs already provides this feature, right? If I don't like a
keybinding or command name I can modify/alias them. Furthermore, I can
do this only for a specific mode.

> So, I suppose you will let dired-mode do all its self-righteous key
> bindings and then use a hook to overwrite all of them with your own
> key bindings?  I think I am beginning to like this
> software-as-the-enemy principle!

Emacs has a set of default keybindings which can be modified to suit
the taste of the user. Where is the issue here? (Some software that I
use will not let me redefine key bindings at all.)

Is the solution to distribute a version of emacs with no keybindings set? :)

--Stuart

Re: Key bindings proposal

[Uday S Reddy]

Stuart Hacking writes:

> Emacs has a set of default keybindings which can be modified to suit
> the taste of the user. Where is the issue here? (Some software that I
> use will not let me redefine key bindings at all.)
> 
> Is the solution to distribute a version of emacs with no keybindings set? :)

Ok, so, you don't believe in the software-as-the-enemy principle?
Sorry for attributing it to you.

If I were to use your scheme to set up Emacs in the flexible way, I
would need to define an entire range of generic aliases like you did
for "isearch" in your message.  Then I need to overwrite pretty much
*all* the key bindings that the modes do with my own bindings so that
the keys are bound to these generic aliases.  

Such an idea wouldn't have occured to me normally, because I really
imagine the software to be a friend.  So, if it doesn't help me, I
would get annoyed instead of thinkings of ways to defeat it.  But the
latter can work too, as you have demonstrated.

Do I want to distribute emacs with no key bindings at all?  No, not at
all.  All I am saying is that Emacs, which calls itself the
"customizable extensible editor," should accommodate the users that
like its way of doing things as well as the users who want to do
things differently.  Making life a peach for the followers but really
difficult for the dissenters doesn't quite fit the bill.

Cheers,
Uday

Re: Key bindings proposal

[Stephen J. Turnbull]

Uday S Reddy writes:

 > Making life a peach for the followers but really difficult for the
 > dissenters doesn't quite fit the bill.

I'm sorry, but you are wrong.  Nobody *made* life difficult for
dissenters; it just *is* difficult.  True, the Emacs developers
*chose* the relatively easy task of finding one path through a dense
maze (and even that has proved not so easy).  But to make life easy
for the dissenters is analogous to enumerating all the paths through
that maze.  Your dissenters demand a solution to a very difficult
task; Emacs doesn't make it hard for them, quite the contrary probably
Emacs is the only system which makes it possible to solve this problem
in a reasonable amount of work.  Other systems that I know of provide
at best the equivalents of `global-set-key' and `(setq global-map
full-keymap)'.  (You're welcome to point me at exceptions if you can,
of course, but all the systems I know of are limited in that way.)

We have agreed that it is possible, using defun and [remap], to do
what you propose in a loadable LISP library.  It's going to be a lot
of work, though, so I suggest you and other advocates get started.

Note that, once you've defined a few score core actions (the total
number of useful actions could easily run into the hundreds, but two
or three score, if judiciously chosen, is probably a good start) and
made note of the keymaps where they are used, it will be very easy to
make the system more robust and maintainable by making the internal
changes you and others have advocated.

But there is *zero* benefit doing things in the reverse order.  The
defun ... [remap] pattern will be sufficiently robust for use in
development of the system, just as advice.el is sufficiently robust
for development purposes.  A few minutes fiddling with a couple
special-purpose functions or macros or advice (eg, of `define-key')
will allow you to express the defun ... [remap] pattern concisely, and
all of the action definitions will then be usable if and when the
internal changes are made.  Any experimentation with the defun
... [remap] pattern that needs to be done would have to be done
anyway, in the development of an [action] pseudo-command.

Re: Key bindings proposal

[Tassilo Horn]

On Saturday 31 July 2010 12:04:50 Uday S Reddy wrote:

> My idea was why can't one type something like "M-x isearch" to get
> this function, instead of "M-x dired-do-isearch" which is too
> long-winded and "M-s a C-s" which is too twisted and unmemorable?

I don't know if that's a good idea.  Sounds a bit too DWIMish to me.
What do I do if I want to use normal isearch although there is a
mode-specific isearch implementation?

What I could think of would be the introduction of a namespace concept.
So all basic commands would be declared in the global namespace, and
each mode could have it's own namespace:

  (defun dired:isearch (...) ...)

Emacs then could then have a buffer local `namespace' variable per
major-mode (or a list (major minor1 minor2...)?), so that M-x isearch in
dired-mode would actually call dired:isearch.  To get the global
function, you could do M-x :isearch.

But such a concept would somehow be orthogonal to [remap ...].  If
there's `dired:isearch', I'd expect that `C-s' invokes `dired:isearch'
in dired-mode without having to explicitly remap...

Just audibly thinking...
Tassilo

Re: Key bindings proposal

[Uday S Reddy]

Tassilo Horn writes:

> > My idea was why can't one type something like "M-x isearch" to get
> > this function, instead of "M-x dired-do-isearch" which is too
> > long-winded and "M-s a C-s" which is too twisted and unmemorable?
> 
> I don't know if that's a good idea.  Sounds a bit too DWIMish to me.
> What do I do if I want to use normal isearch although there is a
> mode-specific isearch implementation?

Sorry, I was just giving "M-x isearch" just to illustrate the number
of key presses required.  It could be "M-y isearch" for all we care.
Note that this "isearch" is different from a function called
"isearch".  It is in a different name space.

> Emacs then could then have a buffer local `namespace' variable per
> major-mode (or a list (major minor1 minor2...)?), so that M-x isearch in
> dired-mode would actually call dired:isearch.  To get the global
> function, you could do M-x :isearch.

Thank you.  A scheme like that would feel so 21st century!

> But such a concept would somehow be orthogonal to [remap ...].  If
> there's `dired:isearch', I'd expect that `C-s' invokes `dired:isearch'
> in dired-mode without having to explicitly remap...

Yes, it is orthogonal to the [remap...] idea.

I think we really wouldn't want dired to remap `isearch-forward' to
`dired:isearch', because `isearch-forward' is quite useful in a dired
buffer.  The user can do such remapping for himself if he/she wants
that.

Cheers,
Uday

Re: Key bindings proposal

[Juri Linkov]

> function has to be on a key or people won't use it.
> And the key combinations keep getting weirder and weirder.
> Like M-s a C-s to do an isearch!

Well, we have 4 basic input trees for input sequences
and usually are trying to add a command to all of them:

1. Command names for M-x.  An input sequence comprises of characters
of the command name, and completion helps making the input sequence shorter.
This have to be taken into account when designing a scheme for command
names (using an unique command name prefix, etc.)

To improve this type of input, we could try adding dwim completions
for M-x.  For instance, like the `calc-execute-extended-command' command
basically does the same as `execute-extended-command' but prefills the
minibuffer's input with the `calc-' prefix:

  M-x calc-

Similarly e.g. in Dired, M-x could guess the `dired-' prefix
for Dired commands, so you could just add `isearch' to run
`dired-isearch-filenames'.

For more convenience, this could also behave like completions
in text fields in web browsers and push the most likely completions
combined with more frequent items from the input history
to the top of the completions list.

2. Menus.  In a menu-driven program with menu accelerators
using Alt+Letter in a sequence like `M-s a C-s' selects
an action from the main menu.

So if we had a separate top-level menu "_S_earch" then using the menu
accelerator key `M-s' would open the Search menu.  Then the next key `a'
will select a submenu with the menu accelerator `a', and the final key
`C-s' will run a command bound to the menu item.  If the last key is RET,
it will select the first menu item.

3. Key sequences of input events.

You seem to suggest that we have to refrain from binding each and every
command to a key sequence since it duplicates two other input types above.

I tend to agree provided that M-x completions are as short as possible
and the menu structure is well-thought-out (balanced breadth and depth,
e.g. to reduce the length of the overlong File menu, print-related items
could be moved into a submenu with the "_P_rint" menu accelerator, etc.)

4. Toolbar (a flat menu with icons).

All in all, is it a conclusion we are leaning towards:

1. All commands should have a name designed for M-x completions.
2. Most commands should be presented in the main menu.
3. Few basic commands should be bound to a key sequence.
4. Some of most frequently used command should be added to the toolbar.

Re: Key bindings proposal

[Thierry Volpiatto]

Hi Juri,

Juri Linkov <juri@jurta.org> writes:

>> function has to be on a key or people won't use it.
>> And the key combinations keep getting weirder and weirder.
>> Like M-s a C-s to do an isearch!
>
> Well, we have 4 basic input trees for input sequences
> and usually are trying to add a command to all of them:
>
> 1. Command names for M-x.  An input sequence comprises of characters
> of the command name, and completion helps making the input sequence shorter.
> This have to be taken into account when designing a scheme for command
> names (using an unique command name prefix, etc.)
>
> To improve this type of input, we could try adding dwim completions
> for M-x.  For instance, like the `calc-execute-extended-command' command
> basically does the same as `execute-extended-command' but prefills the
> minibuffer's input with the `calc-' prefix:
>
>   M-x calc-

If you use anything, you have to try anything-M-x (<f5-a> M-x) that give
you history (easy to use, no need to know M-p/n) and describe commands
under point with C-z (without quitting M-x).
  
> Similarly e.g. in Dired, M-x could guess the `dired-' prefix
> for Dired commands, so you could just add `isearch' to run
> `dired-isearch-filenames'.

If you know that something is called isearch in emacs. ;-)

> For more convenience, this could also behave like completions
> in text fields in web browsers and push the most likely completions
> combined with more frequent items from the input history
> to the top of the completions list.

That what does anything-M-x.

> 2. Menus.  In a menu-driven program with menu accelerators
> using Alt+Letter in a sequence like `M-s a C-s' selects
> an action from the main menu.
>
> So if we had a separate top-level menu "_S_earch" then using the menu
> accelerator key `M-s' would open the Search menu.  Then the next key `a'
> will select a submenu with the menu accelerator `a', and the final key
> `C-s' will run a command bound to the menu item.  If the last key is RET,
> it will select the first menu item.
>
> 3. Key sequences of input events.
>
> You seem to suggest that we have to refrain from binding each and every
> command to a key sequence since it duplicates two other input types above.
>
> I tend to agree provided that M-x completions are as short as possible
> and the menu structure is well-thought-out (balanced breadth and depth,
> e.g. to reduce the length of the overlong File menu, print-related items
> could be moved into a submenu with the "_P_rint" menu accelerator, etc.)
>
> 4. Toolbar (a flat menu with icons).
>
> All in all, is it a conclusion we are leaning towards:
>
> 1. All commands should have a name designed for M-x completions.
> 2. Most commands should be presented in the main menu.
> 3. Few basic commands should be bound to a key sequence.
> 4. Some of most frequently used command should be added to the toolbar.
>
>

-- 
Thierry Volpiatto
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Key bindings proposal

[Juri Linkov]

> If you use anything, you have to try anything-M-x (<f5-a> M-x) that give
> you history (easy to use, no need to know M-p/n) and describe commands
> under point with C-z (without quitting M-x).

I tried anything, but it does nothing.

anything-M-x displays an empty list.  TAB displays the message
"Nothing is selected".  C-z displays the message "No candidates".
Do you have an idea what is wrong?

Re: Key bindings proposal

[Thierry Volpiatto]

Juri Linkov <juri@jurta.org> writes:

>> If you use anything, you have to try anything-M-x (<f5-a> M-x) that give
>> you history (easy to use, no need to know M-p/n) and describe commands
>> under point with C-z (without quitting M-x).
>
> I tried anything, but it does nothing.
>
> anything-M-x displays an empty list.  TAB displays the message
> "Nothing is selected".  C-z displays the message "No candidates".
> Do you have an idea what is wrong?

Nothing is wrong, start typing commands say dired-, after exactly two
characters typed (i.e "di") you will see completion.

choose a command in list and run it with RET, C-z to describe it.

When you have run command it is added in extended-command-history.
Next time you run anything-M-x, you will see your command appearing in
a buffer with header "Emacs commands history".

NOTE: There is no TAB menu in this command as it use anything-comp-read,
an "anything" completing-read that have a sole action like
completing-read (Two indeed with the possibility of a persistent action
i.e C-z).


-- 
Thierry Volpiatto
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

RE: Key bindings proposal

[Drew Adams]

> > I tried anything, but it does nothing.
> > Do you have an idea what is wrong?
> 
> Nothing is wrong, start typing commands say dired-, after exactly two
> characters typed (i.e "di") you will see completion.
> choose a command in list and run it with RET, C-z to describe it.
> 
> When you have run command it is added in extended-command-history.
> Next time you run anything-M-x, you will see your command appearing in
> a buffer with header "Emacs commands history".

FWIW, nearly the same with Icicles.

But `dir' instead of `di', since there are also non-Dired command names (e.g.
`diary', `diff') that start with `di'.  And `C-M-RET' instead of `C-z' for
candidate help.  And just `M-x', not `anything-M-x'.  And normal access to the
history (as well as access using completion).

I made the point that the solution to the problem Juri described is not to
rename the commands but to use better completion (e.g. substring, regexp,
pcomplete, fuzzy,...).  That's the point.  It does not matter how you get better
completion.

I mentioned that even vanilla Emacs now offers completion other than prefix
completion - one need *not* use Icicles or Anything (or Ido, for that matter) to
invoke a command whose names matches somewhere other than the prefix. 

(However, Icicles (and probably Anything, by now) also offers progressive
completion, which lets you match multiple patterns (e.g. substrings) without
regard to order.)

The main point is that commands should *not* be named only on the basis of
facilitating prefix completion.  Instead, if you want to improve completion
matching, then use non-prefix matching.

Re: Key bindings proposal

[Juri Linkov]

> And normal access to the history (as well as access using completion).

Any reason why this is still not available in vanilla Emacs?

> I made the point that the solution to the problem Juri described is
> not to rename the commands but to use better completion
> (e.g. substring, regexp, pcomplete, fuzzy,...).  That's the point.
> It does not matter how you get better completion.

Yes, better completion is what we need.  This includes pushing
more likely completions to the top of the list.  But it seems
in anything-M-x the sorting order of completions is random
(at least, I can't deduce any logic behind the order of its completions).

Re: Key bindings proposal

[Thierry Volpiatto]

Juri Linkov <juri@jurta.org> writes:

>> And normal access to the history (as well as access using completion).
>
> Any reason why this is still not available in vanilla Emacs?
>
>> I made the point that the solution to the problem Juri described is
>> not to rename the commands but to use better completion
>> (e.g. substring, regexp, pcomplete, fuzzy,...).  That's the point.
>> It does not matter how you get better completion.
>
> Yes, better completion is what we need.  This includes pushing
> more likely completions to the top of the list.  But it seems
> in anything-M-x the sorting order of completions is random
> (at least, I can't deduce any logic behind the order of its completions).

No sorting is done in anything-M-x, i think it's not really useful, as
as soon you type some characters, all commands starting with these
characters go on top of list.

Regexp are accepted also, and if you have anything-match plugin enabled,
multi regexp completion is available (just enter a space in anything
pattern).

OTOH, last command used is always pushed on top of history, that mean
all recents commands are on top of list (doublons and not bounded
commands are removed).

-- 
Thierry Volpiatto
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

RE: Key bindings proposal

[Drew Adams]

> > And normal access to the history (as well as access using 
> > completion).
> 
> Any reason why this is still not available in vanilla Emacs?

Why _what_ is not in vanilla Emacs - (a) Icicles or (b) the addition of previous
command inputs to the command history or (c) the ability to complete against
history items?

You know the answer for (a).

(b) _is_ of course available in vanilla Emacs.  Icicles just extends vanilla
minibuffer input, so it maintains this vanilla property.  `Anything' might be a
different story - dunno.

For (c), the answer is that no one has bothered to add the feature to vanilla
Emacs. Note: Completion against the history list has this advantage over cycling
and searching it (`M-p', `M-r'): the age of the input retrieved is irrelevant.


[FWIW - (c) is provided by Icicles in 3 different ways:

c1. During minibuffer input anytime (not necessarily input with completion), you
can use `M-o' to insert a previous input from the input history using completion
(recursive minibuffer).  This is on-demand history completion.  I've suggested
in the past that vanilla Emacs do likewise.

IIRC, at one point you or someone else proposed simply adding previous inputs to
the completion-candidate set.  That is misguided, IMO - the two sets should be
kept separate.  But completion can be allowed independently against both sets -
even during the same input interaction.

c2. During completion, you can use `M-h' to filter the current set of completion
candidates, limiting it to past inputs.

c3. During completion, you can use `M-pause' to filter the (raw/initial) domain
of completion candidates, limiting it to past inputs.

(c2) and (c3) differ in that Icicles lets you progressively filter the set of
candidates or even replace it by a saved set.  (b2) acts on the current set of
candidates; (c3) acts on the domain of candidates defined by the command.]


[FWIW2 - Icicles has additional history-list features, any of which could serve
as food for thought for vanilla Emacs.  Two simple examples: (1) highlight the
previous inputs in *Completions* (optionally: `C-pause' toggles it during
completion); (2) sort the candidates on demand (e.g. putting previous inputs
first).

http://www.emacswiki.org/emacs/Icicles_-_History_Enhancements]

> > I made the point that the solution to the problem Juri described is
> > not to rename the commands but to use better completion
> > (e.g. substring, regexp, pcomplete, fuzzy,...).  That's the point.
> > It does not matter how you get better completion.
> 
> Yes, better completion is what we need.  This includes pushing
> more likely completions to the top of the list.

Be careful, please.  What the program considers "more likely" might not
correspond to what some user considers more likely in a given context.  This
kind of thing should be under user control.

DWIM should always be considered at best only a stupid guess.  It should be
subjected to user control - preferably runtime, on-the-fly control.  Only in
that context can DWIM be useful and not just an annoyance.  Programs can
sometimes help by being smart, but users still know best.

It would be a mistake, IMO, to systematically place previous inputs at the
beginning of the *Completions* list.

Of course, vanilla Emacs does not let you cycle among candidates, so their order
is irrelevant except in terms of what user sees (in *Completions*).  Even so, it
is a bad idea to impose an order such as chronological (previous use).
Alphabetical order has the advantage of making it easy to find a name (think of
an index in a book).

[In Icicles, users can sort completion candidates on the fly in many ways, the
possible sort orders being dependent on the context (and under user control).]

> But it seems in anything-M-x the sorting order of completions is
> randome (at least, I can't deduce any logic behind the order of its 
> completions).

Re: Key bindings proposal

[Juri Linkov]

> Why _what_ is not in vanilla Emacs - (a) Icicles or (b) the addition of previous
> command inputs to the command history or (c) the ability to complete against
> history items?

(c)

> For (c), the answer is that no one has bothered to add the feature to vanilla
> Emacs. Note: Completion against the history list has this advantage over cycling
> and searching it (`M-p', `M-r'): the age of the input retrieved is irrelevant.
>
> c1. During minibuffer input anytime (not necessarily input with completion), you
> can use `M-o' to insert a previous input from the input history using completion
> (recursive minibuffer).  This is on-demand history completion.

I think `M-h' is a better key since it has obvious mnemonics: h = history.

> IIRC, at one point you or someone else proposed simply adding previous inputs to
> the completion-candidate set.  That is misguided, IMO - the two sets should be
> kept separate.  But completion can be allowed independently against both sets -
> even during the same input interaction.

Some web browsers combine previous input (sorted alphabetically
or by frequency) with suggestions in the same list.

RE: Key bindings proposal

[Drew Adams]

> 1. Command names for M-x.  An input sequence comprises of characters
> of the command name, and completion helps making the input 
> sequence shorter.  This have to be taken into account when
> designing a scheme for command names (using an unique command
> name prefix, etc.)
> 
> To improve this type of input, we could try adding dwim completions
> for M-x.  For instance, like the 
> `calc-execute-extended-command' command
> basically does the same as `execute-extended-command' but prefills the
> minibuffer's input with the `calc-' prefix:  M-x calc-
> 
> Similarly e.g. in Dired, M-x could guess the `dired-' prefix
> for Dired commands, so you could just add `isearch' to run
> `dired-isearch-filenames'.

Please don't. There are lots of 3rd-party extensions to Dired (etc.) whose
commands do not start with the prefix `dired-'. Typically, they start with the
3rd-party library prefix. Likewise, for personal user commands that are useful
in Dired (etc.).

There is no problem getting completion to filter only to a given prefix or
substring or whatever, even in vanilla Emacs (e.g. using completion styles).
Hard-coding prefix matching for the current mode is truly misguided.

> So if we had a separate top-level menu "_S_earch"

I've long argued for such a top-level menu. I've used a `Search' menubar menu
for decades. There is lots of stuff on other menus that really belongs on
`Search', and it's helpful for it to be top level. If people are worried about
menu space, then move something like `Options' back under `Help' or `File' (it
was originally under `Help').

This is a useful change independently of the reason you gave (use of menu
accelerators).

> 4. Toolbar (a flat menu with icons).

If changes are to be envisioned for the tool bar, they should be along lines
already suggested previously: allow for multiple actions, popup menu, etc. per
icon (e.g. via modifier keys).

The only things particular about a tool bar should be (1) icons, (2) immediate,
single action by clicking.

Emacs provides a deep, rich user experience with multiple levels of interaction.
Emacs tool bars could be made richer and more useful while retaining their
simplicity for novice use. There is no reason to limit Emacs tool bars to what
are available in some other apps. And even some other apps have tool-bar icons
that allow more complex interaction.

> All in all, is it a conclusion we are leaning towards:
> 
> 1. All commands should have a name designed for M-x completions.
> 2. Most commands should be presented in the main menu.
> 3. Few basic commands should be bound to a key sequence.
> 4. Some of most frequently used command should be added to the toolbar.

That is definitely not a conclusion (4 conclusions) that I am leaning toward.

#1: Naming a command can take completion into account to some degree, but that
should be only a minor consideration. There are other things important about
command names (discoverability, naming patterns for the library, relation to
other commands,...).

#2: A command should be put on a menu only when it is helpful to provide it with
menu access and organization (e.g. discoverability, association with similar
commands). It makes no sense to say that "most" commands should or should not be
on menus, let alone the "main menu" (whatever that might be).

#3 is particularly off the wall. (Though it's unclear what you might mean by
"basic commands".)  Having a command bound by default does not prevent anyone
from rebinding it to a different key. It is true that many commands need not be
bound by default, but it is also true that many are not bound by default. There
is no problem here that needs to be solved.

#4: Some should. Some should not. This is a vacuous conclusion.

Re: Key bindings proposal

[Juri Linkov]

>> So if we had a separate top-level menu "_S_earch"
>
> I've long argued for such a top-level menu. I've used a `Search'
> menubar menu for decades. There is lots of stuff on other menus that
> really belongs on `Search', and it's helpful for it to be top level.
> If people are worried about menu space, then move something like
> `Options' back under `Help' or `File' (it was originally under `Help').

In most programs `Options' (or `Preferences') is just one menu item
under `Edit' or `Tools'.

Re: Key bindings proposal

[Juri Linkov]

> This is a useful change independently of the reason you gave
> (use of menu accelerators).

But what are technical difficulties of implementing menu accelerators?

IIUC, Gtk and Windows already support menu accelerators,
and they will also improve navigation in tmm-menubar
(that currently assigns quite random accelerators).

So for instance, in Gimp you can open a file by typing `<f10> f o'.
And in Emacs it will be possible to do exactly the same
in Gtk, Windows, xterm and non-toolkit versions (using tmm).

RE: Key bindings proposal

[Drew Adams]

> > This is a useful change independently of the reason you gave
> > (use of menu accelerators).
> 
> But what are technical difficulties of implementing menu accelerators?

I have no idea.  But apparently Lennart has more or less succeeded for Windows,
and Stephen mentioned that XEmacs added accelerators long ago.

> IIUC, Gtk and Windows already support menu accelerators,
> and they will also improve navigation in tmm-menubar
> (that currently assigns quite random accelerators).

[With La Carte what you type directly reflects the menu names themselves: you
complete against a menu path (with substring etc. matching, if you use Icicles
or Ido etc.).  There is nothing arbitrary about what you type.  This helps you
learn and remember the menu organization.  You can drill down the menu hierarchy
progressively, as in TMM (but with meaningful input) or you can match your menu
target directly.]
 
> So for instance, in Gimp you can open a file by typing `<f10> f o'.
> And in Emacs it will be possible to do exactly the same
> in Gtk, Windows, xterm and non-toolkit versions (using tmm).

I have nothing against Emacs supporting menu accelerators. That should be clear
from previous posts.  [And La Carte already handles (Lennart's implementation
of) accelerators.]

I was simply agreeing with you that `Search' could and perhaps should be a
top-level menu.  And that is so whether or not Emacs supports menu accelerators.

Re: Key bindings proposal

[Juri Linkov]

>> But what are technical difficulties of implementing menu accelerators?
>
> I have no idea.  But apparently Lennart has more or less succeeded for Windows,
> and Stephen mentioned that XEmacs added accelerators long ago.

Does XEmacs bind a key (or key sequences) to access the top-level menu?
I mean something like <f10> or Alt-F (for File menu)?

>> IIUC, Gtk and Windows already support menu accelerators,
>> and they will also improve navigation in tmm-menubar
>> (that currently assigns quite random accelerators).
>
> [With La Carte what you type directly reflects the menu names themselves: you
> complete against a menu path (with substring etc. matching, if you use Icicles
> or Ido etc.).  There is nothing arbitrary about what you type.  This helps you
> learn and remember the menu organization.  You can drill down the menu hierarchy
> progressively, as in TMM (but with meaningful input) or you can match your menu
> target directly.]

Tmm is for menu navigation, and La Carte is for menu completion.
I think they both are useful.

>> So for instance, in Gimp you can open a file by typing `<f10> f o'.
>> And in Emacs it will be possible to do exactly the same
>> in Gtk, Windows, xterm and non-toolkit versions (using tmm).
>
> I have nothing against Emacs supporting menu accelerators. That should be clear
> from previous posts.

Then who is against Emacs supporting menu accelerators? :-)

RE: Key bindings proposal

[Drew Adams]

> >> But what are technical difficulties of implementing menu 
> >> accelerators?
> >
> > I have no idea.  But apparently Lennart has more or less 
> > succeeded for Windows, and Stephen mentioned that XEmacs
> > added accelerators long ago.
> 
> Does XEmacs bind a key (or key sequences) to access the 
> top-level menu? I mean something like <f10> or Alt-F
> (for File menu)?

No idea.  Maybe Stephen can help you here.

> >> IIUC, Gtk and Windows already support menu accelerators,
> >> and they will also improve navigation in tmm-menubar
> >> (that currently assigns quite random accelerators).
> >
> > [With La Carte what you type directly reflects the menu 
> > names themselves: you complete against a menu path (with
> > substring etc. matching, if you use Icicles or Ido etc.).
> >
> > There is nothing arbitrary about what you type.  This helps you
> > learn and remember the menu organization.  You can drill 
> > down the menu hierarchy progressively, as in TMM (but with
> > meaningful input) or you can match your menu target directly.]
> 
> Tmm is for menu navigation, and La Carte is for menu completion.
> I think they both are useful.

Nope.  La Carte is particularly helpful for menu _navigation_, especially if
used together with Icicles (or Ido or...).

If to navigate means to get around, to orient yourself, to see both the trees
and the forest, to see where you are and where you can go and how to get there,
then La Carte beats TMM everytime for navigation.  You can see all or any part
of the menu tree.  You can change the scope of your view of the tree
incrementally (on the fly).

And what you see are the actual menu names and menu-item names - there is no
artificial legend/key/map to refer to, nothing to learn or forget.  You might
call such a legend "accelerators".  And so they can be, but they require an
indirection and learning, at least at first.  And "at first" is always "now" for
at least some parts of the tree (no one is intimately familiar with the entire
tree).  Even if some simple accelerator-naming rules are used, there is still
some learning and some level of arbitrariness to the map/code.

Simple analogy: Imagine that `C-x C-f' did not use the actual file and directory
names, but required you to use a TMM-like UI where you drilled down from the
root each time using single-key codes (~menu accelerators).  Is that a better UI
for navigation?  I don't think so.

To further improve navigation, add to the usual `C-x C-f' (using file names) the
ability to match also directory names (anywhere along the path) and match using
more powerful patterns (multiple substrings or regexps).  That's analogous to La
Carte (+ Icicles or Ido or... for the fancy matching).

Anyway, Uday's point was about menu accelerators, and my reply was that Emacs
has them (XEmacs, Lennart/Windows) or could have them.  And I support it doing
so.

Re: Key bindings proposal

[Juri Linkov]

> Simple analogy: Imagine that `C-x C-f' did not use the actual file and
> directory names, but required you to use a TMM-like UI where you
> drilled down from the root each time using single-key codes (~menu
> accelerators).  Is that a better UI for navigation?

Tmm is a good alternative to binding every command to a key sequence.

When you remember where the command is located in the menu tree,
you can run it by typing its menu accelerators (either in the
graphical menu or in text-based tmm menu) with fewer key strokes
than with completion.

For instance, currently to run `gnus', I need to type `M-x gnus RET'
- 7 keys.

With menu accelerators, the key sequence will be more than twice shorter
- `<f10> t g' ("Tools -> Gnus" menu) - 3 keys.

(And with enabled top-level menu accelerators also 3 keys - `M-t g'.)

> Anyway, Uday's point was about menu accelerators, and my reply was
> that Emacs has them (XEmacs, Lennart/Windows) or could have them.
> And I support it doing so.

IIUC, Windows defines menu accelerators by prepending "~" in front of
the accelerator character in the menu label, Gtk - by prepending "_".
These two are incompatible with each other.

A common Emacs way would be to define a new underlined face and put it
on the accelerator character.  Then menu accelerators will appear
underlined automatically in tmm (but not in Gtk and Windows).

Or more consistent with Emacs menu definitions would be
to use a menu property like `:key-sequence' and `:keys',
e.g. `key-accel':

  (define-key menu-bar-file-menu [write-file]
    `(menu-item ,(purecopy "Save As...") write-file
                :key-accel "A"
                :help ,(purecopy "Write current buffer to another file")))

Re: Key bindings proposal

[Jason Rumney]

  On 27/8/2010 7:22 AM, Juri Linkov wrote:
> IIUC, Windows defines menu accelerators by prepending "~" in front of
> the accelerator character in the menu label, Gtk - by prepending "_".
> These two are incompatible with each other.
>
> A common Emacs way would be to define a new underlined face and put it
> on the accelerator character.  Then menu accelerators will appear
> underlined automatically in tmm (but not in Gtk and Windows).
>
> Or more consistent with Emacs menu definitions would be
> to use a menu property like `:key-sequence' and `:keys',
> e.g. `key-accel':

IIRC, last time we discussed this, we decided that the latter approach 
would be best.  We also considered adopting the GTK approach and 
replacing _ with ~ on windows (and whatever is appropriate on Mac), but 
that leaves lucid and text menus needing to remove the character all the 
time.

Re: Key bindings proposal

[Juri Linkov]

>> Or more consistent with Emacs menu definitions would be
>> to use a menu property like `:key-sequence' and `:keys',
>> e.g. `key-accel':
>
> IIRC, last time we discussed this, we decided that the latter approach
> would be best.  We also considered adopting the GTK approach and replacing
> _ with ~ on windows (and whatever is appropriate on Mac), but that leaves
> lucid and text menus needing to remove the character all the time.

It seems I missed this decision in this overlong thread.

What would be a good scheme for values of `key-accel'?
It could either specify the absolute position of the accelerator
in the menu label string (an integer value like `:key-accel 6'),
or the accelerator itself as a character (like `:key-accel ?A').

Re: Key bindings proposal

[Stefan Monnier]

>> IIRC, last time we discussed this, we decided that the latter approach
>> would be best.  We also considered adopting the GTK approach and replacing
>> _ with ~ on windows (and whatever is appropriate on Mac), but that leaves
>> lucid and text menus needing to remove the character all the time.

> It seems I missed this decision in this overlong thread.

So have I.

> What would be a good scheme for values of `key-accel'?
> It could either specify the absolute position of the accelerator
> in the menu label string (an integer value like `:key-accel 6'),
> or the accelerator itself as a character (like `:key-accel ?A').

Neither sounds good when you think of a possible future addition
of gettext.


        Stefan

Re: Key bindings proposal

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 28 Aug 2010 02:01:52 +0200
> Cc: emacs-devel@gnu.org, Jason Rumney <jasonr@gnu.org>
> 
> > What would be a good scheme for values of `key-accel'?
> > It could either specify the absolute position of the accelerator
> > in the menu label string (an integer value like `:key-accel 6'),
> > or the accelerator itself as a character (like `:key-accel ?A').
> 
> Neither sounds good when you think of a possible future addition
> of gettext.

Yes, I agree.  We need to design a scheme that could support
translatable menu items.

Re: Key bindings proposal

[Stefan Monnier]

>> Neither sounds good when you think of a possible future addition
>> of gettext.
> Yes, I agree.  We need to design a scheme that could support
> translatable menu items.

That basically implies that it has to be part of the text (and not as
a text-property).  So the scheme using an underscore or some such char
seems to be the way to go.
I see two questions left open:
1- which char to use (I'd favor _ since it's what's used in the Free
   toolkit I happen to know).
2- how to deal with breaking backward compatibility (e.g. menus which
   currently include _).


        Stefan

RE: Key bindings proposal

[Drew Adams]

> That basically implies that it has to be part of the text (and not as
> a text-property).  So the scheme using an underscore or some such char
> seems to be the way to go.
> I see two questions left open:
> 1- which char to use (I'd favor _ since it's what's used in the Free
>    toolkit I happen to know).
> 2- how to deal with breaking backward compatibility (e.g. menus which
>    currently include _).

Not really to weigh in here. And I have not been following this with much
attention or interest...

Just a reminder that dynamically generated menus can contain nearly anything. A
buffer name used as a menu item could easily contain `_', as could a function,
class, etc. name used as an Imenu menu item.  Always treating `_' in a name as
an accelerator indicator would be quite limiting and bug-/error-prone, I expect.

Typically for this kind of thing (treating a char as special sometimes but not
always) some char escaping/unescaping mechanism is used.

Jan D. mentioned that `_' could escape an underscore (it does in Gtk+) so that
`__' (2 of them) inhibits acting as an accelerator indication.  But then there
needs to be an unambigous way to specify an underscore itself as an accelerator
char.  Perhaps `___' (3 or them) could (be made to) do that.  How does Gtk+ deal
with this?  In any case, this stuff needs to be well thought out before going
ahead.

I'm glad (and surprised) to see that you are concerned about backward
compatibility here. ;-)  I doubt there is a good way to respect that, however,
if the menu-item text itself is changed.  (But I also agree about the
limitations of using a text property instead of a char.)

If a menu item contains an underscore and there was no intention of indicating
an accelerator, then there is little or nothing to be done - modulo some way to
test the intention (e.g. version of the code that creates the menu item).  I see
no good way to both (a) respect `_' in old code as _not_ meaning anything
special and (b) make `_' (together with an appropriate escape feature) indicate
an accelerator.

3rd-party code will just have to adjust, providing two sets of menu items: one
that works in old Emacs versions (no accelerator indication) and one that works
in new versions.  Ugh.  And code that dynamically generates menu items would
need to be adapted to always DTRT.  Ugh.

It is also true that introducing a new keyword would complicate code that parses
menu items (or keymaps generally).

Re: Key bindings proposal

[Lennart Borgman]

On Mon, Aug 30, 2010 at 5:34 PM, Drew Adams <drew.adams@oracle.com> wrote:
>
> 3rd-party code will just have to adjust, providing two sets of menu items: one
> that works in old Emacs versions (no accelerator indication) and one that works
> in new versions.  Ugh.  And code that dynamically generates menu items would
> need to be adapted to always DTRT.  Ugh.

Can't this be handled something like this:

- Provide a function in Emacs, say `menu-escape-underscore', that does
escaping of underscore so that it is shown as an underscore.

- Test for the presence of this function in external libraries.

RE: Key bindings proposal

[Drew Adams]

> > 3rd-party code will just have to adjust, providing two sets 
> > of menu items: one that works in old Emacs versions (no
> > accelerator indication) and one that works in new versions.
> > Ugh.  And code that dynamically generates menu items would
> > need to be adapted to always DTRT.  Ugh.
> 
> Can't this be handled something like this:
> 
> - Provide a function in Emacs, say `menu-escape-underscore', that does
> escaping of underscore so that it is shown as an underscore.
> 
> - Test for the presence of this function in external libraries.

The point is that legacy 3rd-party code makes no provision for anything.  It
simply includes `_' as an ordinary character.  Either the 3rd-party code must
change to recognize Emacs's different treatment in different versions or the new
Emacs behavior will treat `_' differently from what was intended.

If you mean that new Emacs would use (fboundp 'menu-escape-underscore) and then
handle the menu accordingly, that might make new Emacs DTRT with old 3rd-party
code.  But it would not solve the reverse problem of old Emacs versions handling
code that creates menus that expect the new treatment.

Maybe there is a good, simple solution, but I don't see it yet.

Re: Key bindings proposal

[Lennart Borgman]

On Mon, Aug 30, 2010 at 5:53 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> > 3rd-party code will just have to adjust, providing two sets
>> > of menu items: one that works in old Emacs versions (no
>> > accelerator indication) and one that works in new versions.
>> > Ugh.  And code that dynamically generates menu items would
>> > need to be adapted to always DTRT.  Ugh.
>>
>> Can't this be handled something like this:
>>
>> - Provide a function in Emacs, say `menu-escape-underscore', that does
>> escaping of underscore so that it is shown as an underscore.
>>
>> - Test for the presence of this function in external libraries.
>
> The point is that legacy 3rd-party code makes no provision for anything.  It
> simply includes `_' as an ordinary character.  Either the 3rd-party code must
> change to recognize Emacs's different treatment in different versions or the new
> Emacs behavior will treat `_' differently from what was intended.
>
> If you mean that new Emacs would use (fboundp 'menu-escape-underscore) and then
> handle the menu accordingly, that might make new Emacs DTRT with old 3rd-party
> code.  But it would not solve the reverse problem of old Emacs versions handling
> code that creates menus that expect the new treatment.


No, I meant that 3rd party code must check for this. So yes, third
party code must change, but it is a simple change, something like

  (when (fboundp 'menu-escape-underscore)
      (setq my-menu-txt (menu-escape-underscore my-menu-txt)))


> Maybe there is a good, simple solution, but I don't see it yet.
>
>

Re: Key bindings proposal

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

> But then there needs to be an unambigous way to specify an underscore
> itself as an accelerator char.

I don't think so.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: Key bindings proposal

[Davis Herring]

> But then there needs to be an unambigous way to specify an underscore
> itself as an accelerator char.  Perhaps `___' (3 or them) could (be
> made to) do that.

"___" (with any following character) is already a literal underscore and
an accelerator-prefix, so that doesn't work.  You'd have to have "__U" be
a literal underscore and "__A" be an accelerator underscore (leaving all
other "__?" patterns undefined for future expansion).

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Key bindings proposal

[Jan Djärv]

Davis Herring skrev 2010-08-30 23.39:
>> But then there needs to be an unambigous way to specify an underscore
>> itself as an accelerator char.  Perhaps `___' (3 or them) could (be
>> made to) do that.
>
> "___" (with any following character) is already a literal underscore and
> an accelerator-prefix, so that doesn't work.  You'd have to have "__U" be
> a literal underscore and "__A" be an accelerator underscore (leaving all
> other "__?" patterns undefined for future expansion).
>

Given that Gtk+ has had this limitation for years (_ can not be an 
accelerator) and nobody complained, I don't think it is anything but a 
theoretical problem.  Anybody got a concrete example of an Emacs menu that 
could have _ as accelerator?

	Jan D.

Re: Key bindings proposal

[Lennart Borgman]

On Tue, Aug 31, 2010 at 7:49 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>
> Given that Gtk+ has had this limitation for years (_ can not be an
> accelerator) and nobody complained, I don't think it is anything but a
> theoretical problem.  Anybody got a concrete example of an Emacs menu that
> could have _ as accelerator?

Drew had examples and I suggested a solution to him in this thread.
Please see our messages here.

Re: Key bindings proposal

[Jan Djärv]

Lennart Borgman skrev 2010-08-31 11.54:
> On Tue, Aug 31, 2010 at 7:49 AM, Jan Djärv<jan.h.d@swipnet.se>  wrote:
>>
>> Given that Gtk+ has had this limitation for years (_ can not be an
>> accelerator) and nobody complained, I don't think it is anything but a
>> theoretical problem.  Anybody got a concrete example of an Emacs menu that
>> could have _ as accelerator?
>
> Drew had examples and I suggested a solution to him in this thread.
> Please see our messages here.

I don't understand.  How can you suggest a solution on how to make underscore 
an accelerator when Gtk+ doesn't even support that?  Or are you talking of 
another specific toolkit/port?

	Jan D.

Re: Key bindings proposal

[Lennart Borgman]

On Tue, Aug 31, 2010 at 2:14 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>
>
> Lennart Borgman skrev 2010-08-31 11.54:
>>
>> On Tue, Aug 31, 2010 at 7:49 AM, Jan Djärv<jan.h.d@swipnet.se>  wrote:
>>>
>>> Given that Gtk+ has had this limitation for years (_ can not be an
>>> accelerator) and nobody complained, I don't think it is anything but a
>>> theoretical problem.  Anybody got a concrete example of an Emacs menu
>>> that
>>> could have _ as accelerator?
>>
>> Drew had examples and I suggested a solution to him in this thread.
>> Please see our messages here.
>
> I don't understand.  How can you suggest a solution on how to make
> underscore an accelerator when Gtk+ doesn't even support that?  Or are you
> talking of another specific toolkit/port?


Sorry, my bad. I misread your question.

Re: Key bindings proposal

[Jan Djärv]

Stefan Monnier skrev 2010-08-28 02.01:
>>> IIRC, last time we discussed this, we decided that the latter approach
>>> would be best.  We also considered adopting the GTK approach and replacing
>>> _ with ~ on windows (and whatever is appropriate on Mac), but that leaves
>>> lucid and text menus needing to remove the character all the time.
>
>> It seems I missed this decision in this overlong thread.
>
> So have I.
>
>> What would be a good scheme for values of `key-accel'?
>> It could either specify the absolute position of the accelerator
>> in the menu label string (an integer value like `:key-accel 6'),
>> or the accelerator itself as a character (like `:key-accel ?A').
>
> Neither sounds good when you think of a possible future addition
> of gettext.
>

I know that strings for translations in Gtk+ programs include the _ for 
marking the accelerator, so translators have to choose a new one in their 
languages.  But I don't think this is something to worry about now, as we 
don't even have plans for including gettext yet.

	Jan D.

Re: Key bindings proposal

[Jason Rumney]

  On 28/8/2010 6:38 AM, Juri Linkov wrote:
>> IIRC, last time we discussed this, we decided that the latter approach
>> would be best.  We also considered adopting the GTK approach and replacing
>> _ with ~ on windows (and whatever is appropriate on Mac), but that leaves
>> lucid and text menus needing to remove the character all the time.
> It seems I missed this decision in this overlong thread.

It seems there has been a more recent thread. I was thinking of a thread 
from several years ago.

Re: Key bindings proposal

[Jan Djärv]

Juri Linkov skrev 2010-08-28 00.38:

>
> What would be a good scheme for values of `key-accel'?
> It could either specify the absolute position of the accelerator
> in the menu label string (an integer value like `:key-accel 6'),
> or the accelerator itself as a character (like `:key-accel ?A').

Why no just a text property on the character in question?

	Jan D.

Re: Key bindings proposal

[Jason Rumney]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Juri Linkov skrev 2010-08-28 00.38:
>
>>
>> What would be a good scheme for values of `key-accel'?
>> It could either specify the absolute position of the accelerator
>> in the menu label string (an integer value like `:key-accel 6'),
>> or the accelerator itself as a character (like `:key-accel ?A').
>
> Why no just a text property on the character in question?

Defining menus is already complex enough as it is.

Re: Key bindings proposal

[Jan Djärv]

Jason Rumney skrev 2010-08-28 11.23:
> Jan Djärv<jan.h.d@swipnet.se>  writes:
>
>> Juri Linkov skrev 2010-08-28 00.38:
>>
>>>
>>> What would be a good scheme for values of `key-accel'?
>>> It could either specify the absolute position of the accelerator
>>> in the menu label string (an integer value like `:key-accel 6'),
>>> or the accelerator itself as a character (like `:key-accel ?A').
>>
>> Why no just a text property on the character in question?
>
> Defining menus is already complex enough as it is.
>

Sure, but putting in stuff like :key-accel makes translation harder and you 
have to add lisp and C code to handle it.  Text properties exist now.

It is trivial to make a function that takes for example "_File" and turns this 
into a string with "File" and a text property on F.

	Jan D.

Re: Key bindings proposal

[Jason Rumney]

  On 28/8/2010 5:41 PM, Jan Djärv wrote:

> Sure, but putting in stuff like :key-accel makes translation harder 
> and you have to add lisp and C code to handle it.  Text properties 
> exist now.
>
> It is trivial to make a function that takes for example "_File" and 
> turns this into a string with "File" and a text property on F.

It's not significantly more difficult than a function that replaces both 
the menu text and the :key-accel (or :mnemonic to use the GTK and Motif 
name rather than the MS Windows one) property given the menu item that 
is being translated and the translation string as above.

The interface should be what is easy for the users of the function, not 
what is slightly easier for the person who implements the feature.

Re: Key bindings proposal

[Jan Djärv]

Jason Rumney skrev 2010-08-28 12.13:
> On 28/8/2010 5:41 PM, Jan Djärv wrote:
>
>> Sure, but putting in stuff like :key-accel makes translation harder and you
>> have to add lisp and C code to handle it. Text properties exist now.
>>
>> It is trivial to make a function that takes for example "_File" and turns
>> this into a string with "File" and a text property on F.
>
> It's not significantly more difficult than a function that replaces both the
> menu text and the :key-accel (or :mnemonic to use the GTK and Motif name
> rather than the MS Windows one) property given the menu item that is being
> translated and the translation string as above.
>
> The interface should be what is easy for the users of the function, not what
> is slightly easier for the person who implements the feature.
>

Agreed.  But it is a fundamentally bad design to keep information in two 
places.  Take this:

(define-key menu-bar-file-menu [exit-emacs]
   `(menu-item ,(purecopy "Quit") save-buffers-kill-terminal
	      :key-accel "Q"
               :help ,(purecopy "Save unsaved buffers, then exit")))

Information in two places.  You may think it is not a big deal, but Motif uses 
a similar scheme (a property that is the number of the acceleration 
character).  People has to update in two places.  When changing menu text 
mistakes will be made and :key-accel will be wrong.  I seen this happen in 
Motif apps, it will happen here also.

Keeping the accelerator indication in the string itself:
(define-key menu-bar-file-menu [exit-emacs]
   `(menu-item ,(purecopy "_Quit") save-buffers-kill-terminal
               :help ,(purecopy "Save unsaved buffers, then exit")))

almost guarantees that bad things won't happen.

This is without any translation.  That is a separate matter.  For example, how 
are you going to present the first case to a translator that uses gettext? He 
only sees "Quit" and does not know where the accelerator is or that there 
should be one.  Gettext collects it strings automatically from sources such as 
.el files and does not know about :key-accel.

	Jan D.

Re: Key bindings proposal

[Juri Linkov]

> Keeping the accelerator indication in the string itself:
> (define-key menu-bar-file-menu [exit-emacs]
>   `(menu-item ,(purecopy "_Quit") save-buffers-kill-terminal
>               :help ,(purecopy "Save unsaved buffers, then exit")))

Does this scheme allow to escape underscores (when _ should be part of
the menu item but not as an accelerator)?

Re: Key bindings proposal

[Jan Djärv]

29 aug 2010 kl. 01:16 skrev Juri Linkov <juri@jurta.org>:

>> Keeping the accelerator indication in the string itself:
>> (define-key menu-bar-file-menu [exit-emacs]
>>  `(menu-item ,(purecopy "_Quit") save-buffers-kill-terminal
>>              :help ,(purecopy "Save unsaved buffers, then exit")))
> 
> Does this scheme allow to escape underscores (when _ should be part of
> the menu item but not as an accelerator)?

Two underscores in a row translates to one in Gtk+.

    Jan D.

Re: Key bindings proposal

[David Kastrup]

Jan Djärv <jan.h.d@swipnet.se> writes:

> 29 aug 2010 kl. 01:16 skrev Juri Linkov <juri@jurta.org>:
>
>>> Keeping the accelerator indication in the string itself:
>>> (define-key menu-bar-file-menu [exit-emacs]
>>>  `(menu-item ,(purecopy "_Quit") save-buffers-kill-terminal
>>>              :help ,(purecopy "Save unsaved buffers, then exit")))
>> 
>> Does this scheme allow to escape underscores (when _ should be part of
>> the menu item but not as an accelerator)?
>
> Two underscores in a row translates to one in Gtk+.

In "___Ola", is the accelerator ?_ or ?O ?

-- 
David Kastrup

Re: Key bindings proposal

[Jan Djärv]

David Kastrup skrev 2010-08-29 13.58:
> Jan Djärv<jan.h.d@swipnet.se>  writes:
>
>> 29 aug 2010 kl. 01:16 skrev Juri Linkov<juri@jurta.org>:
>>
>>>> Keeping the accelerator indication in the string itself:
>>>> (define-key menu-bar-file-menu [exit-emacs]
>>>>   `(menu-item ,(purecopy "_Quit") save-buffers-kill-terminal
>>>>               :help ,(purecopy "Save unsaved buffers, then exit")))
>>>
>>> Does this scheme allow to escape underscores (when _ should be part of
>>> the menu item but not as an accelerator)?
>>
>> Two underscores in a row translates to one in Gtk+.
>
> In "___Ola", is the accelerator ?_ or ?O ?

It is ?O.  AFAIK, it isn't possible to make _ an accelerator, i.e parse three 
underscores as _ + __.  It is always taken to be __ + _.


	Jan D.

Re: Key bindings proposal

[Stephen J. Turnbull]

Juri Linkov writes:

 > Does XEmacs bind a key (or key sequences) to access the top-level
 > menu?  I mean something like <f10> or Alt-F (for File menu)?

Yes.  The actual behavior depends on two customizable variables.

`menu-accelerator-enabled'

  Whether menu accelerator keys can cause the menubar to become
  active.  If `menu-force' or `menu-fallback', then menu accelerator
  keys can be used to activate the top level menu.  Once the menubar
  becomes active, the accelerator keys can be used regardless of the
  value of this variable.

  menu-force is used to indicate that the menu accelerator key takes
  precedence over bindings in the current keymap(s).  menu-fallback
  means that bindings in the current keymap take precedence over menu
  accelerator keys.

  Thus a top level menu with an accelerator of "T" would be activated
  on a keypress of Meta-t if menu-accelerator-enabled is menu-force.
  However, if menu-accelerator-enabled is menu-fallback, then Meta-t
  will not activate the menubar and will instead run the function
  transpose-words, to which it is normally bound.

This variable is normally nil.  The other is

`mswindows-alt-by-itself-activates-menu'

  Controls whether pressing and releasing the Alt key activates the menubar.
  This applies only if no intervening key was pressed.  See also
  `menu-accelerator-enabled', which is probably the behavior you actually want.
  Default is t.

This is available only on MS Windows.

Re: Key bindings proposal

[Juri Linkov]

>  > Does XEmacs bind a key (or key sequences) to access the top-level
>  > menu?  I mean something like <f10> or Alt-F (for File menu)?
>
> Yes.  The actual behavior depends on two customizable variables.
>
> `menu-accelerator-enabled'
>
>   Whether menu accelerator keys can cause the menubar to become
>   active.  If `menu-force' or `menu-fallback', then menu accelerator
>   keys can be used to activate the top level menu.  Once the menubar
>   becomes active, the accelerator keys can be used regardless of the
>   value of this variable.

Thanks for the information.

Shouldn't this be part of CUA mode?  If the CUA standard defines this
functionality then probably it should be enabled with CUA mode.

Re: Key bindings proposal

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
> Shouldn't this be part of CUA mode?  If the CUA standard defines this
> functionality then probably it should be enabled with CUA mode.

I think CUA-mode is already way too overloaded and bloated with random
functionality.  To the extent it's possible, it seems far better to have
an independent mode.

-Miles

-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

Re: Key bindings proposal

[Juri Linkov]

>> Shouldn't this be part of CUA mode?  If the CUA standard defines this
>> functionality then probably it should be enabled with CUA mode.
>
> I think CUA-mode is already way too overloaded and bloated with random
> functionality.

And there are no CUA-mode parts that could be shared - there is
no delay between key presses (like cua-prefix-override-inhibit-delay),
and activating the top-level doesn't depend on the region being active
(like in CUA).

The only idea that could be taken from CUA-mode is using the SHIFT key
to override the menu activation.

Actually, this is what Gnome Terminal already does
when "Enable menu access keys" is enabled:

- M-b moves backward one word (since there is no menu with the
  accelerator "B");
- M-f activates the top-level File menu;
- S-M-f moves forward one word.

The same could be implemented in Emacs (not by default, of course).

> To the extent it's possible, it seems far better to have
> an independent mode.

A mode or a variable?  XEmacs just goes with a customizable variable
`menu-accelerator-enabled'.

RE: Key bindings proposal

[Uday S Reddy]

Drew Adams writes:

> #3 is particularly off the wall. (Though it's unclear what you might
> mean by "basic commands".)  Having a command bound by default does
> not prevent anyone from rebinding it to a different key. It is true
> that many commands need not be bound by default, but it is also true
> that many are not bound by default. There is no problem here that
> needs to be solved.

Here is a philosophy that one might take.  We will bind a few crucial
functions to keys because we think they are absolutely essential.
Then we will make available a whole bunch of other functions and a
whole bunch of free keys, so that you can bind them as they suit you.

"Less is more" with this philosophy.  The fewer keys you bind, the
more free keys you give to the user.

Let me give you a concrete instance of the problem I spent some
thought on during the last couple of weeks.  VM has traditionally had
a key binding of `k' to kill-subject, i.e., kill all messages with the
same subject as the current one.  Most people have used it to kill
message threads, because threading didn't work very reliably in the
old days, and so, we went by subject.  Now, I have improved threading
and it works reliably.  So, I raised the idea "can we rebind `k' to
kill-thread instead of kill-subject?"  The answer is, "oh, well, not
quite."  I can bet that 90% of the users 90% of the time will use
kill-thread instead of kill-subject.  But I can't simply disregard the
remaining 10%.  If the old key binding is left alone, then the users
will just habitually type `k' and never discover that there is a
better function now.

If there had not been a built-in key binding for k = kill-subject, and
it was merely a suggestion for users to do the binding themselves, I
could now simply change the suggestion and let the users suit
themselves.  Those users who really need kill-subject will keep the
old binding and the others will switch over.  The whac-a-mole problem
is better solved at the usr end than at our end.

As a developer, I don't feel possessive about key bindings.  I am
quite happy to give the users a blank slate and let them do their own
key bindings.  It is my software that I put my value in.  If the key
bindings get in the way of my users deriving the best value out of my
software, then what purpose has been served?

Cheers,
Uday

Re: Key bindings proposal

[Andreas Schwab]

Juri Linkov <juri@jurta.org> writes:

> Similarly e.g. in Dired, M-x could guess the `dired-' prefix
> for Dired commands, so you could just add `isearch' to run
> `dired-isearch-filenames'.

That's definitely not DWIM.  Just because I happen to visit a dired
buffer does not mean that I want to execute a command starting with
"dired-".  In fact, most commands associated with the current buffer's
major mode are usually on a key, so the command I want to execute with
M-x is more likely _not_ associated with that mode.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Key bindings proposal

[Uday S Reddy]

Juri Linkov writes:

> All in all, is it a conclusion we are leaning towards:
> 
> 1. All commands should have a name designed for M-x completions.
> 2. Most commands should be presented in the main menu.
> 3. Few basic commands should be bound to a key sequence.
> 4. Some of most frequently used command should be added to the toolbar.

Dear Juri, Thanks for an excellent summary and putting the life back
into this thread!

A couple of amendments.  My proposal for 

> 1. All commands should have a name designed for M-x completions.

wasn't actually that M-x should be extended or modified.  Rather, a
prefix key like M-x (say, M-z for argument's sake) would be used for
invoking mode-specific "command names".  Each mode would bind such
command names to actual elisp functions, and this allows us to reuse
the command names in each mode.

So `M-z isearch' can provide isearch through files in dired, isearch
through buffers in buf-menu, isearch through messages in Rmail or Gnus
or VM, etc.  Similarly, you might have commands `M-z next', `M-z
previous', `M-z view', `M-z other-window', `M-z mark', `M-z delete',
`M-z undelete', `M-z execute' and so on.

The key idea is that command names form a *new namespace*, created
explicitly for providing efficient user interaction.  

In addition, my idea also includes:

1a. key bindings can be made to "command names".

This allows the user to create a personal keymap like
  
  n for M-z next
  p for M-z previous
  v for M-z view
  o for M-z other-window
  m for M-z mark
  d for M-z delete
  u for M-z undelete
  x for M-z execute
  ...

and install it in every mode where it might make sense.  This would
save work for configuration and re-skinning.

Note that Stephen Turnbull countered by saying that a lot of this can
already be achieved using the existing elisp technology.  I am not
entirely convinced, but those suggestions need to be explored.

Regarding:

> 2. Most commands should be presented in the main menu.

I don't have a firm view on this.  There is also a case for having
simple menus that are not intimidating.  

But, I think one can probably have the cake and eat it too in this
case.  It is easy enough to install different menus depending on the
user's preference.  A beginner might start with simple menus, and
graduate to bigger ones when he/she wants more.

Regarding the contentious issue:

> 3. Few basic commands should be bound to a key sequence.

we will probably need to continue debating it.  "Less is more" only if
the users can turn it into "more".  If the users have a good
technology for making their own key bindings, then Emacs can ship with
fewer and fewer built-in key bindings.  Or, you can at least detach
the majority of key bindings from standard Emacs and make them
customization packages.

I will be going offline for a few weeks.  I will catch up after I get
back.

Cheers,
Uday

Re: Key bindings proposal

[Juri Linkov]

> Dear Juri, Thanks for an excellent summary and putting the life back
> into this thread!

Since you brought up the key binding `M-s a C-s' (added by yours truly)
as an example of the obsession with key bindings, I feel responsible
for your criticism :-)

> Rather, a prefix key like M-x (say, M-z for argument's sake) would be
> used for invoking mode-specific "command names".  Each mode would bind
> such command names to actual elisp functions, and this allows us to
> reuse the command names in each mode.

I see, we have mode-specific menus and mode-specific key bindings,
but not mode-specific command names for the M-x namespace.

Maybe it should be not just mode-specific but also context-dependent
in a broader sense.  Some programs provide <S-f10> to pop up a context
menu.  So Emacs could provide a separate context menu and corresponding
command namespace and key prefixes.

Re: Key bindings proposal

[Lennart Borgman]

On Sat, Aug 28, 2010 at 12:34 AM, Juri Linkov <juri@jurta.org> wrote:
>
> Maybe it should be not just mode-specific but also context-dependent
> in a broader sense.  Some programs provide <S-f10> to pop up a context
> menu.  So Emacs could provide a separate context menu and corresponding
> command namespace and key prefixes.

I tried to implement something like that in appmenu.el in nXhtml. (It
has changed quite a few times.)

Re: Key bindings proposal

[Juri Linkov]

>> Maybe it should be not just mode-specific but also context-dependent
>> in a broader sense.  Some programs provide <S-f10> to pop up a context
>> menu.  So Emacs could provide a separate context menu and corresponding
>> command namespace and key prefixes.
>
> I tried to implement something like that in appmenu.el in nXhtml. (It
> has changed quite a few times.)

You construct menu items from doc-strings, but much simpler would be
to use normal menu definitions at point (provided that modes will put
them there).

coding guidelines? (was Re: Key bindings proposal)

[Joe Brenner]

Stefan Monnier <monnier@IRO.UMontreal.CA> wrote:

> Using `remap' is one way to express such an intention.
> I would welcome patches that try to make intentions more clear
> (e.g. eliminate the massive hardcoding of the "C-c" prefix all over the
> place) and have myself replaced bindings to TAB and to M-q many times by
> settings of indent-line-function and fill-paragraph-functions.

Rather than hardcoding "C-c", what are we supposed to do?

Are these guidelines documented anywhere?

(The elisp manual is full of examples where "C-c" is hardcoded.)

Re: coding guidelines? (was Re: Key bindings proposal)

[Andreas Schwab]

Joe Brenner <doom@kzsu.stanford.edu> writes:

> Rather than hardcoding "C-c", what are we supposed to do?

mode-specific-map

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

coding guidelines? (was Re: Key bindings proposal)

[Stephen J. Turnbull]

Joe Brenner writes:

 > > I would welcome patches that try to make intentions more clear
 > > (e.g. eliminate the massive hardcoding of the "C-c" prefix all over the

 > Rather than hardcoding "C-c", what are we supposed to do?

Create a separate map and bind it to a single prefix key sequence.
Usually the prefix sequence should also be configurable.  From
footnote.el:

;;;###autoload
(defvar footnote-prefix [(control ?c) ?!]
  "*When not using message mode, the prefix to bind in `mode-specific-map'")

;;;###autoload
(defvar footnote-mode-map nil
  "Keymap used for footnote minor mode.")

;; Set up our keys
;;;###autoload
(unless footnote-mode-map
  (setq footnote-mode-map (make-sparse-keymap))
  (define-key footnote-mode-map "a" 'Footnote-add-footnote)
  (define-key footnote-mode-map "b" 'Footnote-back-to-message)
  (define-key footnote-mode-map "c" 'Footnote-cycle-style)
  (define-key footnote-mode-map "d" 'Footnote-delete-footnote)
  (define-key footnote-mode-map "g" 'Footnote-goto-footnote)
  (define-key footnote-mode-map "r" 'Footnote-renumber-footnotes)
  (define-key footnote-mode-map "s" 'Footnote-set-style))

;;;###autoload
(define-key global-map footnote-prefix footnote-mode-map)

That's not quite verbatim; there's some additional weirdness about
footnote-minor-mode-map that I don't really understand.



 > 
 > Are these guidelines documented anywhere?
 > 
 > (The elisp manual is full of examples where "C-c" is hardcoded.)
 > 

Re: coding guidelines? (was Re: Key bindings proposal)

[Joe Brenner]

Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Joe Brenner writes:

>  > > I would welcome patches that try to make intentions more clear
>  > > (e.g. eliminate the massive hardcoding of the "C-c" prefix all over the
>
>  > Rather than hardcoding "C-c", what are we supposed to do?
>
> Create a separate map and bind it to a single prefix key sequence.
> Usually the prefix sequence should also be configurable.  From
> footnote.el:
>
> ;;;###autoload
> (defvar footnote-prefix [(control ?c) ?!]
>   "*When not using message mode, the prefix to bind in `mode-specific-map'")
>
> ;;;###autoload
> (defvar footnote-mode-map nil
>   "Keymap used for footnote minor mode.")
>
> ;; Set up our keys
> ;;;###autoload
> (unless footnote-mode-map
>   (setq footnote-mode-map (make-sparse-keymap))
>   (define-key footnote-mode-map "a" 'Footnote-add-footnote)
>   (define-key footnote-mode-map "b" 'Footnote-back-to-message)
>   (define-key footnote-mode-map "c" 'Footnote-cycle-style)
>   (define-key footnote-mode-map "d" 'Footnote-delete-footnote)
>   (define-key footnote-mode-map "g" 'Footnote-goto-footnote)
>   (define-key footnote-mode-map "r" 'Footnote-renumber-footnotes)
>   (define-key footnote-mode-map "s" 'Footnote-set-style))
>
> ;;;###autoload
> (define-key global-map footnote-prefix footnote-mode-map)
>
> That's not quite verbatim; there's some additional weirdness about
> footnote-minor-mode-map that I don't really understand.

This is pretty good (and much better than the hacks I was trying to get a
customizeable prefix key), but this puts the new bindings in the global
keymap.

I think what's going on in footnote.el is that they wanted the new
bindings in it's own map which is associated with a new minor mode.

That approach makes a little more sense to me (for my immediate problem,
anyway), but I'm a little puzzled that the minor mode bindings don't go
away when you shut off the minor mode.

Do I need to do something in an after mode hook to cleanup?

Re: coding guidelines? (was Re: Key bindings proposal)

[Joe Brenner]

Joe Brenner <doom@kzsu.stanford.edu> wrote:

> I think what's going on in footnote.el is that they wanted the new
> bindings in it's own map which is associated with a new minor mode.
>
> That approach makes a little more sense to me (for my immediate problem,
> anyway), but I'm a little puzzled that the minor mode bindings don't go
> away when you shut off the minor mode.

Oops, spoke too soon.  I had some cruft in my code that was causing
that problem.  Sorry.