emacs-pretest-bug
[Top][All Lists]
Advanced

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

RE: iswitchb-mode and iswitchb-global-map


From: Drew Adams
Subject: RE: iswitchb-mode and iswitchb-global-map
Date: Tue, 2 Jan 2007 23:43:58 -0800

> > > 2. Shouldn't `iswitchb-global-map' be redefined anew each
> > > time `iswitchb-mode' is turned on?
> >
> > Kind of, yes.  I've changed the code to use command remapping
> > instead to get
> > the same kind of result.

I haven't yet given it a try, but I took a quick look at the code. Since
there is no remapping equivalent of the 4th arg to
substitute-key-definition, I suppose that the code now captures whatever the
current bindings of `switch-to-buffer' etc. are, instead of capturing only
their `global-map' bindings. Is that correct?

Maybe that would be a good thing (better), maybe not. I'm not sure - I guess
so. The behavior would be different from before, in any case. Now, the
bindings set up might be different, depending on what they are when the mode
is turned on.

Am I right that the remapping will cause (part of) `iswitchb-global-map' to
be redefined anew each time its keys are looked up? That's even better than
renewing it each time `iswitchb-mode' is turned on, which was what I
proposed (#2).

I'm not too sure how command remapping works. The map is created only once
here, and put onto `minor-mode-map-alist' once and for all, as before. But,
IIUC, the bindings for this in the map are remappings, which are essentially
dynamic bindings. That is, the map itself is static and isn't updated each
time the mode is entered (as I had suggested), but those bindings are always
calculated dynamically, by remapping. If that's how it works, that's pretty
cool. I hadn't thought about remapping that way before: the binding takes
place at the time of key lookup. Very late binding binding ;-).

Another difference from my idea of updating `minor-mode-map-alist' each time
the mode is turned on, and using `substitute-key-definition' with
`global-map', comes from the fact that remapping only works through a single
level. I'm not sure what that would mean in practice, if two or more modes
remap the same commands. Precedence in `minor-mode-map-alist' is what
counts, so there would be a difference in behavior, in any case.

My approach of deleting and reinserting the map in `minor-mode-map-alist'
would give users some flexibility when dealing with "dueling" minor modes:
they could turn two modes on in a particular order to choose which one grabs
contested bindings. Command remapping doesn't allow that, by itself; to get
that effect, I think you would still need to dynamically change the order of
`minor-mode-map-alist'.

Let me know if this makes no sense or I'm missing something. It's late and
I'm tired.






reply via email to

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