bug#6256: 24.0.50; read-event in `repeat' command

[Stefan Monnier]

> I was thinking that that code would work because it remains abstract (in
> principle).  It just decomposes the event into its components and compares
> those.  There is (in principle) nothing platform-specific about it.

In principle, your message call should have generated a message.
In principle my

    (eq (or (car-safe evt) evt)
        (or (car-safe repeat-repeat-char)
            repeat-repeat-char))

is 100% equivalent (tho more efficient) to your
           
    (and (equal (event-basic-type evt)
                (event-basic-type repeat-repeat-char))
         (equal (event-modifiers evt)
                (event-modifiers repeat-repeat-char))))

But obviously, there's more at play here.

>> That on X11, the second event is *not* the same as the first because
>> mouse wheel send first a down and then an up event.

> I see.  So it sounds like we need an abstraction to deal with that -
> I'd think that would be useful anyway.  After all, there is no good
> reason to distinguish the first wheel rotation (in a given direction).
> At least there is no good reason to _always_ do that, even if someone
> might find a reason why that might be useful sometimes.

[ You're misunderstanding. ]
I know how to deal with the X11 side.  It's dealt with, the code works.
Let's concentrate on your case.  E.g.:

>> You could also try
>>  (while (let ((evt  (read-event)))
>>           (message "EVT: %S, R-R-CHAR: %S" evt repeat-repeat-char)
>>           (and (equal (event-basic-type evt)
>>                       (event-basic-type repeat-repeat-char))
>>                (equal (event-modifiers evt)
>>                       (event-modifiers repeat-repeat-char))))
>>    (repeat repeat-arg))

Or adding the suggested `message' calls before/after read-key or
elsewhere to try and see what are the values of repeat-repeat-char at
various places rather than try and guess them.


        Stefan