[Top][All Lists]

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

Re: elisp mouse programming problems

From: Kevin Rodgers
Subject: Re: elisp mouse programming problems
Date: Thu, 21 Aug 2003 11:44:18 -0600
User-agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv: Gecko/20020406 Netscape6/6.2.2

David Vanderschel wrote:

"Alex Schroeder" <address@hidden> wrote in message

"David Vanderschel" <address@hidden> writes:

Also, in testing such things, I am confused by the
fact that I cannot seem to redefine the bindings of a
mode-map by simply setting it to nil and rerunning the
(modified) code which builds the mode-map.  ...

A keymap is a list that starts with the symbol `keymap'.
Only the cdr of that list is used by Emacs when
looking up keys.  When you just change the value of a
mode-map, the old cdr will still be used.  (Maybe you
need to draw box diagrams to see this.)

When I said "setting it to nil" I was talking about
the pointer to the list (Hube-mode-map, in my case).
Thus regenerating that list should also generate a new
cdr.  If emacs still has a pointer to the old cdr, I
need to know how to get emacs to give it up.  What
makes it adopt the cdr in the first place?

I think I have now figured this one out.  Changing the
mode-map itself is not sufficient.  You must again
invoke (use-local-map whatever-mode-map).

That is not true.  As Alex explained, when you modify the keymap, you
are modifying a part of its list structure that is shared by the
variable and the mode.

(I had
erroneously believed that what emacs remembered was my
variable which held the pointer to the mode-map and
that it would use the new map when I changed it.  But
there is no quote on the argument, so it cannot know.
I now recall running into another manifestation of
this.  emacs will readily show you the current
mode-map, but it is difficult to discover the 'name'
of that map - ie., the variable used to create it.)

That is true, but it's not relevant.

Kevin Rodgers

reply via email to

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