emacs-devel
[Top][All Lists]
Advanced

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

Re: Customizing key bindings


From: Alex Schroeder
Subject: Re: Customizing key bindings
Date: Tue, 10 Sep 2002 19:57:27 +0200
User-agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2.90 (i686-pc-linux-gnu)

My code implements #2.  The reason for choosing that approach are
trivial: I don't want to touch the C code, so changing define-key is
out of the question (for me).  Now, if #2 had been difficult to do,
then we would have returned to #1.  But #2 was rather easy to do.
This is why I see no reason to do #1 at the moment.

I realize this is not a real argument.  :)  It just seems more
pragmatic at the moment.

Alex.

Richard Stallman <address@hidden> writes:

>     Another question is `if there the implementation uses two keymaps
>     (either for nesting at lookup time, or just for bookkeeping purposes),
>     where is the second one stored?'  I really dislike your idea of having
>     two separate lisp variable to store them.
>
> In my two-keymap proposal, the second one is found only as the parent
> of the first.  The first is marked somehow as a customization keymap
> so that define-key knows to keep moving and define in its parent.
>
> My two-keymap proposal is #1 below.
>
> ======================================================================
> Here's what I think the :set for a keymap should do.
> Actually, I have two alternative ideas:
>
> 1. Create a new keymap, as above, but make its parent be
> the keymap that was the value of SYM before.  Put the
> symbol `custom' in the keymap to mark it as made here.
>
> If Custom had already run and done this, strip off the
> keymap it made before, and make a new one.
>
> Change define-key so that it skips that keymap and makes the change in
> the parent.
>
> Now all changes made outside Custom will be permanent.  However, the
> bindings specified with Custom will shadow those changes.  In some
> cases the user might not like that, but I don't see that any
> alternative is clearly better.
>
> [In fact, it seems to me that this is more correct than any other
> alternative.]
>
> 2. Instead of making a new keymap, just install the changes in the
> original keymap, saving the original definitions.
>
> More precisely, here's what :set would do:
>
> * Reinstall all the saved original bindings
>
> * For each key that has a Custom key binding,
> save is current binding.
>
> * Install the Custom key bindings.
>
> This way, changes made outside Custom all take effect immediately.
> If the key has no Custom binding, the change is permanent.
> If the key does have a Custom binding, the change is lost when
> Custom runs again, but maybe that is reasonable in this case.




reply via email to

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