[Top][All Lists]

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

Re: elisp mouse programming problems

From: David Vanderschel
Subject: Re: elisp mouse programming problems
Date: Thu, 21 Aug 2003 01:46:41 GMT

"Alex Schroeder" <address@hidden> wrote in message
> "David Vanderschel" <address@hidden> writes:
> > I am having a problem with overriding the global
> > map ...

> One mouse click will generate not only the mouse
> click event, but also a button-down event.  And if
> somebody binds a command to the button-down event,
> then the command bound to the click event is never
> called.

That is new information for me, but I do not think
that this would not explain why I cannot override

My whole problem is that only certain bindings fail,
and I can't see the difference.

In one failure case, we are talking about C-down-mouse-1.
So I have tried to experiment more with that.  When I
look in my new mode-map, I see the pair:

     (C-down-mouse-1 . dv-test1)

When I do C-h c for C-down-mouse-1, I still get:

     C-down-mouse-1 at that spot runs the command msb

My own major mode mode-map was definitely in effect
(for other things I bound specially) in the buffer in
which I tried that.

> > 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).  (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.)

> The correct solution depends on where the bindings
> are:  Global map?  Local map?  Overlays?  Text
> properties?

The case I am concerned with occurs when the bindings
are in the major mode mode-map which I am working on

  David V.

reply via email to

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