* bug#6256: 24.0.50; read-event in `repeat' command
@ 2010-05-24 15:11 Drew Adams
2010-05-24 16:28 ` Drew Adams
0 siblings, 1 reply; 29+ messages in thread
From: Drew Adams @ 2010-05-24 15:11 UTC (permalink / raw)
To: 6256
In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
of 2010-05-23 on G41R2F1
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/xpm/include'
I use popup frames a lot. By default, that is how a buffer gets displayed in my
setup.
I'm also on MS Windows, which has the property that a newly created frame is
always selected (obtains the focus). This means that displaying a buffer is
different, depending on whether its frame already exists. If it does, then the
focus (typically) does not change to the buffer's frame. If it does not, then
the focus moves there. I work around this focus-grabbing annoyance sometimes by
using `select-frame-set-input-focus' at appropriate places. (Ugh!)
Anyway, the problem I have is with the `repeat' command. Presumably,
it tries to be sensitive to actual user events, such as typing a character, but
ignore other, non-user events. This does not work for me in some
cases - an automatic `switch-frame' event is causing it to stop repeating.
I have a command that displays a buffer in its own frame (the same frame or
another, possibly new, frame). I make it repeatable using `repeat', and I bind
it to a key, say `f'. That works fine in general: hitting `f f f...' continues
to display buffers - in new frames or existing frames. No problem.
But in some cases my command also pops up an additional buffer, in another
frame. In those cases the repetition breaks as soon as that second buffer is
displayed. Hitting `f' at that point just inserts an `f' character (in that
buffer if it was selected, else in the first buffer displayed by `f'). It does
not matter whether the second buffer and its frame already exist or not.
I mentioned the frame focus above, but that is apparently not the problem. It
does not matter whether the `f' command opens the first buffer in a new frame or
an existing frame, and likewise for the second buffer. And it does not matter
whether the second buffer is selected (and its frame focused) or not.
It is only when hitting `f' opens also a second buffer that a subsequent `f'
just inserts.
However, if I make a copy of the definition of command `repeat' and change only
its `read-event' to `read-char-exclusive', then the problem goes away. So some
event being read is being tested and found to be different from the `f' last
input event, thus ending the repetition.
I'm guessing that this is what happens: The `read-event' reads the `f' and
repeats the command, which displays the first and second buffers. I would think
there would be a `switch-frame' event associated with each buffer display, but
maybe not. In any case, if there is a `switch-frame' for the first buffer
display it is ignored, but the `switch-frame' for the second buffer display
causes repetition to stop.
It is difficult to use the debugger with `repeat', so I copied the code and
inserted a call to `message' after the `read-event'. It shows clearly that
display of the second buffer causes the event read to be a `switch-frame'.
Do we intentionally use `read-event' here (instead of `read-char-exclusive') in
order to let `repeat' work with other user events besides just char input (e.g.
mouse clicks)? If so, then changing `read-event' to `read-char-exclusive' would
not be the correct fix, but what would? This is not clear to me.
`read-event' has been present in this code since at least Emacs 20, but this
code does not correctly handle `switch-frame' events. Real user events need to
be distinguished from events such as `switch-frame' that can be generated by
code.
Is changing `read-event' to `read-char-exclusive' the proper fix for this bug?
It works for me. If it is not the right fix, then what is?
If it is important for some use reason to keep `read-event', and no fix is found
that would DTRT to distinguish real user events from events such as
`switch-frame', then could we at least use `(funcall repeat-read-function)'
instead of `(read-event)', so that code that wants to be sensitive to only char
events can bind `repeat-read-function' to `read-char-exclusive' around the call
to `repeat'?
The default value of such a var could be `read-event', if that's deemed the best
default, but we at least need some way to make `repeat' ignore non-char events
(if we cannot find a way to make it ignore non-user events).
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#6256: 24.0.50; read-event in `repeat' command
2010-05-24 15:11 bug#6256: 24.0.50; read-event in `repeat' command Drew Adams
@ 2010-05-24 16:28 ` Drew Adams
2010-05-24 23:05 ` Drew Adams
0 siblings, 1 reply; 29+ messages in thread
From: Drew Adams @ 2010-05-24 16:28 UTC (permalink / raw)
To: 6256
> Is changing `read-event' to `read-char-exclusive' the proper
> fix for this bug? It works for me. If it is not the right fix,
> then what is?
>
> If it is important for some use reason to keep `read-event',
> and no fix is found that would DTRT to distinguish real user
> events from events such as `switch-frame', then could we at
> least use `(funcall repeat-read-function)' instead of
> `(read-event)', so that code that wants to be sensitive to
> only char events can bind `repeat-read-function' to
> `read-char-exclusive' around the call to `repeat'?
>
> The default value of such a var could be `read-event', if
> that's deemed the best default, but we at least need some
> way to make `repeat' ignore non-char events
> (if we cannot find a way to make it ignore non-user events).
Actually, I think that using `read-char-exclusive' is the right fix. If the
action were initiated by a mouse event it is unlikely that the next event would
be the same mouse event, so repetition would not occur anyway.
Could you please make this fix: replace the unique occurrence of `read-event' by
`read-char-exclusive' in `repeat'. Thx.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#6256: 24.0.50; read-event in `repeat' command
2010-05-24 16:28 ` Drew Adams
@ 2010-05-24 23:05 ` Drew Adams
2010-05-25 0:06 ` Lennart Borgman
2010-05-25 2:41 ` Stefan Monnier
0 siblings, 2 replies; 29+ messages in thread
From: Drew Adams @ 2010-05-24 23:05 UTC (permalink / raw)
To: 6256
> > Is changing `read-event' to `read-char-exclusive' the proper
> > fix for this bug? It works for me. If it is not the right fix,
> > then what is?
> >
> > If it is important for some use reason to keep `read-event',
> > and no fix is found that would DTRT to distinguish real user
> > events from events such as `switch-frame', then could we at
> > least use `(funcall repeat-read-function)' instead of
> > `(read-event)', so that code that wants to be sensitive to
> > only char events can bind `repeat-read-function' to
> > `read-char-exclusive' around the call to `repeat'?
> >
> > The default value of such a var could be `read-event', if
> > that's deemed the best default, but we at least need some
> > way to make `repeat' ignore non-char events
> > (if we cannot find a way to make it ignore non-user events).
>
> Actually, I think that using `read-char-exclusive' is the
> right fix. If the
> action were initiated by a mouse event it is unlikely that
> the next event would
> be the same mouse event, so repetition would not occur anyway.
>
> Could you please make this fix: replace the unique occurrence
> of `read-event' by `read-char-exclusive' in `repeat'. Thx.
I take it back. `read-char-exclusive' is not the right fix, because not all
keyboard events are character events. Hitting the key `left', for instance,
does not work.
And in fact, I do not seem to be able to reproduce the problem anymore in Emacs
23. (It does occur in Emacs 22.3, however.) Sorry for the noise.
So I guess this bug could be closed. But I still wonder if the code shouldn't
be tweaked somehow to read an event but ignore non-user (or at least
non-keyboard) events. I don't know how to do that.
Before closing, it would be great if someone knowledgable would reply with some
info about the question. Thx.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#6256: 24.0.50; read-event in `repeat' command
2010-05-24 23:05 ` Drew Adams
@ 2010-05-25 0:06 ` Lennart Borgman
2010-05-25 2:41 ` Stefan Monnier
1 sibling, 0 replies; 29+ messages in thread
From: Lennart Borgman @ 2010-05-25 0:06 UTC (permalink / raw)
To: Drew Adams; +Cc: 6256
On Tue, May 25, 2010 at 1:05 AM, Drew Adams <drew.adams@oracle.com> wrote:
>
> So I guess this bug could be closed. But I still wonder if the code shouldn't
> be tweaked somehow to read an event but ignore non-user (or at least
> non-keyboard) events. I don't know how to do that.
After a quick look I guess it does that. However the switch-frame
event is a bit special. The handling of it is delayed in keyboard.c. I
guess what you have seen is the result of that something has gone
wrong because of that (but I am not sure).
Maybe this has been fixed in 23.2?
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#6256: 24.0.50; read-event in `repeat' command
2010-05-24 23:05 ` Drew Adams
2010-05-25 0:06 ` Lennart Borgman
@ 2010-05-25 2:41 ` Stefan Monnier
2010-07-03 21:24 ` Drew Adams
1 sibling, 1 reply; 29+ messages in thread
From: Stefan Monnier @ 2010-05-25 2:41 UTC (permalink / raw)
To: Drew Adams; +Cc: 6256
> I take it back. `read-char-exclusive' is not the right fix, because not all
> keyboard events are character events. Hitting the key `left', for instance,
> does not work.
I think the real answer is that both read-event and read-char-exclusive
are the wrong answer. A better answer would be to have some way to
change the way the next key is handled. Something like
a `next-key-map', kind of like the overriding maps, except that it would
be automatically reset before running a command (and it would not
disable the other keymaps, only take precedence over them).
Basically calling read-event and friends and then putting it back onto
the unread-command-events list is almost always wrong in one way or
another (e.g. it postpones running post-command-hook).
Stefan
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#6256: 24.0.50; read-event in `repeat' command
2010-05-25 2:41 ` Stefan Monnier
@ 2010-07-03 21:24 ` Drew Adams
2010-07-04 22:45 ` Stefan Monnier
2010-09-11 18:25 ` Stefan Monnier
0 siblings, 2 replies; 29+ messages in thread
From: Drew Adams @ 2010-07-03 21:24 UTC (permalink / raw)
To: 'Stefan Monnier'; +Cc: 6256
> > I take it back. `read-char-exclusive' is not the right
> > fix, because not all keyboard events are character events.
> > Hitting the key `left', for instance, does not work.
>
> I think the real answer is that both read-event and
> read-char-exclusive are the wrong answer. A better answer
> would be to have some way to change the way the next key is
> handled. Something like a `next-key-map', kind of like the
> overriding maps, except that it would be automatically reset
> before running a command (and it would not disable the other
> keymaps, only take precedence over them).
>
> Basically calling read-event and friends and then putting it
> back onto the unread-command-events list is almost always
> wrong in one way or another (e.g. it postpones running
> post-command-hook).
I don't really understand the code very well, I admit. You obviously understand
it and have an idea for how to improve things in a big way. It's not clear that
that improvement is soon forthcoming, however. I assume that it might not be
trivial or that you are busy doing other things.
While waiting for the ideal fix, can we at least improve this incrementally to
enable `repeat' to work as I would expect it to wrt, say, mouse events?
For example, suppose I do this:
(defun repeat-command (command)
(let ((repeat-previous-repeated-command command)
(repeat-message-function 'ignore)
(last-repeatable-command 'repeat))
(repeat nil)))
(defun foo-repeat (arg)
(interactive "P")
(repeat-command 'foo))
(define-key my-map (vector (list mouse-wheel-up-event)) 'foo-repeat)
And suppose `my-map' is bound to `C-x p'. I would like for `C-x p' followed by
repeated mouse-wheel-up events to repeat command `foo'.
That does not happen, however, because of this restrictive `eq' test in the
definition of function `repeat':
(while (eq (read-event) repeat-repeat-char)
(repeat repeat-arg))
The event read will be something like this, for the wheel action:
(wheel-down (#<window 8 on foo.el> 2051 (118 . 176) 158455015 nil
2051 (59 . 40) nil (26 . 2) (2 . 4)))
I would think that we would want to change the test to this, or similar:
(while (let ((evt (read-event)))
(and (equal (event-basic-type evt) (event-basic-type
repeat-repeat-char))
(equal (event-modifiers evt) (event-modifiers
repeat-repeat-char))))
(repeat repeat-arg))
And that seems to work OK. What do you think - is it reasonable to do that? It
seems like a win, to me (nothing lost, something gained). But perhaps I'm
missing something.
It seems to me that what we want is to check whether the same user event
occurred, and for complex events such as mouse events we would typically just
want the same event type with the same modifiers.
Please let me know what you think.
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#6256: 24.0.50; read-event in `repeat' command
2010-07-03 21:24 ` Drew Adams
@ 2010-07-04 22:45 ` Stefan Monnier
2010-07-07 14:43 ` Drew Adams
2010-07-21 15:54 ` Drew Adams
2010-09-11 18:25 ` Stefan Monnier
1 sibling, 2 replies; 29+ messages in thread
From: Stefan Monnier @ 2010-07-04 22:45 UTC (permalink / raw)
To: Drew Adams; +Cc: 6256
> That does not happen, however, because of this restrictive `eq' test in the
> definition of function `repeat':
> (while (eq (read-event) repeat-repeat-char)
> (repeat repeat-arg))
> The event read will be something like this, for the wheel action:
> (wheel-down (#<window 8 on foo.el> 2051 (118 . 176) 158455015 nil
> 2051 (59 . 40) nil (26 . 2) (2 . 4)))
> I would think that we would want to change the test to this, or similar:
> (while (let ((evt (read-event)))
> (and (equal (event-basic-type evt) (event-basic-type
> repeat-repeat-char))
> (equal (event-modifiers evt) (event-modifiers
> repeat-repeat-char))))
> (repeat repeat-arg))
> And that seems to work OK. What do you think - is it reasonable to do
> that?
That sounds right, yes,
People, feel free to make such a change,
Stefan
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#6256: 24.0.50; read-event in `repeat' command
2010-07-04 22:45 ` Stefan Monnier
@ 2010-07-07 14:43 ` Drew Adams
2010-07-21 15:54 ` Drew Adams
1 sibling, 0 replies; 29+ messages in thread
From: Drew Adams @ 2010-07-07 14:43 UTC (permalink / raw)
To: 'Stefan Monnier'; +Cc: 6256
> People, feel free to make such a change,
I hope someone will. Thanks.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#6256: 24.0.50; read-event in `repeat' command
2010-07-04 22:45 ` Stefan Monnier
2010-07-07 14:43 ` Drew Adams
@ 2010-07-21 15:54 ` Drew Adams
2010-08-28 15:19 ` Drew Adams
1 sibling, 1 reply; 29+ messages in thread
From: Drew Adams @ 2010-07-21 15:54 UTC (permalink / raw)
To: 'Stefan Monnier'; +Cc: 6256
> From: Stefan Monnier Sent: Sunday, July 04, 2010 3:46 PM
> That sounds right, yes,
> People, feel free to make such a change,
Could someone please commit this change? Thx.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#6256: 24.0.50; read-event in `repeat' command
2010-07-03 21:24 ` Drew Adams
2010-07-04 22:45 ` Stefan Monnier
@ 2010-09-11 18:25 ` Stefan Monnier
2010-09-11 22:34 ` Drew Adams
1 sibling, 1 reply; 29+ messages in thread
From: Stefan Monnier @ 2010-09-11 18:25 UTC (permalink / raw)
To: Drew Adams; +Cc: 6256
> And suppose `my-map' is bound to `C-x p'. I would like for `C-x p'
> followed by repeated mouse-wheel-up events to repeat command `foo'.
> That does not happen, however, because of this restrictive `eq' test in the
> definition of function `repeat':
> (while (eq (read-event) repeat-repeat-char)
> (repeat repeat-arg))
> The event read will be something like this, for the wheel action:
> (wheel-down (#<window 8 on foo.el> 2051 (118 . 176) 158455015 nil
> 2051 (59 . 40) nil (26 . 2) (2 . 4)))
I installed the patch below in the emacs-23 branch (it seemed slightly
safer than your version of the code).
Please confirm that it fixes your problem,
Stefan
=== modified file 'lisp/repeat.el'
--- lisp/repeat.el 2010-01-13 08:35:10 +0000
+++ lisp/repeat.el 2010-09-11 18:20:32 +0000
@@ -335,7 +335,12 @@
(setq real-last-command 'repeat)
(setq repeat-undo-count 1)
(unwind-protect
- (while (eq (read-event) repeat-repeat-char)
+ (while (let ((evt (read-event))) ;FIXME: read-key maybe?
+ ;; For clicks, we need to strip the meta-data to
+ ;; check the underlying event name.
+ (eq (or (car-safe evt) evt)
+ (or (car-safe repeat-repeat-char)
+ repeat-repeat-char)))
(repeat repeat-arg))
;; Make sure `repeat-undo-count' is reset.
(setq repeat-undo-count nil))
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#6256: 24.0.50; read-event in `repeat' command
2010-09-11 18:25 ` Stefan Monnier
@ 2010-09-11 22:34 ` Drew Adams
2010-09-12 16:06 ` Drew Adams
0 siblings, 1 reply; 29+ messages in thread
From: Drew Adams @ 2010-09-11 22:34 UTC (permalink / raw)
To: 'Stefan Monnier'; +Cc: 6256
Thanks for trying, but no, unfortunately it does not work.
I tested your patch using this release:
GNU Emacs 23.2.1 (i386-mingw-nt5.1.2600)
of 2010-05-08 on G41R2F1
And I can confirm that the code I suggested does work.
> From: Stefan Monnier Sent: Saturday, September 11, 2010 11:26 AM
> > And suppose `my-map' is bound to `C-x p'. I would like for `C-x p'
> > followed by repeated mouse-wheel-up events to repeat command `foo'.
>
> > That does not happen, however, because of this restrictive
> > `eq' test in the definition of function `repeat':
>
> > (while (eq (read-event) repeat-repeat-char)
> > (repeat repeat-arg))
>
> > The event read will be something like this, for the wheel action:
> > (wheel-down (#<window 8 on foo.el> 2051 (118 . 176) 158455015 nil
> > 2051 (59 . 40) nil (26 . 2) (2 . 4)))
>
> I installed the patch below in the emacs-23 branch (it seemed slightly
> safer than your version of the code).
> Please confirm that it fixes your problem,
> + (while (let ((evt (read-event))) ;FIXME: read-key maybe?
> + ;; For clicks, we need to strip the meta-data to
> + ;; check the underlying event name.
> + (eq (or (car-safe evt) evt)
> + (or (car-safe repeat-repeat-char)
> + repeat-repeat-char)))
If you want to test for yourself, then:
1. Load the Bookmark+ files (see below).
2. Use C-x p RET at several places in a file to create some bookmarks.
3. Use C-x p <up> <up> <up>... (or <down> <down>...) to cycle among the
bookmarks. You will see a message showing the position at each bookmark
visited.
4. Now try C-x p followed by repeated mouse-wheel down or up movements. You
should see the same movement to each bookmark in turn, and the same position
messages. With your code the wheel repetition does not work. With the code I
sent it does work. This is the `while' condition I sent (again):
(while (let ((evt (read-event)))
(and (equal (event-basic-type evt)
(event-basic-type repeat-repeat-char))
(equal (event-modifiers evt)
(event-modifiers repeat-repeat-char))))
The Bookmark+ files are these (load in this order, after loading std library
bookmark.el):
bookmark+-mac.el
bookmark+-bmu.el
bookmark+-1.el
bookmark+-lit.el
bookmark+.el
You can find the Bookmark+ files here (Emacs Wiki Elisp area):
http://www.emacswiki.org/cgi-bin/wiki?action=index;match=%5C.(el%7Ctar)(%5C.gz)%
3F%24
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#6256: 24.0.50; read-event in `repeat' command
2010-09-11 22:34 ` Drew Adams
@ 2010-09-12 16:06 ` Drew Adams
2010-09-17 3:34 ` Drew Adams
2010-10-18 18:40 ` Stefan Monnier
0 siblings, 2 replies; 29+ messages in thread
From: Drew Adams @ 2010-09-12 16:06 UTC (permalink / raw)
To: 'Stefan Monnier'; +Cc: 6256
> If you want to test for yourself, then:
>
> 1. Load the Bookmark+ files (see below).
Forgot to mention that you will need to uncomment this code in bookmark+-1.el:
;; (define-key bookmark-map (vector (list mouse-wheel-up-event))
;; 'bmkp-next-bookmark-this-buffer-repeat)
;; (define-key bookmark-map (vector (list mouse-wheel-down-event))
;; 'bmkp-previous-bookmark-this-buffer-repeat)
> 2. Use C-x p RET at several places in a file to create some bookmarks.
> 3. Use C-x p <up> <up> <up>... (or <down> <down>...) to cycle
> among the bookmarks. You will see a message showing the position at
> each bookmark visited.
>
> 4. Now try C-x p followed by repeated mouse-wheel down or up
> movements. You should see the same movement to each bookmark
> in turn, and the same position messages. With your code the wheel
> repetition does not work. With the code I sent it does work.
> This is the `while' condition I sent (again):
>
> (while (let ((evt (read-event)))
> (and (equal (event-basic-type evt)
> (event-basic-type repeat-repeat-char))
> (equal (event-modifiers evt)
> (event-modifiers repeat-repeat-char))))
>
> The Bookmark+ files are these (load in this order, after
> loading std library bookmark.el):
>
> bookmark+-mac.el
> bookmark+-bmu.el
> bookmark+-1.el
> bookmark+-lit.el
> bookmark+.el
>
> You can find the Bookmark+ files here (Emacs Wiki Elisp area):
>
http://www.emacswiki.org/cgi-bin/wiki?action=index;match=%5C.(el%7Ctar)(%5C.gz)%
3F%24
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#6256: 24.0.50; read-event in `repeat' command
2010-09-12 16:06 ` Drew Adams
@ 2010-09-17 3:34 ` Drew Adams
2010-09-22 14:01 ` bug#6256: [PATCH] " Drew Adams
2010-10-18 18:40 ` Stefan Monnier
1 sibling, 1 reply; 29+ messages in thread
From: Drew Adams @ 2010-09-17 3:34 UTC (permalink / raw)
To: 'Stefan Monnier'; +Cc: 6256
ping
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#6256: [PATCH] RE: bug#6256: 24.0.50; read-event in `repeat' command
2010-09-17 3:34 ` Drew Adams
@ 2010-09-22 14:01 ` Drew Adams
2010-09-25 14:30 ` Drew Adams
0 siblings, 1 reply; 29+ messages in thread
From: Drew Adams @ 2010-09-22 14:01 UTC (permalink / raw)
To: 'Stefan Monnier'; +Cc: 6256
ping
Please apply the patch (code) I sent (or equivalent that works). Thx.
> From: Drew Adams Sent: Thursday, September 16, 2010 8:34 PM
>
> ping
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#6256: [PATCH] RE: bug#6256: 24.0.50; read-event in `repeat' command
2010-09-22 14:01 ` bug#6256: [PATCH] " Drew Adams
@ 2010-09-25 14:30 ` Drew Adams
0 siblings, 0 replies; 29+ messages in thread
From: Drew Adams @ 2010-09-25 14:30 UTC (permalink / raw)
To: 'Stefan Monnier'; +Cc: 6256
ping.
I sent a fix for this in May 2010. Stefan, you agreed (in July) with the fix I
sent. You said:
"That sounds right, yes. People, feel free to make such a change."
We waited for someone to commit it. No one did. In September you committed a
different "fix" that does not work. Can you please commit the fix I sent, or at
least something equivalent that actually fixes the bug? Thx.
> > > People, feel free to make such a change
> >
> > Could someone please commit this change? Thx.
> > ping
>
> ping
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#6256: 24.0.50; read-event in `repeat' command
2010-09-12 16:06 ` Drew Adams
2010-09-17 3:34 ` Drew Adams
@ 2010-10-18 18:40 ` Stefan Monnier
2010-10-18 21:12 ` Drew Adams
[not found] ` <jwv4ocjuvm1.fsf-monnier+emacs@gnu.org>
1 sibling, 2 replies; 29+ messages in thread
From: Stefan Monnier @ 2010-10-18 18:40 UTC (permalink / raw)
To: Drew Adams; +Cc: 6256
>> If you want to test for yourself, then:
>> 1. Load the Bookmark+ files (see below).
It's not exactly self-contained and going through all those links to
finally download each file is rather inconvenient. So in order to help
me help you, in the future, please try and make it easier. E.g. with
a single download, and then a single load-file.
>> 4. Now try C-x p followed by repeated mouse-wheel down or up
>> movements. You should see the same movement to each bookmark
>> in turn, and the same position messages. With your code the wheel
>> repetition does not work.
Indeed it doesn't work.
>> With the code I sent it does work.
>> This is the `while' condition I sent (again):
>> (while (let ((evt (read-event)))
>> (and (equal (event-basic-type evt)
>> (event-basic-type repeat-repeat-char))
>> (equal (event-modifiers evt)
>> (event-modifiers repeat-repeat-char))))
But that doesn't work either in my tests: the problem is that the
last-command-event was `mouse-4' (i.e. the up event) whereas read-event
returns `down-mouse-4' (a subsequent read-event would return the
`mouse-4').
For my case, replacing the read-event by `read-key' happens to make
it work (see patch below). Please confirm whether or not it fixes it
for you, and if it doesn't, please show me the values of
`repeat-repeat-char' and `evt' in the above test.
Stefan
=== modified file 'lisp/repeat.el'
--- lisp/repeat.el 2010-09-11 18:23:45 +0000
+++ lisp/repeat.el 2010-10-18 18:34:24 +0000
@@ -335,7 +335,7 @@
(setq real-last-command 'repeat)
(setq repeat-undo-count 1)
(unwind-protect
- (while (let ((evt (read-event))) ;FIXME: read-key maybe?
+ (while (let ((evt (read-key)))
;; For clicks, we need to strip the meta-data to
;; check the underlying event name.
(eq (or (car-safe evt) evt)
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#6256: 24.0.50; read-event in `repeat' command
2010-10-18 18:40 ` Stefan Monnier
@ 2010-10-18 21:12 ` Drew Adams
2010-10-19 1:13 ` Stefan Monnier
[not found] ` <jwv4ocjuvm1.fsf-monnier+emacs@gnu.org>
1 sibling, 1 reply; 29+ messages in thread
From: Drew Adams @ 2010-10-18 21:12 UTC (permalink / raw)
To: 'Stefan Monnier'; +Cc: 6256
> >> With the code I sent it does work.
> >> This is the `while' condition I sent (again):
>
> >> (while (let ((evt (read-event)))
> >> (and (equal (event-basic-type evt)
> >> (event-basic-type repeat-repeat-char))
> >> (equal (event-modifiers evt)
> >> (event-modifiers repeat-repeat-char))))
>
> But that doesn't work either in my tests: the problem is that the
> last-command-event was `mouse-4' (i.e. the up event) whereas
> read-event returns `down-mouse-4' (a subsequent read-event would
> return the `mouse-4').
No doubt that is a difference between Emacs on Windows and Emacs on GNU.
BTW, the behavior you describe doesn't really seem very right for a mouse wheel:
Why should the first wheel event be `down-'? I would think that `down-' would
only be called for when you press the mouse wheel (as in mouse-2 clicking using
the wheel). Whatever.
Seems like the Emacs mouse-wheel behavior on Windows (the events) is generally
superior to that on GNU. What about fixing the latter so that it comes up to
speed? Another problem is that it precludes having `mouse-4' and `mouse-5'
correspond to actual mouse buttons. On Windows I can make good use of those
mouse buttons when I use a mouse that has them. Using `mouse-4' and 5 as
stand-ins for the mouse wheel on GNU seems like an ugly workaround/hack. But I
don't know the details/history.
BTW - Don't know if this is related - if not, ignore for this thread, but you
might want to compare my question in emacs-devel wrt an added `<nil>' when using
the wheel in a standalone minibuffer (thread "mouse wheel events - why an extra
<nil>?").
> For my case, replacing the read-event by `read-key' happens to make
> it work (see patch below). Please confirm whether or not it fixes it
> for you, and if it doesn't, please show me the values of
> `repeat-repeat-char' and `evt' in the above test.
> + (while (let ((evt (read-key)))
> ;; For clicks, we need to strip the meta-data to
> ;; check the underlying event name.
> (eq (or (car-safe evt) evt)
Yes, that works for me too. Please install it if you see no problems with it.
Thx.
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#6256: 24.0.50; read-event in `repeat' command
2010-10-18 21:12 ` Drew Adams
@ 2010-10-19 1:13 ` Stefan Monnier
2010-10-19 6:50 ` Jan Djärv
0 siblings, 1 reply; 29+ messages in thread
From: Stefan Monnier @ 2010-10-19 1:13 UTC (permalink / raw)
To: Drew Adams
>> But that doesn't work either in my tests: the problem is that the
>> last-command-event was `mouse-4' (i.e. the up event) whereas
>> read-event returns `down-mouse-4' (a subsequent read-event would
>> return the `mouse-4').
> No doubt that is a difference between Emacs on Windows and Emacs on GNU.
> BTW, the behavior you describe doesn't really seem very right for
> a mouse wheel: Why should the first wheel event be `down-'?
Under X11, wheel-up and wheel-down events are buttons, so they get
pressed&released like any other (actually, it seems to be the case for
the hardware as well, so it's not a complete invention of the X11
layer). I.e. when you turn up the wheel by 3 steps, you get 6 events.
> I would think that `down-' would only be called for when you press the
> mouse wheel (as in mouse-2 clicking using the wheel). Whatever.
You also get such a down in that case, but that's a down-mouse-2 rather
than a down-mouse-4 or down-mouse-5: pressing on the wheel is
a completely different button from "turning the wheel".
> Seems like the Emacs mouse-wheel behavior on Windows (the events) is
> generally superior to that on GNU.
Yes, tho it's mostly not Emacs's fault. X11's handling of wheels is
not great.
> What about fixing the latter so that it comes up to speed?
> Another problem is that it precludes having `mouse-4' and `mouse-5'
> correspond to actual mouse buttons.
That's a general problem under X11, yes. There are various ways to work
around the problem, but it's a source of annoyances. Typically, the
additional buttons will then appear not as mouse-4/5 but for example as
mouse-6,7,8.
>> For my case, replacing the read-event by `read-key' happens to make
>> it work (see patch below). Please confirm whether or not it fixes it
>> for you, and if it doesn't, please show me the values of
>> `repeat-repeat-char' and `evt' in the above test.
>> + (while (let ((evt (read-key)))
>> ;; For clicks, we need to strip the meta-data to
>> ;; check the underlying event name.
>> (eq (or (car-safe evt) evt)
> Yes, that works for me too. Please install it if you see no problems
> with it. Thx.
Thanks, it's installed in emacs-23, closed,
Stefan
^ permalink raw reply [flat|nested] 29+ messages in thread* bug#6256: 24.0.50; read-event in `repeat' command
2010-10-19 1:13 ` Stefan Monnier
@ 2010-10-19 6:50 ` Jan Djärv
2010-10-19 14:03 ` Drew Adams
0 siblings, 1 reply; 29+ messages in thread
From: Jan Djärv @ 2010-10-19 6:50 UTC (permalink / raw)
To: 6256, monnier
2010-10-19 03:13, Stefan Monnier skrev:
> That's a general problem under X11, yes. There are various ways to work
> around the problem, but it's a source of annoyances. Typically, the
> additional buttons will then appear not as mouse-4/5 but for example as
> mouse-6,7,8.
>
If you have a mouse that scrolls horizontally also it comes as mouse 6 and 7.
So extra buttons in that case would be 8, 9, 10 and so on. This makes it
har do make code that uses extra buttons, there is no unique button numbering
between different mouses except 1-5.
Jan D.
^ permalink raw reply [flat|nested] 29+ messages in thread
* bug#6256: 24.0.50; read-event in `repeat' command
2010-10-19 6:50 ` Jan Djärv
@ 2010-10-19 14:03 ` Drew Adams
0 siblings, 0 replies; 29+ messages in thread
From: Drew Adams @ 2010-10-19 14:03 UTC (permalink / raw)
To: 'Jan Djärv', 6256, monnier
> If you have a mouse that scrolls horizontally also it comes
> as mouse 6 and 7.
> So extra buttons in that case would be 8, 9, 10 and so on.
> This makes it hard do make code that uses extra buttons,
> there is no unique button numbering between different
> mouses except 1-5.
Correction: except 1-3, not 1-5 (or is it even just 1-2?).
mouse-4 and mouse-5 on Windows are the 4th and 5th mouse buttons (crazy!, I
know), while on GNU they represent wheel actions.
But apparently there's not much that Emacs can do about this.
(Did I understand that correctly?)
^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <jwv4ocjuvm1.fsf-monnier+emacs@gnu.org>]
end of thread, other threads:[~2010-10-22 19:47 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-05-24 15:11 bug#6256: 24.0.50; read-event in `repeat' command Drew Adams
2010-05-24 16:28 ` Drew Adams
2010-05-24 23:05 ` Drew Adams
2010-05-25 0:06 ` Lennart Borgman
2010-05-25 2:41 ` Stefan Monnier
2010-07-03 21:24 ` Drew Adams
2010-07-04 22:45 ` Stefan Monnier
2010-07-07 14:43 ` Drew Adams
2010-07-21 15:54 ` Drew Adams
2010-08-28 15:19 ` Drew Adams
2010-09-11 18:25 ` Stefan Monnier
2010-09-11 22:34 ` Drew Adams
2010-09-12 16:06 ` Drew Adams
2010-09-17 3:34 ` Drew Adams
2010-09-22 14:01 ` bug#6256: [PATCH] " Drew Adams
2010-09-25 14:30 ` Drew Adams
2010-10-18 18:40 ` Stefan Monnier
2010-10-18 21:12 ` Drew Adams
2010-10-19 1:13 ` Stefan Monnier
2010-10-19 6:50 ` Jan Djärv
2010-10-19 14:03 ` Drew Adams
[not found] ` <jwv4ocjuvm1.fsf-monnier+emacs@gnu.org>
[not found] ` <0658C0CCC79D466BA9DE233F5980CAE5@us.oracle.com>
[not found] ` <jwvpqv7rp50.fsf-monnier+emacs@gnu.org>
2010-10-19 19:21 ` Drew Adams
2010-10-19 20:54 ` Stefan Monnier
2010-10-19 22:17 ` Drew Adams
2010-10-20 15:47 ` Stefan Monnier
2010-10-20 20:55 ` Drew Adams
2010-10-21 1:08 ` Stefan Monnier
2010-10-22 18:43 ` Drew Adams
2010-10-22 19:47 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).