Re: [CVS] f7, f8 bound..

[Miles Bader <miles@gnu.org>]

On Fri, Sep 06, 2002 at 12:07:51PM +0200, Per Abrahamsen wrote:
> >> With your code, the rules are simle:  If you change a keymap with
> >> customize, all other changes are lost.  With such a simple rule, the
> >> rest of the world can comply.
> >
> > That's obviously a simple rule, but it's also silly and bad; if that's
> > what the current code does, then it's not usable.
> 
> Why "not usable"?  

Because it's `brittle', and makes customize incompatible with with
non-customize use, which is something we want to avoid (well, maybe you don't
want to avoid it, but I do).

The way keymaps are handled, traditionally, is via incremental modification,
not simply `setting' them, and customize should be no different.

In any case, it doesn't really seem that hard to do better -- customize
should only ever add or remove entries from keymaps, not `set the keymap,'
and it should keep track of which ones it did, and only save those when
saving.  One way to do this is just have an alist of (MAP-VAR ADDED DEL'D)
entries (where ADDED and DEL'D are lists of keys).

> Well, it is not usable for the global map, too many packages write to
> that, but packages writing directly to mode maps aren't that common.

The problem is not `packages writing to mode maps,' it's _users_.

Many people set keybindings in mode hooks and the like; sometimes they've
copied that code from other people and don't really understand it.  The
`trash everything' approach obviously messes this up.

The `incremental' approach I mention above is much kinder.

> For the global map, maybe we can get dispensation to use two keymaps.

Not if I can help it.

> > Your two variable solution has a similar problem, BTW -- if
> > e.g. `custom-global-map' overrides `global-map', and someone has bound a
> > key via custom, and tries to re-bind it using `M-x global-set-key' --
> > then his new binding will be effectively ignored!
> 
> True, I haven't though of using non-customize functions interactively.
> They would have had to be modified in order to make the two keymap
> solution a 100% solution.

Are you suggesting they modify the customize keymap too?  In other words all
commands modify _one_ keymap?  In that case you're basically using one
keymap, so why not drop the pretense, and just use one for real?

[Maybe you're suggesting that interactive and `non-interactive' (e.g. invoked
by `M-:') uses of global-set-key work differently, but I think that's
unacceptable.]

The more I think about it, the more I think the two keymap solution is
confusing, both to programmers _and_ users, and that an incremental one
keymap solution (see above) is what we should use.

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.