mouse wheel events - why an extra <nil>?

mouse wheel events - why an extra <nil>?

[Drew Adams]

This is about mouse wheel events, on Windows at least.  (Dunno if it is
platform-dependent, but Emacs on Windows does handle wheel events differently.)

Consider this:

(defcustom foo-keys (list [nil (control wheel-up)] ; A
                          [(control wheel-up)])    ; B
  "..." :type '(repeat sexp))

(dolist (key  foo-keys)
  (define-key minibuffer-local-must-match-map key 'toto))

It seems to be the case that both A and B are needed in order to bind the wheel
action to `toto'.  (And this is so regardless of whether modifiers such as
`control' are present.)

I would have expected only B to be needed.  That is, I would expect the wheel
event/key to always be <C-wheel-up>, but it seems to be the case that: (a) first
it is <nil> <C-wheel-up> and thereafter just <C-wheel-up>.  I don't understand
why.

That is, if only B is defined then the wheel action never calls `toto' - a
message says that <nil> <C-wheel-up> is undefined.  (What is that <nil>?  Where
is it from?)

And if only A is defined then only the first C-wheel-up of a sequence calls
`toto'.  Subsequent C-wheel-ups do nothing - a message says that <C-wheel-up> is
undefined.

This is most clearly seen if <C-wheel-up> is bound in the `global-map' to some
other command, say `titi'.  If B is removed, so the only minibuffer binding for
a C-wheel-up action is (define-key minibuffer-local-must-match-map [nil (control
wheel-up)] 'toto)), then the first C-wheel-up calls `toto' and the second and
subsequent C-wheel-ups call `titi' (the `global-map' binding).

I'd like to understand this.  I don't notice this behavior for a global wheel
binding (i.e., outside the minibuffer).  For instance, repeated C-wheel-ups
always call `titi', and there is no need for an additional global binding to
`titi' of [nil (control wheel-up)] - just binding [(control wheel-up)] suffices.

Is there a bug here perhaps?  If not, can someone please enlighten me as to what
is going on?  The doc regarding mouse events, and wheel events in particular,
does not cover this at all, and the code in mwheel.el is likewise no help here.

(One other bit of info that might be relevant, though I doubt it, is that I'm
using a standalone minibuffer frame.)

RE: mouse wheel events - why an extra <nil>?

[Drew Adams]

> (defcustom foo-keys (list [nil (control wheel-up)] ; A
>                           [(control wheel-up)])    ; B
>   "..." :type '(repeat sexp))

Sorry, I should have used the variables instead of constants, so you can try it
on non-Windows as well:

(defcustom foo-keys
  (list (vector nil (list 'control mouse-wheel-down-event))  ; A
        (vector (list 'control mouse-wheel-down-event))) ; B
  "..." :type '(repeat sexp))

(See the previous mail for the rest.)

Re: mouse wheel events - why an extra <nil>?

[Juri Linkov]

>> (defcustom foo-keys (list [nil (control wheel-up)] ; A
>>                           [(control wheel-up)])    ; B
>>   "..." :type '(repeat sexp))
>
> Sorry, I should have used the variables instead of constants, so you can try it
> on non-Windows as well:

There is no wheel-up on non-Windows.

RE: mouse wheel events - why an extra <nil>?

[Drew Adams]

> >> (defcustom foo-keys (list [nil (control wheel-up)] ; A
> >>                           [(control wheel-up)])    ; B
> >>   "..." :type '(repeat sexp))
> >
> > Sorry, I should have used the variables instead of 
> > constants, so you can try it on non-Windows as well:
> 
> There is no wheel-up on non-Windows.

Correct.  Which is why I used the variables instead, in my followup mail that
you replied to.  You cut out that part of my mail, however - perhaps you did not
see it.  Here it is again:

(defcustom foo-keys
  (list (vector nil (list 'control mouse-wheel-down-event))  ; A
        (vector (list 'control mouse-wheel-down-event))) ; B
  "..." :type '(repeat sexp))

That is not Windows-specific code, unlike what I sent in my first msg.


BTW, I think now that the problem (bug, it seems) arises in particular when
using a standalone minibuffer frame.  My guess is that a frame-switch event or
something like that might somehow be polluting the wheel event that gets
returned, so that that event gets <nil> prepended to it somehow.  With a
standalone minibuffer frame this happens systematically, in the way I described
previously.

It is apparently not Windows-specific however.  A user of my code who does not
use a standalone minibuffer frame and does not use Windows said that he too saw
the error a couple of times: 

 "Some hours ago, I had an error message involving an mouse
  event starting with nil. I can't reproduce it. Never had it
  before, I think.

  [later] After 10 mins hardly trying to provoke it again, I had
  it one more time.  I pressed C-h k and got the message
  "<nil> <down-mouse-5> (translated from <down-mouse-5>) at
  that spot is undefined" with the mouse being over the echo
  area (of course, that's not the mb).  It's not reproducible.
  Maybe it is related to switching frames with the window manager."

On Windows the error message refers to "<nil> <C-wheel-down>".  On his platform
it refers to "<nil> <down-mouse-5>".  He does not have a standalone minibuffer
frame, which is why, I'm guessing, he does not see the error systematically.

I don't have more info than that about this.  Hopefully one of you will be able
to enlighten us all wrt the mysterious <nil> that appears here as part of a
mouse-wheel event but only in some circumstances.  As I mentioned, the doc and
Lisp code regarding the mouse wheel is not much help.