elisp mouse programming problems

elisp mouse programming problems

[David Vanderschel]

I am having a problem with overriding the global map
for some mouse events.  For example, I can bind
C-mouse-1 in a major mode mode-map for a major mode I
created.  Yet when that mode is in effect, such a
mouse click still goes to mouse-select-buffer (as it
is correctly bound globally) and never reaches the
function I bound to the key for the mode.  I do not
have this problem with all mouse events, and I cannot
figure out what is going wrong.  I am consistently
successful in overriding the global binding of
ordinary key sequences (as opposed to mouse events) in
this manner.  Extra details appended.

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.  The old
bindings seem to remain in effect.  If I kill emacs
and restart it, the changed bindings do take effect.
Not even killing the buffer with the new mode,
reloading the file which defines the program, and
rerunning the program which creates the special mode
buffer helps.  What is it that I do not understand
here?

If it matters (which I doubt), I am still running
20.7.3 (on Windows 98).

Thanks for any pointers,
  David V.

______________________________________________________________________

More details:

I have the following code I have been fooling with:

(when (null Hube-mode-map)
  (let ( (m (make-sparse-keymap)) )
    (suppress-keymap m t)
    (define-key m [double-mouse-1] 'Hube-double-mouse-1)
    (define-key m [drag-mouse-1]   'Hube-mouse-1-up)
    (define-key m [drag-mouse-2]   'Hube-mouse-2-up-test)
    (define-key m [C-S-mouse-1]    'Hube-control-mouse-1)
    (define-key m [C-mouse-1]      'Hube-control-mouse-1)
    (define-key m [down-mouse-1]   'Hube-mouse-1-down)
    (define-key m [mouse-1]        'Hube-mouse-1-up)
    (define-key m [mouse-2]        'Hube-mouse-2)
    (define-key m [(control n)]    'dv-test2)
    (setq Hube-mode-map m)
    ))

The bindings which fail to work are those for
C-mouse-1 and drag-mouse-2.  They keep getting handled
by the functions which are bound to them globally.
All the others do work as I expect - and note that
many of them are things which do have standard global
bindings in emacs.  In my initialization, I have
explicitly bound drag-mouse-2 globally to
mouse-drag-throw in mouse-extras.el.  (Used that for
years!)  C-mouse-1 is bound by the msb package which I
use.  I introduced the C-n just to demonstrate that a
"control" modifier was not the source of my apparent
problem.  I also tried to rebind S-mouse-1 and it
persisted in invoking mouse-set-font.  Hube-mode does
not use any other modes.

Re: elisp mouse programming problems

[Alex Schroeder]

"David Vanderschel" <DJV1@Austin.RR.com> writes:

> I am having a problem with overriding the global map
> for some mouse events.  For example, I can bind
> C-mouse-1 in a major mode mode-map for a major mode I
> created.  Yet when that mode is in effect, such a
> mouse click still goes to mouse-select-buffer (as it
> is correctly bound globally) and never reaches the
> function I bound to the key for the mode.  I do not
> have this problem with all mouse events, and I cannot
> figure out what is going wrong.  I am consistently
> successful in overriding the global binding of
> ordinary key sequences (as opposed to mouse events) in
> this manner.  Extra details appended.

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.

See (elisp)Button-Down Events.

> 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.  The old
> bindings seem to remain in effect.  If I kill emacs
> and restart it, the changed bindings do take effect.
> Not even killing the buffer with the new mode,
> reloading the file which defines the program, and
> rerunning the program which creates the special mode
> buffer helps.  What is it that I do not understand
> here?

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

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

Alex.
-- 
http://www.emacswiki.org/alex/
There is no substitute for experience.

Re: elisp mouse programming problems

[David Vanderschel]

"Alex Schroeder" <alex@emacswiki.org> wrote in message
news:873cfwvcqp.fsf@emacswiki.org...
> "David Vanderschel" <DJV1@Austin.RR.com> 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
drag-mouse-2.

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
now.

Thanks,
  David V.

Re: elisp mouse programming problems

[Johan Bockgård]

"David Vanderschel" <DJV1@Austin.RR.com> writes:

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

I think this is relevant, particularly the second paragraph:

(info "(elisp)Active Keymaps")

    All the active keymaps are used together to determine what command
    to execute when a key is entered. Emacs searches these maps one by
    one, in order of decreasing precedence, until it finds a binding
    in one of the maps. The procedure for searching a single keymap is
    called "key lookup"; see *Note Key Lookup::.

    Normally, Emacs first searches for the key in the minor mode maps,
    in the order specified by `minor-mode-map-alist'; if they do not
    supply a binding for the key, Emacs searches the local map; if
    that too has no binding, Emacs then searches the global map.
    However, if `overriding-local-map' is non-`nil', Emacs searches
    that map first, before the global map.

-- 
Johan Bockgård

Re: elisp mouse programming problems

[David Vanderschel]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1528 bytes --]

"Johan Bockgård" <bojohan+news@dd.chalmers.se> wrote in message
news:yoijy8xnspkq.fsf@frealaf.dd.chalmers.se...
> "David Vanderschel" <DJV1@Austin.RR.com> writes:

> > In one failure case, we are talking about
> > C-down-mouse-1. ...

> I think this is relevant, particularly the second paragraph:

> (info "(elisp)Active Keymaps")

>     ...

>     Normally, Emacs first searches for the key in the minor mode maps,
>     in the order specified by `minor-mode-map-alist'; if they do not
>     supply a binding for the key, Emacs searches the local map; if
>     that too has no binding, Emacs then searches the global map.
>     However, if `overriding-local-map' is non-`nil', Emacs searches
>     that map first, before the global map.

Yes, it is very relevant.  I am surprised by the fact
that minor mode maps can override a major mode map.
My problem was that the msb minor mode was enabled and
I had to disable that.  In general, I do not know how
a program like mine would know which of many unknown
possibilities for minor modes might be interfering.  I
would like for other folks to be able to use the
program, but I don't know what minor modes they may
have enabled by default.  Furthermore, it might be
rude to just start arbitrarily disabling _all_ minor
modes on the grounds that they _might_ interfere.

Is there a way for a major mode's binding to take
precedence over any minor modes?  The
overriding-local-map is not overriding enough unless
the above documentation is stated incorrectly.

Regards,
  David V.

Re: elisp mouse programming problems

[Kevin Rodgers]

David Vanderschel wrote:

> "Alex Schroeder" <alex@emacswiki.org> wrote in message
> news:873cfwvcqp.fsf@emacswiki.org...
> 
>>"David Vanderschel" <DJV1@Austin.RR.com> 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

Re: elisp mouse programming problems

[David Vanderschel]

"Kevin Rodgers" <ihs_4664@yahoo.com> wrote in message
news:3F4504F2.60600@yahoo.com...
> David Vanderschel wrote:

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


Then I still do not understand how to get emacs to use
the revised keymap.  For one thing I am not modifying
_the_ keymap - I am creating a new one.  I am sorry if
I am being a bit dense here.  I think the implication
must be that replacing the map pointed to by my
variable still leaves the system with a pointer to the
old cdr.  So are you saying that it is essential to
replace the cdr _in_ the old list, as opposed to
replacing the entire list itself?

Eg., (setf (cdr my-map) (cdr new-map)), as opposed to
(setq my-map new-map).

Why wouldn't invoking use-local-map again also
accomplish the same goal?

Regards,
  David V.

Re: elisp mouse programming problems

[Kevin Rodgers]

David Vanderschel wrote:

> "Kevin Rodgers" <ihs_4664@yahoo.com> wrote in message
> news:3F4504F2.60600@yahoo.com...
> 
>>David Vanderschel wrote:
>>
> 
>>>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.
>>
> 
> 
> Then I still do not understand how to get emacs to use
> the revised keymap.  For one thing I am not modifying
> _the_ keymap - I am creating a new one.


Ah, I didn't realize that.

> I am sorry if
> I am being a bit dense here.  I think the implication
> must be that replacing the map pointed to by my
> variable still leaves the system with a pointer to the
> old cdr.


Sorry, I was the dense one.  You are correct.

> So are you saying that it is essential to
> replace the cdr _in_ the old list, as opposed to
> replacing the entire list itself?
> 
> Eg., (setf (cdr my-map) (cdr new-map)), as opposed to
> (setq my-map new-map).

> 
> Why wouldn't invoking use-local-map again also
> accomplish the same goal?

It would.


-- 
Kevin Rodgers

Re: elisp mouse programming problems

[Eli Zaretskii]

> From: "David Vanderschel" <DJV1@Austin.RR.com>
> Newsgroups: gnu.emacs.help
> Date: Tue, 19 Aug 2003 22:17:22 -0500
> 
> I am having a problem with overriding the global map
> for some mouse events.  For example, I can bind
> C-mouse-1 in a major mode mode-map for a major mode I
> created.  Yet when that mode is in effect, such a
> mouse click still goes to mouse-select-buffer (as it
> is correctly bound globally) and never reaches the
> function I bound to the key for the mode.

Did you try to bind C-down-mouse-1 to the same command?

The Elisp manual has a chapter about mouse events that you may wish to
read.

> The bindings which fail to work are those for
> C-mouse-1 and drag-mouse-2.  They keep getting handled
> by the functions which are bound to them globally.

What does Emacs say when you type "C-h c" followed by one of those two
mouse gestures that fail?

Re: elisp mouse programming problems

[David Vanderschel]

"Eli Zaretskii" <eliz@elta.co.il> wrote in message
news:mailman.542.1061395718.29551.help-gnu-emacs@gnu.org...
> > From: "David Vanderschel" <DJV1@Austin.RR.com>
> > Newsgroups: gnu.emacs.help
> > Date: Tue, 19 Aug 2003 22:17:22 -0500

> > I am having a problem with overriding the global map
> > for some mouse events.  For example, I can bind
> > C-mouse-1 in a major mode mode-map for a major mode I
> > created.  Yet when that mode is in effect, such a
> > mouse click still goes to mouse-select-buffer (as it
> > is correctly bound globally) and never reaches the
> > function I bound to the key for the mode.

> Did you try to bind C-down-mouse-1 to the same command?

I have now.  See my response to Alex.

> The Elisp manual has a chapter about mouse events
> that you may wish to read.

Believe me, I have read it!

> > The bindings which fail to work are those for
> > C-mouse-1 and drag-mouse-2.  They keep getting handled
> > by the functions which are bound to them globally.

> What does Emacs say when you type "C-h c" followed
> by one of those two mouse gestures that fail?

This is awkward with mouse events - since pressing and
releasing a mouse button generates multiple events,
and it may report on an event different from the one I
am concerned with.

However, this did give me a clue which enabled me to
fix my drag-mouse-2.  Even though I did not get a
report on drag-mouse-2, what C-h c did report was:

    down-mouse-2 at that spot runs the command mouse-drag-throw

I suppose that once mouse-drag-throw was running it
took away _my_ drag.  I have now bound down-mouse-2 to
a no op in my mode, and the function I had intended
for drag-mouse-2 now works!  Alex was more nearly
correct on this than I had initially thought.

But I was STILL unable to usurp C-down-mouse-1!  I
have bound a test function to it, and it does not run.
C-h c still says:

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

I have now solved that one too, and the reason was
something which has not been mentioned; but it also
raises a new question.  The problem was that the minor
mode msb was enabling itself in all my buffers (which
is normally OK).  Once I disabled msb-mode in my
special buffer, all was well.  But why would a binding
for a minor mode take precedence when I had attempted
to bind the same event in my major mode?  How can a
general purpose program like I am trying to make know,
in general, which minor modes it must disable in order
to work properly?  I feel that I must still be missing
something here.

Thanks,
  David V.

Re: elisp mouse programming problems

[Alex Schroeder]

"David Vanderschel" <DJV1@Austin.RR.com> writes:

> But why would a binding for a minor mode take precedence when I had
> attempted to bind the same event in my major mode?

I think the reasons are irrelevant, because either precedence makes
sense.  Therefore the Emacs maintainers just had to choose one and
document it.  I guess that they felt that minor modes are somewhat
"more specific" etc., but in truth, it doesn't really matter.

> How can a general purpose program like I am trying to make know, in
> general, which minor modes it must disable in order to work
> properly?  I feel that I must still be missing something here.

I think you have just discovered one of the weaker points in the Emacs
user interface design.  The problem is, nobody knows what to do about
it.  :)  People have even written code to rearrange local keymaps in
order to solve some of these problems, but those are ugly hacks, in my
humble opinion.

The only practical solution is to document it:

  "My mode uses the mouse to achieve certain things -- dragging
  objects, recognizing gestures, etc.  If you are using another minor
  mode that also uses the mouse, then you are in trouble: You will
  either have to disable that other minor mode, or you have to remap
  the conflicting keybindings of that other mode's mode-map.
  Unfortunately it is rather difficult to give better advice than
  this, unless I know exactly what other mode you want to use in
  conjunction with mine."

Something like that.

Alex.
-- 
http://www.emacswiki.org/alex/
There is no substitute for experience.

Re: elisp mouse programming problems

[David Vanderschel]

"Alex Schroeder" <alex@emacswiki.org> wrote in message
news:87y8xnfbip.fsf@emacswiki.org...
> "David Vanderschel" <DJV1@Austin.RR.com> writes:

> > How can a general purpose program like I am trying to make know, in
> > general, which minor modes it must disable in order to work
> > properly?  I feel that I must still be missing something here.

> I think you have just discovered one of the weaker points in the Emacs
> user interface design.  The problem is, nobody knows what to do about
> it.  :)  ...

One possibility that did occur to me last night was
that my program could itself introduce a new minor
mode, invoke it, and do something to assure that its
keymap is at the front of the list.  Then it _could_
override the bindings of other minor modes.  Yet you
did not suggest this solution.  Is there some reason
why it would not work?

Regards,
  David V.

Re: elisp mouse programming problems

[Kevin Rodgers]

David Vanderschel wrote:

> "Alex Schroeder" <alex@emacswiki.org> wrote in message
> news:87y8xnfbip.fsf@emacswiki.org...
> 
>>"David Vanderschel" <DJV1@Austin.RR.com> writes:
>>
> 
>>>How can a general purpose program like I am trying to make know, in
>>>general, which minor modes it must disable in order to work
>>>properly?  I feel that I must still be missing something here.
>>>
> 
>>I think you have just discovered one of the weaker points in the Emacs
>>user interface design.  The problem is, nobody knows what to do about
>>it.  :)  ...
>>
> 
> One possibility that did occur to me last night was
> that my program could itself introduce a new minor
> mode, invoke it, and do something to assure that its
> keymap is at the front of the list.  Then it _could_
> override the bindings of other minor modes.  Yet you
> did not suggest this solution.  Is there some reason
> why it would not work?


Since another minor mode might prepend its (VARIABLE . KEYMPAP) entry to

minor-mode-map-alist later, you would have to continually check and possibly

modify it, perhaps with post-command-hook.  It'd be a bit of a performance hit,
and not very elegant.

-- 
Kevin Rodgers

Re: elisp mouse programming problems

[Kai Großjohann]

"David Vanderschel" <DJV1@Austin.RR.com> writes:

> One possibility that did occur to me last night was that my program
> could itself introduce a new minor mode, invoke it, and do something
> to assure that its keymap is at the front of the list.  Then it
> _could_ override the bindings of other minor modes.  Yet you did not
> suggest this solution.  Is there some reason why it would not work?

Why do you have the right to have the last say?  (Or to come first,
or whatever?)

Why shouldn't super-nifty-mode be allowed to get the event?

See, whatever it might be that people build into Emacs to allow a
mode to say "I'm more important" -- when you have two modes that say
this, you're in trouble.
-- 
Two cafe au lait please, but without milk.

Re: elisp mouse programming problems

[Kai Großjohann]

kai.grossjohann@gmx.net (Kai Großjohann) writes:

> Why do you have the right to have the last say?  (Or to come first,
> or whatever?)

I didn't mean you personally.  I hope you got the meagre attempt at
some humor...  If you didn't, chalk it up to the meagreness, not
yourself :-)
-- 
Two cafe au lait please, but without milk.