emacs-devel
[Top][All Lists]
Advanced

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

Re: Qs on key-description, substitute-command-keys


From: John S. Yates, Jr.
Subject: Re: Qs on key-description, substitute-command-keys
Date: Sat, 15 Oct 2005 14:00:09 -0400

On Sat, 15 Oct 2005 07:54:14 -0400, Stefan Monnier wrote:

> There is no way to get this kind of control.  `substitute-command-keys' has
> some rules such as "prefer a binding using plain ascii keys" (so it'll
> prefer C-x < over C-next, based on the principle that not all terminals have
> a `next' key and even fewer have a way to generate a C-next event) and
> "prefer a shorter binding".

While I can understand the impulse behind this heuristic, it ultimately
seems paternalistic ("we need to prepare you for the great variety of
terminals that you may encounter").

A better approach might be a set of configurable rules that would lead
to a considered choice. 

1) Emacs can usually query the environment to determine the nature of the
keyboard in use.  With this information it can exclude bindings that would
be impossible to produce.  In the same vein, if the menubar is not displayed
there is again no point in suggesting menu bindings.

2) There should be a set of rules.  I imagine an ordered set of predicates.
After applying the hard filtering described above, if more than one binding
survives, develop a per-binding preference strings as follows: apply each
predicate in order; encode each failed predicate as '0', and each successful
predicate as '1'.  Compare the strings lexically. The lexically lowest string
will correspond to the most desirable binding.  (With a limit on the number
of rules an analogous scheme could be implement using bit strings encoded as
integers.)

My hope is that after describing my preferences as a set of rules, emacs
would oblige me by suggesting bindings compatible with my idiosyncrasies.
In particular I would like this to work for new packages that I have not
used before, let alone customized in any fashion.

/john
a users is likely to find 

/john





reply via email to

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