* bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal
2024-03-20 14:29 bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Olaf Rogalsky
@ 2024-03-20 16:43 ` Eli Zaretskii
2024-03-20 18:10 ` Olaf Rogalsky
2024-03-24 19:27 ` Olaf Rogalsky
` (3 subsequent siblings)
4 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2024-03-20 16:43 UTC (permalink / raw)
To: Olaf Rogalsky, Jared Finder; +Cc: 69915
> From: Olaf Rogalsky <olaf.rogalsky@t-online.de>
> Date: Wed, 20 Mar 2024 15:29:33 +0100
>
> when using emacs in the terminal, the mouse-autoselect-window variable
> has no effect, i.e. moving the mouse from one window to the next does
> not change the selected window.
>
> Recipe:
> --- snip ---
> emacs -nw
> M-: (xterm-mouse-mode 1)
> M-: (setq mouse-autoselect-window t)
> C-x 2
> <mouse-motion <<<other window>>> >
> --- snap ---
>
> The reason is, that xt-mouse.el does not generate <select-window>
> events. The following patch fixes that.
Thanks.
> To this end, it also fixes a bug in "window.el". Here, the
> <select-window> event which is added to `last-input-event', does not
> contain a propper posn field. In X11, this works fine, but in the
> terminal it results in a "nil <select-window> is undefined" error.
On an MS-Windows terminal I don't see this problem, so maybe there's
more here than meets the eye?
Anyway, why do you call posn-at-point with first argument nil? I
don't think the position of point in that window is at all relevant,
is it? Should we perhaps use the position derived from mouse-position
instead?
Jared, any comments to this patch?
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal
2024-03-20 16:43 ` Eli Zaretskii
@ 2024-03-20 18:10 ` Olaf Rogalsky
2024-03-21 17:00 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 22+ messages in thread
From: Olaf Rogalsky @ 2024-03-20 18:10 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 69915, Jared Finder
> On an MS-Windows terminal I don't see this problem, so maybe there's
> more here than meets the eye?
Yes, same in X11. I wasn't able to track it down. Maybe it is burried
deep inside of "read_char".
> Anyway, why do you call posn-at-point with first argument nil? I
Because I was lazy and didn't thought, that "the position of point in that
window is at all relevant".
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Olaf Rogalsky <olaf.rogalsky@t-online.de>
>> Date: Wed, 20 Mar 2024 15:29:33 +0100
>>
>> when using emacs in the terminal, the mouse-autoselect-window variable
>> has no effect, i.e. moving the mouse from one window to the next does
>> not change the selected window.
>>
>> Recipe:
>> --- snip ---
>> emacs -nw
>> M-: (xterm-mouse-mode 1)
>> M-: (setq mouse-autoselect-window t)
>> C-x 2
>> <mouse-motion <<<other window>>> >
>> --- snap ---
>>
>> The reason is, that xt-mouse.el does not generate <select-window>
>> events. The following patch fixes that.
>
> Thanks.
>
>> To this end, it also fixes a bug in "window.el". Here, the
>> <select-window> event which is added to `last-input-event', does not
>> contain a propper posn field. In X11, this works fine, but in the
>> terminal it results in a "nil <select-window> is undefined" error.
>
> On an MS-Windows terminal I don't see this problem, so maybe there's
> more here than meets the eye?
>
> Anyway, why do you call posn-at-point with first argument nil? I
> don't think the position of point in that window is at all relevant,
> is it? Should we perhaps use the position derived from mouse-position
> instead?
>
> Jared, any comments to this patch?
--
Olaf Rogalsky
Schwoerhausgasse 5
89073 Ulm
Germany
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal
2024-03-20 18:10 ` Olaf Rogalsky
@ 2024-03-21 17:00 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 22+ messages in thread
From: Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-21 17:00 UTC (permalink / raw)
To: Olaf Rogalsky; +Cc: 69915, Eli Zaretskii
On 2024-03-20 11:10, Olaf Rogalsky wrote:
>> On an MS-Windows terminal I don't see this problem, so maybe there's
>> more here than meets the eye?
> Yes, same in X11. I wasn't able to track it down. Maybe it is burried
> deep inside of "read_char".
I tried this change locally on master without the change to window.el
and everything worked fine for me. Are you certain you need the change
to window.el as well? I'd be very surprised if it is necessary to change
the structure of the <select-window> event to get autoselect to work.
My repro was just:
src/emacs -nw -Q
M-x xterm-mouse-mode
M-x set-variable RET mouse-autoselect-window RET t
C-x 2
C-x 3
Then moving the mouse between the three visible windows.
Is your setup is different somehow?
A few other pieces of feedback (you may find it easier to generate the
events in xterm-mouse-translate-1 to address):
<select-window> events shouldn't be generated while the mouse is being
dragged. This probably is reflected in fully by track-mouse, but I'd
suggest looking at the native code that generates the event to confirm.
If there is a case where two events should be generated (not sure if
this case exists depending on above), we'd want to return both, but you
can only return a single key sequence from the translate function. I
think this case deserves a FIXME note.
Did you try out switching frames? I'm not certain if <select-window> is
supposed to be generated when the frame is switched.
Please name the new internal state variable with prefix "xt-mouse--".
-- MJF
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal
2024-03-20 14:29 bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Olaf Rogalsky
2024-03-20 16:43 ` Eli Zaretskii
@ 2024-03-24 19:27 ` Olaf Rogalsky
2024-03-25 21:53 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-27 21:47 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
` (2 subsequent siblings)
4 siblings, 1 reply; 22+ messages in thread
From: Olaf Rogalsky @ 2024-03-24 19:27 UTC (permalink / raw)
To: Jared Finder; +Cc: 69915, eliz@gnu.org
Hi Jared,
thanks for your feedback (answering this from my gmail account and
hope this doesn't mess up the debbugs history).
> A few other pieces of feedback (you may find it easier to generate the
> events in xterm-mouse-translate-1 to address):
Yes, I think you are right. I refactored my code accordingly, see the new patch
below.
> Are you certain you need the change to window.el as well? I'd be very
> surprised if it is necessary to change
...
> Is your setup is different somehow?
No, but I forgot to mention, that the "nil <select-window> is undefined" error
only occurred, iff mouse-autoselect-window had a numeric value.
With my new patch, the error disappeared. I don't know why, but a
change to window.el
isn't necessary anymore. I still think, that the proposed change would
be correct.
> <select-window> events shouldn't be generated while the mouse is being
> dragged. This probably is reflected in fully by track-mouse, but I'd
> suggest looking at the native code that generates the event to confirm.
Truly understanding xterm.c unfortunately is beyond my expertise. Nevertheless I
tested, the behavior. Dragging the mouse from one window to the next
(while passing over
the modeline) gives the following sequence of events:
ESC [ < 3 5 ; 5 5 ; 4 1 M ESC [ < 0 ; 5 5 ; 4 1 M ;; mouse-drag-region
ESC [ < 3 2 ; 5 5 ; 4 2 M ;; anonymous-command
ESC [ < 3 2 ; 5 5 ; 4 3 M ;; anonymous-command
<help-echo> ESC [ < 3 2 ; 5 5 ; 4 4 M ;; ignore
ESC [ < 3 2 ; 5 6 ; 4 4 M ;; anonymous-command
ESC [ < 0 ; 5 6 ; 4 4 m ;; anonymous-command
<drag-mouse-1> ;; mouse-set-region
So indeed, no select-window event is generated. As a result, dragging
the mouse over the
borders of the window results in a scrolling of the window. This
matches the behavior of the
X11 backend.
> If there is a case where two events should be generated (not sure if
> this case exists depending on above), we'd want to return both, but you
> can only return a single key sequence from the translate function. I
> think this case deserves a FIXME note.
Can't follow you here. At which occasion two events might be generated
and which ones?
> Did you try out switching frames? I'm not certain if <select-window> is
> supposed to be generated when the frame is switched.
Switching frames is not handled in xt-mouse.el. However, if you change
the focus from another
X11 window to the title bar of the terminal or wise-versa, no
switch-frame event is generated. Instead,
xterm-translate-focus-in/xterm-translate-focus-out are called via a
binding in xterm-rxvt-function-map.
These functions toggle the terminal parameter tty-focus-state between
focused and defocused and then
call after-focus-change-function, which also does not generate a
switch-frame event.
As far as I could find out, the X11 backend of emacs doesn't generate
switch-frame events, either.
> Please name the new internal state variable with prefix "xt-mouse--".
I changed it to the terminal parameter xterm-mouse-last-window.
Regards, Olaf
New patch:
diff --git a/lisp/xt-mouse.el b/lisp/xt-mouse.el
index 081b8f32456..8b405262168 100644
--- a/lisp/xt-mouse.el
+++ b/lisp/xt-mouse.el
@@ -60,7 +60,9 @@ xterm-mouse-translate-1
(let* ((event (xterm-mouse-event extension))
(ev-command (nth 0 event))
(ev-data (nth 1 event))
+ (ev-window (nth 0 ev-data))
(ev-where (nth 1 ev-data))
+ (last-window (terminal-parameter nil 'xterm-mouse-last-window))
(vec (vector event))
(is-move (eq 'mouse-movement ev-command))
(is-down (string-match "down-" (symbol-name ev-command))))
@@ -73,6 +75,9 @@ xterm-mouse-translate-1
'mouse-movement
'mouse-click)))
+ ;; remember window of current mouse position
+ (set-terminal-parameter nil 'xterm-mouse-last-window ev-window)
+
(cond
((null event) nil) ;Unknown/bogus byte sequence!
(is-down
@@ -84,10 +89,19 @@ xterm-mouse-translate-1
vec)
(is-move
(xterm-mouse--handle-mouse-movement)
- (if track-mouse vec
- ;; Mouse movement events are currently supposed to be
- ;; suppressed. Return no event.
- []))
+ (if (and mouse-autoselect-window ; after mouse movement
autoselect the mouse window, but ...
+ (windowp ev-window) ; ignore modeline, tab-bar,
menu-bar and so forth ...
+ ;;(not (posn-area (event-start event))) ; also
ignore, if not inside of text area of window ...
+ (not (eq ev-window last-window)) ; but only, if mouse
is over new window ...
+ (not (eq ev-window (selected-window)))) ; which is
different from the selected window
+ (progn
+ (put 'select-window 'event-kind 'switch-frame)
+ (setf (car event) 'select-window)
+ vec)
+ (if track-mouse vec
+ ;; Mouse movement events are currently supposed to be
+ ;; suppressed. Return no event.
+ [])))
(t
(let* ((down (terminal-parameter nil 'xterm-mouse-last-down))
(down-data (nth 1 down))
^ permalink raw reply related [flat|nested] 22+ messages in thread
* bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal
2024-03-24 19:27 ` Olaf Rogalsky
@ 2024-03-25 21:53 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-26 12:31 ` Eli Zaretskii
2024-03-26 23:50 ` Olaf Rogalsky
0 siblings, 2 replies; 22+ messages in thread
From: Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-25 21:53 UTC (permalink / raw)
To: Olaf Rogalsky; +Cc: 69915, eliz
On 2024-03-24 12:27, Olaf Rogalsky wrote:
> Hi Jared,
>
> thanks for your feedback (answering this from my gmail account and
> hope this doesn't mess up the debbugs history).
>
>> Are you certain you need the change to window.el as well? I'd be very
>> surprised if it is necessary to change
> ...
>> Is your setup is different somehow?
> No, but I forgot to mention, that the "nil <select-window> is
> undefined" error
> only occurred, iff mouse-autoselect-window had a numeric value.
> With my new patch, the error disappeared. I don't know why, but a
> change to window.el
> isn't necessary anymore. I still think, that the proposed change would
> be correct.
I'll defer to Eli here, but my general sentiment would be to leave
window.el untouched unless a change is needed. The event list returned
was last changed in 2006 so it's reasonably stable.
>> <select-window> events shouldn't be generated while the mouse is being
>> dragged. This probably is reflected in fully by track-mouse, but I'd
>> suggest looking at the native code that generates the event to
>> confirm.
> Truly understanding xterm.c unfortunately is beyond my expertise.
> Nevertheless I
> tested, the behavior. Dragging the mouse from one window to the next
> (while passing over
> the modeline) gives the following sequence of events:
>
> ESC [ < 3 5 ; 5 5 ; 4 1 M ESC [ < 0 ; 5 5 ; 4 1 M ;; mouse-drag-region
> ESC [ < 3 2 ; 5 5 ; 4 2 M ;; anonymous-command
> ESC [ < 3 2 ; 5 5 ; 4 3 M ;; anonymous-command
> <help-echo> ESC [ < 3 2 ; 5 5 ; 4 4 M ;; ignore
> ESC [ < 3 2 ; 5 6 ; 4 4 M ;; anonymous-command
> ESC [ < 0 ; 5 6 ; 4 4 m ;; anonymous-command
> <drag-mouse-1> ;; mouse-set-region
>
> So indeed, no select-window event is generated. As a result, dragging
> the mouse over the
> borders of the window results in a scrolling of the window. This
> matches the behavior of the
> X11 backend.
Thank you. There's one remaining difference to handle that I highlight
in the diff below.
>> If there is a case where two events should be generated (not sure if
>> this case exists depending on above), we'd want to return both, but
>> you
>> can only return a single key sequence from the translate function. I
>> think this case deserves a FIXME note.
> Can't follow you here. At which occasion two events might be generated
> and which ones?
I was thinking that if both a mouse movement and select window event
should both be returned, like if track-mouse is non-nil and you switch
windows. Can you test this case?
>> Did you try out switching frames? I'm not certain if <select-window>
>> is
>> supposed to be generated when the frame is switched.
> Switching frames is not handled in xt-mouse.el. However, if you change
> the focus from another
> X11 window to the title bar of the terminal or wise-versa, no
> switch-frame event is generated. Instead,
> xterm-translate-focus-in/xterm-translate-focus-out are called via a
> binding in xterm-rxvt-function-map.
> These functions toggle the terminal parameter tty-focus-state between
> focused and defocused and then
> call after-focus-change-function, which also does not generate a
> switch-frame event.
> As far as I could find out, the X11 backend of emacs doesn't generate
> switch-frame events, either.
I was actually referring to using C-x 5 2 and C-x 5 o within a single
terminal. I tested this locally and it works fine.
> New patch:
> ... other parts of patch look good to me :) ...
> @@ -84,10 +89,19 @@ xterm-mouse-translate-1
> vec)
> (is-move
> (xterm-mouse--handle-mouse-movement)
> - (if track-mouse vec
> - ;; Mouse movement events are currently supposed to be
> - ;; suppressed. Return no event.
> - []))
> + (if (and mouse-autoselect-window ; after mouse movement
Style nit: Can you please do this as a cond instead of a nested (if x y
(if z u v))?
> autoselect the mouse window, but ...
> + (windowp ev-window) ; ignore modeline, tab-bar,
> menu-bar and so forth ...
> + ;;(not (posn-area (event-start event))) ; also
> ignore, if not inside of text area of window ...
> + (not (eq ev-window last-window)) ; but only, if mouse
> is over new window ...
> + (not (eq ev-window (selected-window)))) ; which is
> different from the selected window
Looking at xterm.c, I think you also want a test against
window-minibuffer-p.
> + (progn
> + (put 'select-window 'event-kind 'switch-frame)
> + (setf (car event) 'select-window)
> + vec)
I think this should be an event that's just select-window and the
window, to line up with what the select-window event looks like on other
platforms (I tested PGTK and Windows terminal). You can verify this by
running M-x trace-function RET handle-select-window RET.
That would instead be something like:
(progn
(put 'select-window 'event-kind 'switch-frame)
(vector `(select-window (,ev-window)))
Thank you so much for making this patch!
-- MJF
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal
2024-03-25 21:53 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-26 12:31 ` Eli Zaretskii
2024-03-26 23:50 ` Olaf Rogalsky
1 sibling, 0 replies; 22+ messages in thread
From: Eli Zaretskii @ 2024-03-26 12:31 UTC (permalink / raw)
To: Jared Finder; +Cc: olaf.rogalsky, 69915
> Date: Mon, 25 Mar 2024 14:53:15 -0700
> From: Jared Finder <jared@finder.org>
> Cc: eliz@gnu.org, 69915@debbugs.gnu.org
>
> On 2024-03-24 12:27, Olaf Rogalsky wrote:
> > Hi Jared,
> >
> > thanks for your feedback (answering this from my gmail account and
> > hope this doesn't mess up the debbugs history).
> >
> >> Are you certain you need the change to window.el as well? I'd be very
> >> surprised if it is necessary to change
> > ...
> >> Is your setup is different somehow?
> > No, but I forgot to mention, that the "nil <select-window> is
> > undefined" error
> > only occurred, iff mouse-autoselect-window had a numeric value.
> > With my new patch, the error disappeared. I don't know why, but a
> > change to window.el
> > isn't necessary anymore. I still think, that the proposed change would
> > be correct.
>
> I'll defer to Eli here, but my general sentiment would be to leave
> window.el untouched unless a change is needed. The event list returned
> was last changed in 2006 so it's reasonably stable.
I agree.
Olaf, if leaving window.el unchanged causes these errors, please show
a recipe for reproducing it, and let's try to investigate why it
happens, before we decide how to fix it.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal
2024-03-25 21:53 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-26 12:31 ` Eli Zaretskii
@ 2024-03-26 23:50 ` Olaf Rogalsky
1 sibling, 0 replies; 22+ messages in thread
From: Olaf Rogalsky @ 2024-03-26 23:50 UTC (permalink / raw)
To: Jared Finder; +Cc: 69915, eliz
Hi Jared,
> On 2024-03-24 12:27, Olaf Rogalsky wrote:
> > Hi Jared,
> > thanks for your feedback (answering this from my gmail account and
> > hope this doesn't mess up the debbugs history).
> > >> Are you certain you need the change to window.el as well? I'd be
very
> >> surprised if it is necessary to change
> > ...
> >> Is your setup is different somehow?
> > No, but I forgot to mention, that the "nil <select-window> is
undefined" error
> > only occurred, iff mouse-autoselect-window had a numeric value.
> > With my new patch, the error disappeared. I don't know why, but a
> > change to window.el
> > isn't necessary anymore. I still think, that the proposed change would
> > be correct.
>
> I'll defer to Eli here, but my general sentiment would be to leave
window.el untouched unless a change is needed. The event list returned was
last changed in 2006 so it's reasonably stable.
I can't reproduce the error anymore, so I would leave it as is.
> >> <select-window> events shouldn't be generated while the mouse is
being
> >> dragged. This probably is reflected in fully by track-mouse, but I'd
> >> suggest looking at the native code that generates the event to
confirm.
> > Truly understanding xterm.c unfortunately is beyond my expertise.
Nevertheless I
> > tested, the behavior. Dragging the mouse from one window to the next
> > (while passing over
> > the modeline) gives the following sequence of events:
> > ESC [ < 3 5 ; 5 5 ; 4 1 M ESC [ < 0 ; 5 5 ; 4 1 M ;;
mouse-drag-region
> > ESC [ < 3 2 ; 5 5 ; 4 2 M ;; anonymous-command
> > ESC [ < 3 2 ; 5 5 ; 4 3 M ;; anonymous-command
> > <help-echo> ESC [ < 3 2 ; 5 5 ; 4 4 M ;; ignore
> > ESC [ < 3 2 ; 5 6 ; 4 4 M ;; anonymous-command
> > ESC [ < 0 ; 5 6 ; 4 4 m ;; anonymous-command
> > <drag-mouse-1> ;; mouse-set-region
> > So indeed, no select-window event is generated. As a result, dragging
> > the mouse over the
> > borders of the window results in a scrolling of the window. This
> > matches the behavior of the
> > X11 backend.
>
> Thank you. There's one remaining difference to handle that I highlight
in the diff below.
>
> >> If there is a case where two events should be generated (not sure if
> >> this case exists depending on above), we'd want to return both, but
you
> >> can only return a single key sequence from the translate function. I
> >> think this case deserves a FIXME note.
> > Can't follow you here. At which occasion two events might be generated
> > and which ones?
>
> I was thinking that if both a mouse movement and select window event
should both be returned, like if track-mouse is non-nil and you switch
windows. Can you test this case?
Test case 1:
(track-mouse
(setq mouse-autoselect-window t)
(let (e)
(while (not (eq e ?q))
(setq e (read-key))
(when (and (consp e) (symbolp (car e)))
(message "%s to %s at posn %s" (car e) (caadr e) (posn-x-y (cadr
e)))))))
Result with patched terminal:
mouse-movement to #<window 1 on *scratch*> at posn (65 . 40)
mouse-movement to #<window 1 on *scratch*> at posn (65 . 41)
select-window to #<window 4 on *scratch*> at posn (65 . 0)
mouse-movement to #<window 4 on *scratch*> at posn (64 . 0)
mouse-movement to #<window 4 on *scratch*> at posn (64 . 1)
=> select-window event is reported, but at a different posn as the next or
previous mouse-movement. So no simultaneous events for mouse-movement
and select-window.
Result for X11 backend
mouse-movement to #<window 3 on *scratch*> at posn (433 . 983)
mouse-movement to #<window 3 on *scratch*> at posn (432 . 1009)
mouse-movement to #<window 15 on *scratch*> at posn (423 . 0)
mouse-movement to #<window 15 on *scratch*> at posn (420 . 24)
=> no select-window event is reported to read-key at all!
For the second test case I use read-key-sequence instead of read-key
Test case 2:
(track-mouse
(let ((can-return-switch-frame t) e)
(while (not (equal e "q"))
(setq e (read-key-sequence nil nil t can-return-switch-frame nil))
(when (not (stringp e))
(setq e (seq-elt e 0))
(message "%s to %s at posn %s" (car e) (caadr e) (posn-x-y (cadr
e)))))))
Result with patched terminal:
mouse-movement to #<window 1 on *scratch*> at posn (65 . 40)
mouse-movement to #<window 1 on *scratch*> at posn (65 . 41)
select-window to #<window 4 on *scratch*> at posn (65 . 0)
mouse-movement to #<window 4 on *scratch*> at posn (64 . 0)
mouse-movement to #<window 4 on *scratch*> at posn (64 . 1)
=> same as result for test case 1
Result for X11 backend:
mouse-movement to #<window 1 on *scratch*> at posn (43 . 39)
mouse-movement to #<window 1 on *scratch*> at posn (43 . 40)
select-window to #<window 4 on *scratch*> at posn (43 . 0)
mouse-movement to #<window 4 on *scratch*> at posn (43 . 1)
mouse-movement to #<window 4 on *scratch*> at posn (43 . 2)
=> Now a select window event is reported as in the terminal. And also
for X11: no simultaneous events for mouse-movement and select-window.
So, read-key behaves differently in the terminal compared to X11:
In the terminal, the can-return-switch-frame parameter of read-key-sequence
has no effect and select-window events are always generated.
Fyi, the can-return-switch-frame parameter is handled at +10838 keyboard.c
in the monstrous over 1000 lines long function read_key_sequence:
if (EVENT_HAS_PARAMETERS (key)
/* Either a `switch-frame' or a `select-window' event. */
&& EQ (EVENT_HEAD_KIND (EVENT_HEAD (key)), Qswitch_frame))
{
/* If we're at the beginning of a key sequence, and the caller
says it's okay, go ahead and return this event. If we're
in the midst of a key sequence, delay it until the end. */
if (t > 0 || !can_return_switch_frame)
{
delayed_switch_frame = key;
goto replay_key;
}
}
But apparently these lines are never executed in the case of the terminal
input.
> >> Did you try out switching frames? I'm not certain if <select-window>
is
> >> supposed to be generated when the frame is switched.
> > Switching frames is not handled in xt-mouse.el. However, if you change
> > the focus from another
> > X11 window to the title bar of the terminal or wise-versa, no
> > switch-frame event is generated. Instead,
> > xterm-translate-focus-in/xterm-translate-focus-out are called via a
> > binding in xterm-rxvt-function-map.
> > These functions toggle the terminal parameter tty-focus-state between
> > focused and defocused and then
> > call after-focus-change-function, which also does not generate a
> > switch-frame event.
> > As far as I could find out, the X11 backend of emacs doesn't generate
> > switch-frame events, either.
>
> I was actually referring to using C-x 5 2 and C-x 5 o within a single
terminal. I tested this locally and it works fine.
Good!
> > New patch:
> > ... other parts of patch look good to me :) ...
> > @@ -84,10 +89,19 @@ xterm-mouse-translate-1
> > vec)
> > (is-move
> > (xterm-mouse--handle-mouse-movement)
> > - (if track-mouse vec
> > - ;; Mouse movement events are currently supposed to be
> > - ;; suppressed. Return no event.
> > - []))
> > + (if (and mouse-autoselect-window ; after mouse movement
>
> Style nit: Can you please do this as a cond instead of a nested (if x y
(if z u v))?
yes, of cause
> > autoselect the mouse window, but ...
> > + (windowp ev-window) ; ignore modeline, tab-bar,
> > menu-bar and so forth ...
> > + ;;(not (posn-area (event-start event))) ; also
> > ignore, if not inside of text area of window ...
> > + (not (eq ev-window last-window)) ; but only, if mouse
> > is over new window ...
> > + (not (eq ev-window (selected-window)))) ; which is
> > different from the selected window
>
> Looking at xterm.c, I think you also want a test against
window-minibuffer-p.
On the other hand, looking at msdos.c, there is no test against the
minibuffer. I believed, that
the selection of the minibuffer is taken care of at +10638 of window.el. In
my tests the patch
behaves exactly like the documentation, quote: "Mouse auto-selection
selects the minibuffer window
only if it is active, and never deselects the active minibuffer window."
I added the test, but commented it out.
I also commented out a condition, which ensures that the selection of a
window can only occur, if
the mouse is in the text area of the window. This matches the following
sentence of the documentation:
"In either case, the mouse pointer must enter the text area of a window in
order to trigger its selection."
But I found no situation, where it did matter and msdos.c didn't have that
test, either. WDYT?
> > + (progn
> > + (put 'select-window 'event-kind 'switch-frame)
> > + (setf (car event) 'select-window)
> > + vec)
>
> I think this should be an event that's just select-window and the
window, to line up with what the select-window event looks like on other
platforms (I tested PGTK and Windows terminal). You can verify this by
running M-x trace-function RET handle-select-window RET.
>
> That would instead be something like:
>
> (progn
> (put 'select-window 'event-kind 'switch-frame)
> (vector `(select-window (,ev-window)))
I can't find the documentation of the format of the select-window event.
Maybe its a good idea to add it.
Please find below the next iteration of the patch.
Olaf
diff --git a/lisp/xt-mouse.el b/lisp/xt-mouse.el
index 081b8f32456..88c6c28b293 100644
--- a/lisp/xt-mouse.el
+++ b/lisp/xt-mouse.el
@@ -60,7 +60,9 @@ xterm-mouse-translate-1
(let* ((event (xterm-mouse-event extension))
(ev-command (nth 0 event))
(ev-data (nth 1 event))
+ (ev-window (nth 0 ev-data))
(ev-where (nth 1 ev-data))
+ (last-window (terminal-parameter nil 'xterm-mouse-last-window))
(vec (vector event))
(is-move (eq 'mouse-movement ev-command))
(is-down (string-match "down-" (symbol-name ev-command))))
@@ -73,6 +75,9 @@ xterm-mouse-translate-1
'mouse-movement
'mouse-click)))
+ ;; remember window of current mouse position
+ (set-terminal-parameter nil 'xterm-mouse-last-window ev-window)
+
(cond
((null event) nil) ;Unknown/bogus byte sequence!
(is-down
@@ -84,10 +89,16 @@ xterm-mouse-translate-1
vec)
(is-move
(xterm-mouse--handle-mouse-movement)
- (if track-mouse vec
- ;; Mouse movement events are currently supposed to be
- ;; suppressed. Return no event.
- []))
+ (cond ((and mouse-autoselect-window ; after mouse movement
autoselect the mouse window, but ...
+ (windowp ev-window) ; ignore modeline, tab-bar,
menu-bar and so forth ...
+ ;;(not (posn-area (event-start event))) ; also ignore,
if not inside of text area of window ...
+ ;;(not (window-minibuffer-p (selected-window))) ; and
don't deselect the minibuffer
+ (not (eq ev-window last-window)) ; and select only, if
mouse is over a new window ...
+ (not (eq ev-window (selected-window)))) ; which is
different from the selected window
+ (put 'select-window 'event-kind 'switch-frame)
+ (vector `(select-window (,ev-window))))
+ (track-mouse vec)
+ (t [])))
(t
(let* ((down (terminal-parameter nil 'xterm-mouse-last-down))
(down-data (nth 1 down))
^ permalink raw reply related [flat|nested] 22+ messages in thread
* bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal
2024-03-20 14:29 bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Olaf Rogalsky
2024-03-20 16:43 ` Eli Zaretskii
2024-03-24 19:27 ` Olaf Rogalsky
@ 2024-03-27 21:47 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 6:11 ` Eli Zaretskii
2024-03-30 20:18 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <handler.69915.D69915.17123985538558.notifdone@debbugs.gnu.org>
4 siblings, 1 reply; 22+ messages in thread
From: Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-27 21:47 UTC (permalink / raw)
To: Olaf Rogalsky; +Cc: 69915, eliz
On 2024-03-26 16:50, Olaf Rogalsky wrote:
> Hi Jared,
>
>> >> <select-window> events shouldn't be generated while the mouse is being
>> >> dragged. This probably is reflected in fully by track-mouse, but I'd
>> >> suggest looking at the native code that generates the event to confirm.
>> > Truly understanding xterm.c unfortunately is beyond my expertise. Nevertheless I
>> > tested, the behavior. Dragging the mouse from one window to the next
>> > (while passing over
>> > the modeline) gives the following sequence of events:
... elided comments ...
>> > Can't follow you here. At which occasion two events might be generated
>> > and which ones?
>> > I was thinking that if both a mouse movement and select window event should both be returned, like if track-mouse is non-nil and you switch windows. Can you test this case?
>
> Test case 1:
> (track-mouse
> (setq mouse-autoselect-window t)
>
> (let (e)
> (while (not (eq e ?q))
> (setq e (read-key))
> (when (and (consp e) (symbolp (car e)))
> (message "%s to %s at posn %s" (car e) (caadr e) (posn-x-y
> (cadr e)))))))
>
> Result with patched terminal:
... elided results ...
>
> For the second test case I use read-key-sequence instead of read-key
>
> Test case 2:
>
> (track-mouse
> (let ((can-return-switch-frame t) e)
> (while (not (equal e "q"))
> (setq e (read-key-sequence nil nil t can-return-switch-frame
> nil))
> (when (not (stringp e))
> (setq e (seq-elt e 0))
> (message "%s to %s at posn %s" (car e) (caadr e) (posn-x-y
> (cadr e)))))))
>
> Result with patched terminal:
... elided results ...
>
> So, read-key behaves differently in the terminal compared to X11:
> In the terminal, the can-return-switch-frame parameter of
> read-key-sequence
> has no effect and select-window events are always generated.
>
> Fyi, the can-return-switch-frame parameter is handled at +10838
> keyboard.c
> in the monstrous over 1000 lines long function read_key_sequence:
>
> if (EVENT_HAS_PARAMETERS (key)
> /* Either a `switch-frame' or a `select-window' event. */
> && EQ (EVENT_HEAD_KIND (EVENT_HEAD (key)), Qswitch_frame))
> {
> /* If we're at the beginning of a key sequence, and the caller
> says it's okay, go ahead and return this event. If we're
> in the midst of a key sequence, delay it until the end. */
> if (t > 0 || !can_return_switch_frame)
> {
> delayed_switch_frame = key;
> goto replay_key;
> }
> }
> But apparently these lines are never executed in the case of the
> terminal input.
Sadly, read_key_sequence in C code is quite a beast.
One last experiment is worth trying here. If this doesn't work out, I
think a FIXME will be sufficient. Instead of returning the
<select-window> event, try pushing the <select-window> event onto
unread-command-events. My thought is that this will let native code
dequeue and handle the event normally, including taking
can_return_switch_frame into account. Can you please try this?
>> > autoselect the mouse window, but ...
>> > + (windowp ev-window) ; ignore modeline, tab-bar,
>> > menu-bar and so forth ...
>> > + ;;(not (posn-area (event-start event))) ; also
>> > ignore, if not inside of text area of window ...
>> > + (not (eq ev-window last-window)) ; but only, if mouse
>> > is over new window ...
>> > + (not (eq ev-window (selected-window)))) ; which is
>> > different from the selected window
>> > Looking at xterm.c, I think you also want a test against window-minibuffer-p.
>
> On the other hand, looking at msdos.c, there is no test against the
> minibuffer. I believed, that
> the selection of the minibuffer is taken care of at +10638 of
> window.el. In my tests the patch
> behaves exactly like the documentation, quote: "Mouse auto-selection
> selects the minibuffer window
> only if it is active, and never deselects the active minibuffer
> window."
> I added the test, but commented it out.
I'm not sure what the right way to proceed here is then. Eli, can you
give advice?
Looking at different OS files that handle mouse_autoselect_window, I see
the following state for checks if the selected window is a minibuffer
with MINI_WINDOW_P:
pgtkterm.c: checks
w32term.c: does NOT check
w32inevt.c: does NOT check
nsterm.m: checks
xterm.c: checks
msdos.c: does NOT check
haikuterm.c: checks
androidterm.c: checks
term.c: no support for mouse-autoselect-window. :(
My gut is to assume that the X and GTK behavior is most likely to be
better tested and more correct, but I defer to Eli here.
> I also commented out a condition, which ensures that the selection of a
> window can only occur, if the mouse is in the text area of the window.
> This matches the following sentence of the documentation:
> "In either case, the mouse pointer must enter the text area of a window
> in order to trigger its selection."
> But I found no situation, where it did matter and msdos.c didn't have
> that test, either. WDYT?
I think the documentation is incorrect and this commented out case
should be removed. Local testing on PGTK and Mac shows that the mouse
pointer can be over the window dividers, widget scroll bars, or fringes
and still have autoselect behavior activate.
>> > + (progn
>> > + (put 'select-window 'event-kind 'switch-frame)
>> > + (setf (car event) 'select-window)
>> > + vec)
>> > I think this should be an event that's just select-window and the window, to line up with what the select-window event looks like on other platforms (I tested PGTK and Windows terminal). You can verify this by running M-x trace-function RET handle-select-window RET.
>> > That would instead be something like:
>> > (progn
>> (put 'select-window 'event-kind 'switch-frame)
>> (vector `(select-window (,ev-window)))
>
> I can't find the documentation of the format of the select-window
> event. Maybe its a good idea to add it.
Agreed. I think it should be added to Focus Events in commands.texi.
> Please find below the next iteration of the patch.
Assuming above comments are addressed, this looks good to me. I imagine
there will be minor comment reformatting to avoid going beyond 80
columns.
> diff --git a/lisp/xt-mouse.el b/lisp/xt-mouse.el
> index 081b8f32456..88c6c28b293 100644
> --- a/lisp/xt-mouse.el
> +++ b/lisp/xt-mouse.el
> @@ -60,7 +60,9 @@ xterm-mouse-translate-1
> (let* ((event (xterm-mouse-event extension))
> (ev-command (nth 0 event))
> (ev-data (nth 1 event))
> + (ev-window (nth 0 ev-data))
> (ev-where (nth 1 ev-data))
> + (last-window (terminal-parameter nil
> 'xterm-mouse-last-window))
> (vec (vector event))
> (is-move (eq 'mouse-movement ev-command))
> (is-down (string-match "down-" (symbol-name ev-command))))
> @@ -73,6 +75,9 @@ xterm-mouse-translate-1
> 'mouse-movement
> 'mouse-click)))
>
> + ;; remember window of current mouse position
> + (set-terminal-parameter nil 'xterm-mouse-last-window ev-window)
> +
> (cond
> ((null event) nil) ;Unknown/bogus byte sequence!
> (is-down
> @@ -84,10 +89,16 @@ xterm-mouse-translate-1
> vec)
> (is-move
> (xterm-mouse--handle-mouse-movement)
> - (if track-mouse vec
> - ;; Mouse movement events are currently supposed to be
> - ;; suppressed. Return no event.
> - []))
> + (cond ((and mouse-autoselect-window ; after mouse movement
> autoselect the mouse window, but ...
> + (windowp ev-window) ; ignore modeline, tab-bar,
> menu-bar and so forth ...
> + ;;(not (posn-area (event-start event))) ; also
> ignore, if not inside of text area of window ...
> + ;;(not (window-minibuffer-p (selected-window))) ;
> and don't deselect the minibuffer
> + (not (eq ev-window last-window)) ; and select
> only, if mouse is over a new window ...
> + (not (eq ev-window (selected-window)))) ; which is
> different from the selected window
> + (put 'select-window 'event-kind 'switch-frame)
> + (vector `(select-window (,ev-window))))
> + (track-mouse vec)
> + (t [])))
> (t
> (let* ((down (terminal-parameter nil 'xterm-mouse-last-down))
> (down-data (nth 1 down))
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal
2024-03-27 21:47 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-28 6:11 ` Eli Zaretskii
2024-03-28 14:41 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-30 17:03 ` Olaf Rogalsky
0 siblings, 2 replies; 22+ messages in thread
From: Eli Zaretskii @ 2024-03-28 6:11 UTC (permalink / raw)
To: Jared Finder; +Cc: olaf.rogalsky, 69915
> Date: Wed, 27 Mar 2024 14:47:27 -0700
> From: Jared Finder <jared@finder.org>
> Cc: eliz@gnu.org, 69915@debbugs.gnu.org
>
> > On the other hand, looking at msdos.c, there is no test against
> > the minibuffer. I believed, that the selection of the minibuffer
> > is taken care of at +10638 of window.el. In my tests the patch
> > behaves exactly like the documentation, quote: "Mouse
> > auto-selection selects the minibuffer window only if it is active,
> > and never deselects the active minibuffer window." I added the
> > test, but commented it out.
>
> I'm not sure what the right way to proceed here is then. Eli, can you
> give advice?
>
> Looking at different OS files that handle mouse_autoselect_window, I see
> the following state for checks if the selected window is a minibuffer
> with MINI_WINDOW_P:
>
> pgtkterm.c: checks
> w32term.c: does NOT check
> w32inevt.c: does NOT check
> nsterm.m: checks
> xterm.c: checks
> msdos.c: does NOT check
> haikuterm.c: checks
> androidterm.c: checks
> term.c: no support for mouse-autoselect-window. :(
>
> My gut is to assume that the X and GTK behavior is most likely to be
> better tested and more correct, but I defer to Eli here.
I tend to agree. But, just to be sure, can you or Olaf describe the
exact issue and how it could happen, and perhaps show a recipe to try
reproducing it? I'd like to take a closer look at the relevant code.
> > I also commented out a condition, which ensures that the selection of a
> > window can only occur, if the mouse is in the text area of the window.
> > This matches the following sentence of the documentation:
> > "In either case, the mouse pointer must enter the text area of a window
> > in order to trigger its selection."
> > But I found no situation, where it did matter and msdos.c didn't have
> > that test, either. WDYT?
>
> I think the documentation is incorrect and this commented out case
> should be removed. Local testing on PGTK and Mac shows that the mouse
> pointer can be over the window dividers, widget scroll bars, or fringes
> and still have autoselect behavior activate.
Is this at all relevant for TTY frames? Everything is "text area" on
TTY frames, right? If not, what are the use cases where the mouse
would be "not in the text area" on a TTY frame, in the context of
auto-selecting a window?
> >> > + (progn
> >> > + (put 'select-window 'event-kind 'switch-frame)
> >> > + (setf (car event) 'select-window)
> >> > + vec)
> >> > I think this should be an event that's just select-window and the window, to line up with what the select-window event looks like on other platforms (I tested PGTK and Windows terminal). You can verify this by running M-x trace-function RET handle-select-window RET.
> >> > That would instead be something like:
> >> > (progn
> >> (put 'select-window 'event-kind 'switch-frame)
> >> (vector `(select-window (,ev-window)))
> >
> > I can't find the documentation of the format of the select-window
> > event. Maybe its a good idea to add it.
>
> Agreed. I think it should be added to Focus Events in commands.texi.
I agree.
> > Please find below the next iteration of the patch.
>
> Assuming above comments are addressed, this looks good to me. I imagine
> there will be minor comment reformatting to avoid going beyond 80
> columns.
Thanks, please post the final version after these minor changes for
review.
Thanks.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal
2024-03-28 6:11 ` Eli Zaretskii
@ 2024-03-28 14:41 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-31 8:58 ` Eli Zaretskii
2024-03-30 17:03 ` Olaf Rogalsky
1 sibling, 1 reply; 22+ messages in thread
From: Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-28 14:41 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: olaf.rogalsky, 69915
On 2024-03-27 23:11, Eli Zaretskii wrote:
>> Date: Wed, 27 Mar 2024 14:47:27 -0700
>> From: Jared Finder <jared@finder.org>
>> Cc: eliz@gnu.org, 69915@debbugs.gnu.org
>>
>> > On the other hand, looking at msdos.c, there is no test against
>> > the minibuffer. I believed, that the selection of the minibuffer
>> > is taken care of at +10638 of window.el. In my tests the patch
>> > behaves exactly like the documentation, quote: "Mouse
>> > auto-selection selects the minibuffer window only if it is active,
>> > and never deselects the active minibuffer window." I added the
>> > test, but commented it out.
>>
>> I'm not sure what the right way to proceed here is then. Eli, can you
>> give advice?
>>
>> Looking at different OS files that handle mouse_autoselect_window, I
>> see
>> the following state for checks if the selected window is a minibuffer
>> with MINI_WINDOW_P:
>>
>> pgtkterm.c: checks
>> w32term.c: does NOT check
>> w32inevt.c: does NOT check
>> nsterm.m: checks
>> xterm.c: checks
>> msdos.c: does NOT check
>> haikuterm.c: checks
>> androidterm.c: checks
>> term.c: no support for mouse-autoselect-window. :(
>>
>> My gut is to assume that the X and GTK behavior is most likely to be
>> better tested and more correct, but I defer to Eli here.
>
> I tend to agree. But, just to be sure, can you or Olaf describe the
> exact issue and how it could happen, and perhaps show a recipe to try
> reproducing it? I'd like to take a closer look at the relevant code.
The intended behavior is that is even with mouse-autoselect-window set,
moving the mouse is never supposed to change the selected window away
from the minibuffer. Many platforms explicitly check if the selected
window is the minibuffer before emitting the <select-window> event, but
not all platforms do (see list above).
And on all platforms, including ones without the explicit check we get
the intended behavior from our testing.
So my question is should we copy the explicit check to prevent
<select-window> events from being emitted to xt-mouse.el as well, even
though it does not appear to be necessary from our testing?
-- MJF
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal
2024-03-28 14:41 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-31 8:58 ` Eli Zaretskii
2024-04-01 9:09 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2024-03-31 8:58 UTC (permalink / raw)
To: Jared Finder, martin rudalics; +Cc: olaf.rogalsky, 69915
> Date: Thu, 28 Mar 2024 07:41:28 -0700
> From: Jared Finder <jared@finder.org>
> Cc: olaf.rogalsky@gmail.com, 69915@debbugs.gnu.org
>
> On 2024-03-27 23:11, Eli Zaretskii wrote:
> >> Date: Wed, 27 Mar 2024 14:47:27 -0700
> >> From: Jared Finder <jared@finder.org>
> >> Cc: eliz@gnu.org, 69915@debbugs.gnu.org
> >>
> >> > On the other hand, looking at msdos.c, there is no test against
> >> > the minibuffer. I believed, that the selection of the minibuffer
> >> > is taken care of at +10638 of window.el. In my tests the patch
> >> > behaves exactly like the documentation, quote: "Mouse
> >> > auto-selection selects the minibuffer window only if it is active,
> >> > and never deselects the active minibuffer window." I added the
> >> > test, but commented it out.
> >>
> >> I'm not sure what the right way to proceed here is then. Eli, can you
> >> give advice?
> >>
> >> Looking at different OS files that handle mouse_autoselect_window, I
> >> see
> >> the following state for checks if the selected window is a minibuffer
> >> with MINI_WINDOW_P:
> >>
> >> pgtkterm.c: checks
> >> w32term.c: does NOT check
> >> w32inevt.c: does NOT check
> >> nsterm.m: checks
> >> xterm.c: checks
> >> msdos.c: does NOT check
> >> haikuterm.c: checks
> >> androidterm.c: checks
> >> term.c: no support for mouse-autoselect-window. :(
> >>
> >> My gut is to assume that the X and GTK behavior is most likely to be
> >> better tested and more correct, but I defer to Eli here.
> >
> > I tend to agree. But, just to be sure, can you or Olaf describe the
> > exact issue and how it could happen, and perhaps show a recipe to try
> > reproducing it? I'd like to take a closer look at the relevant code.
>
> The intended behavior is that is even with mouse-autoselect-window set,
> moving the mouse is never supposed to change the selected window away
> from the minibuffer. Many platforms explicitly check if the selected
> window is the minibuffer before emitting the <select-window> event, but
> not all platforms do (see list above).
>
> And on all platforms, including ones without the explicit check we get
> the intended behavior from our testing.
>
> So my question is should we copy the explicit check to prevent
> <select-window> events from being emitted to xt-mouse.el as well, even
> though it does not appear to be necessary from our testing?
The mini-window test was added by Martin, AFAICT, as part of rewriting
the mouse-autoselect-window support. Martin, do you remember why you
added the MINI_WINDOW_P test in xterm.c, but not, for example, in
w32term.c?
In any case, I couldn't find any problems with the current behavior on
MS-Windows when mouse-autoselect-window is non-nil.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal
2024-03-31 8:58 ` Eli Zaretskii
@ 2024-04-01 9:09 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-01 11:40 ` Eli Zaretskii
0 siblings, 1 reply; 22+ messages in thread
From: martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-01 9:09 UTC (permalink / raw)
To: Eli Zaretskii, Jared Finder; +Cc: olaf.rogalsky, 69915
>> The intended behavior is that is even with mouse-autoselect-window set,
>> moving the mouse is never supposed to change the selected window away
>> from the minibuffer. Many platforms explicitly check if the selected
>> window is the minibuffer before emitting the <select-window> event, but
>> not all platforms do (see list above).
>>
>> And on all platforms, including ones without the explicit check we get
>> the intended behavior from our testing.
>>
>> So my question is should we copy the explicit check to prevent
>> <select-window> events from being emitted to xt-mouse.el as well, even
>> though it does not appear to be necessary from our testing?
>
> The mini-window test was added by Martin, AFAICT, as part of rewriting
> the mouse-autoselect-window support. Martin, do you remember why you
> added the MINI_WINDOW_P test in xterm.c, but not, for example, in
> w32term.c?
>
> In any case, I couldn't find any problems with the current behavior on
> MS-Windows when mouse-autoselect-window is non-nil.
The original mini-window test was conceived by Stefan
commit 66c226bf5a1e8289b0ce676d5e4225810a11af91
Author: Stefan Monnier <monnier@iro.umontreal.ca>
Date: Thu Jan 20 14:23:23 2005 +0000
(handle-select-window): Don't switch window when we're in the minibuffer.
and I moved it to xterm.c later. I don't remember why and all I
remember is that the accompanying comment was not mine.
The check is redundant because the condition is tested again here in
'handle-select-window':
;; Don't switch if window autoselection with mouse is active
;; and minibuffer window is selected.
(and mouse-autoselect-window (window-minibuffer-p))
One could say that the xterm.c code is more efficient because it doesn't
generate a SELECT_WINDOW_EVENT when the selected window is the
minibuffer window. The w32 code generates the event but has it
dismissed later in 'handle-select-window'.
In either case I would not remove the check from 'handle-select-window'
because that one is platform-independent so there's no need to implement
anything separately in the backends.
Though it might be more accurate to replace 'window-minibuffer-p' with
'minibuffer-window-active-p' to catch the case where a user, for some
reason, selects the minibuffer window manually without activating the
minibuffer. And the 'mouse-autoselect-window' conjunct above is likely
redundant...
martin
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal
2024-04-01 9:09 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-01 11:40 ` Eli Zaretskii
2024-04-01 14:08 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2024-04-01 11:40 UTC (permalink / raw)
To: martin rudalics; +Cc: olaf.rogalsky, 69915, jared
> Date: Mon, 1 Apr 2024 11:09:47 +0200
> Cc: olaf.rogalsky@gmail.com, 69915@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
>
> > The mini-window test was added by Martin, AFAICT, as part of rewriting
> > the mouse-autoselect-window support. Martin, do you remember why you
> > added the MINI_WINDOW_P test in xterm.c, but not, for example, in
> > w32term.c?
> >
> > In any case, I couldn't find any problems with the current behavior on
> > MS-Windows when mouse-autoselect-window is non-nil.
>
> The original mini-window test was conceived by Stefan
>
> commit 66c226bf5a1e8289b0ce676d5e4225810a11af91
> Author: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu Jan 20 14:23:23 2005 +0000
>
> (handle-select-window): Don't switch window when we're in the minibuffer.
>
> and I moved it to xterm.c later. I don't remember why and all I
> remember is that the accompanying comment was not mine.
>
> The check is redundant because the condition is tested again here in
> 'handle-select-window':
>
> ;; Don't switch if window autoselection with mouse is active
> ;; and minibuffer window is selected.
> (and mouse-autoselect-window (window-minibuffer-p))
>
> One could say that the xterm.c code is more efficient because it doesn't
> generate a SELECT_WINDOW_EVENT when the selected window is the
> minibuffer window. The w32 code generates the event but has it
> dismissed later in 'handle-select-window'.
>
> In either case I would not remove the check from 'handle-select-window'
> because that one is platform-independent so there's no need to implement
> anything separately in the backends.
>
> Though it might be more accurate to replace 'window-minibuffer-p' with
> 'minibuffer-window-active-p' to catch the case where a user, for some
> reason, selects the minibuffer window manually without activating the
> minibuffer. And the 'mouse-autoselect-window' conjunct above is likely
> redundant...
Thanks.
Jared and Olaf, so I think the minibuffer test in the patch should
stay, but please see Martin's suggestions above.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal
2024-04-01 11:40 ` Eli Zaretskii
@ 2024-04-01 14:08 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-02 7:50 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 22+ messages in thread
From: Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-01 14:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: olaf.rogalsky, martin rudalics, 69915
On 2024-04-01 04:40, Eli Zaretskii wrote:
>> Date: Mon, 1 Apr 2024 11:09:47 +0200
>> Cc: olaf.rogalsky@gmail.com, 69915@debbugs.gnu.org
>> From: martin rudalics <rudalics@gmx.at>
>>
>> > The mini-window test was added by Martin, AFAICT, as part of
>> rewriting
>> > the mouse-autoselect-window support. Martin, do you remember why
>> you
>> > added the MINI_WINDOW_P test in xterm.c, but not, for example, in
>> > w32term.c?
>> >
>> > In any case, I couldn't find any problems with the current behavior
>> on
>> > MS-Windows when mouse-autoselect-window is non-nil.
>>
>> The original mini-window test was conceived by Stefan
>>
>> commit 66c226bf5a1e8289b0ce676d5e4225810a11af91
>> Author: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Thu Jan 20 14:23:23 2005 +0000
>>
>> (handle-select-window): Don't switch window when we're in the
>> minibuffer.
>>
>> and I moved it to xterm.c later. I don't remember why and all I
>> remember is that the accompanying comment was not mine.
>>
>> The check is redundant because the condition is tested again here in
>> 'handle-select-window':
>>
>> ;; Don't switch if window autoselection with mouse is
>> active
>> ;; and minibuffer window is selected.
>> (and mouse-autoselect-window (window-minibuffer-p))
>>
>> One could say that the xterm.c code is more efficient because it
>> doesn't
>> generate a SELECT_WINDOW_EVENT when the selected window is the
>> minibuffer window. The w32 code generates the event but has it
>> dismissed later in 'handle-select-window'.
>>
>> In either case I would not remove the check from
>> 'handle-select-window'
>> because that one is platform-independent so there's no need to
>> implement
>> anything separately in the backends.
>>
>> Though it might be more accurate to replace 'window-minibuffer-p' with
>> 'minibuffer-window-active-p' to catch the case where a user, for some
>> reason, selects the minibuffer window manually without activating the
>> minibuffer. And the 'mouse-autoselect-window' conjunct above is
>> likely
>> redundant...
>
> Thanks.
>
> Jared and Olaf, so I think the minibuffer test in the patch should
> stay, but please see Martin's suggestions above.
Martin, did you mean we should change Olaf's patch to xt-mouse.el use
minibuffer-window-active-p or we should change handle-select-window in
window.el to use minibuffer-window-active-p?
I have a preference to keep xt-mouse.el aligned with xterm.c as well as
other native code checks, all which use MINI_WINDOW_P
(window-minibuffer-p in Lisp) currently.
-- MJF
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal
2024-04-01 14:08 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-02 7:50 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-04 16:32 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 22+ messages in thread
From: martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-02 7:50 UTC (permalink / raw)
To: Jared Finder, Eli Zaretskii; +Cc: olaf.rogalsky, 69915
> Martin, did you mean we should change Olaf's patch to xt-mouse.el use
> minibuffer-window-active-p or we should change handle-select-window in
> window.el to use minibuffer-window-active-p?
>
> I have a preference to keep xt-mouse.el aligned with xterm.c as well
> as other native code checks, all which use MINI_WINDOW_P
> (window-minibuffer-p in Lisp) currently.
'minibuffer-window-active-p' should be more accurate but I do not fully
understand its semantics any more. For anything you and Olaf do, I'd
recommend 'window-minibuffer-p' / MINI_WINDOW_P.
martin
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal
2024-04-02 7:50 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-04 16:32 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-04 16:41 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-06 10:15 ` Eli Zaretskii
0 siblings, 2 replies; 22+ messages in thread
From: Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-04 16:32 UTC (permalink / raw)
To: martin rudalics; +Cc: olaf.rogalsky, 69915, Eli Zaretskii
On 2024-04-01 04:40, Eli Zaretskii wrote:
> On 2024-04-02 00:50, martin rudalics wrote:
>> Jared and Olaf, so I think the minibuffer test in the patch should
>> stay, but please see Martin's suggestions above.
>
>> Martin, did you mean we should change Olaf's patch to xt-mouse.el use
>> minibuffer-window-active-p or we should change handle-select-window in
>> window.el to use minibuffer-window-active-p?
>>
>> I have a preference to keep xt-mouse.el aligned with xterm.c as well
>> as other native code checks, all which use MINI_WINDOW_P
>> (window-minibuffer-p in Lisp) currently.
>
> 'minibuffer-window-active-p' should be more accurate but I do not fully
> understand its semantics any more. For anything you and Olaf do, I'd
> recommend 'window-minibuffer-p' / MINI_WINDOW_P.
Eli, given this feedback I don't think Olaf's patch should be altered as
it currently uses window-minibuffer-p. Let me know if you would like
any further changes.
-- MJF
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal
2024-04-04 16:32 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-04 16:41 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-06 10:15 ` Eli Zaretskii
1 sibling, 0 replies; 22+ messages in thread
From: Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-04-04 16:41 UTC (permalink / raw)
To: martin rudalics; +Cc: olaf.rogalsky, 69915, Eli Zaretskii
Apologies, the manual quoting I did here for context was incorrectly
done in the previous email. I have corrected that.
>>>> Jared and Olaf, so I think the minibuffer test in the patch should
>>>> stay, but please see Martin's suggestions above.
>>>
>>> Martin, did you mean we should change Olaf's patch to xt-mouse.el use
>>> minibuffer-window-active-p or we should change handle-select-window
>>> in
>>> window.el to use minibuffer-window-active-p?
>>>
>>> I have a preference to keep xt-mouse.el aligned with xterm.c as well
>>> as other native code checks, all which use MINI_WINDOW_P
>>> (window-minibuffer-p in Lisp) currently.
>>
>> 'minibuffer-window-active-p' should be more accurate but I do not
>> fully
>> understand its semantics any more. For anything you and Olaf do, I'd
>> recommend 'window-minibuffer-p' / MINI_WINDOW_P.
>
> Eli, given this feedback I don't think Olaf's patch should be altered
> as it currently uses window-minibuffer-p. Let me know if you would
> like any further changes.
>
> -- MJF
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal
2024-04-04 16:32 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-04 16:41 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-04-06 10:15 ` Eli Zaretskii
1 sibling, 0 replies; 22+ messages in thread
From: Eli Zaretskii @ 2024-04-06 10:15 UTC (permalink / raw)
To: Jared Finder; +Cc: olaf.rogalsky, rudalics, 69915-done
> Date: Thu, 04 Apr 2024 09:32:28 -0700
> From: Jared Finder <jared@finder.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, olaf.rogalsky@gmail.com,
> 69915@debbugs.gnu.org
>
> Eli, given this feedback I don't think Olaf's patch should be altered as
> it currently uses window-minibuffer-p. Let me know if you would like
> any further changes.
Thanks, I installed both Olaf's and your changes, and I'm therefore
closing this bug.
P.S. Please note that @heading is not TRT inside a @subsection; I
fixed that.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal
2024-03-28 6:11 ` Eli Zaretskii
2024-03-28 14:41 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-30 17:03 ` Olaf Rogalsky
1 sibling, 0 replies; 22+ messages in thread
From: Olaf Rogalsky @ 2024-03-30 17:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 69915, Jared Finder
[-- Attachment #1: Type: text/plain, Size: 4680 bytes --]
Hi Jared and Eli,
Jared Finder <jared@finder.org> writes:
> On 2024-03-26 16:50, Olaf Rogalsky wrote:
>> Hi Jared,
>>
>>> >> <select-window> events shouldn't be generated while the mouse is being
>>> >> dragged. This probably is reflected in fully by track-mouse, but I'd
>>> >> suggest looking at the native code that generates the event to confirm.
>>> > Truly understanding xterm.c unfortunately is beyond my expertise. Nevertheless I
>>> > tested, the behavior. Dragging the mouse from one window to the next
>>> > (while passing over
>>> > the modeline) gives the following sequence of events:
> ... elided comments ...
>>> > Can't follow you here. At which occasion two events might be generated
>>> > and which ones?
>>> > I was thinking that if both a mouse movement and select window
>>> > event should both be returned, like if track-mouse is non-nil and
>>> > you switch windows. Can you test this case?
>> Test case 1:
>> (track-mouse
>> (setq mouse-autoselect-window t)
>> (let (e)
>> (while (not (eq e ?q))
>> (setq e (read-key))
>> (when (and (consp e) (symbolp (car e)))
>> (message "%s to %s at posn %s" (car e) (caadr e) (posn-x-y
>> (cadr e)))))))
>> Result with patched terminal:
> ... elided results ...
>> For the second test case I use read-key-sequence instead of read-key
>> Test case 2:
>> (track-mouse
>> (let ((can-return-switch-frame t) e)
>> (while (not (equal e "q"))
>> (setq e (read-key-sequence nil nil t can-return-switch-frame
>> nil))
>> (when (not (stringp e))
>> (setq e (seq-elt e 0))
>> (message "%s to %s at posn %s" (car e) (caadr e) (posn-x-y
>> (cadr e)))))))
>> Result with patched terminal:
> ... elided results ...
>> So, read-key behaves differently in the terminal compared to X11:
>> In the terminal, the can-return-switch-frame parameter of
>> read-key-sequence
...
>> But apparently these lines are never executed in the case of the
>> terminal input.
...
> One last experiment is worth trying here. If this doesn't work out, I
> think a FIXME will be sufficient. Instead of returning the
> <select-window> event, try pushing the <select-window> event onto
> unread-command-events. My thought is that this will let native code
> dequeue and handle the event normally, including taking
> can_return_switch_frame into account. Can you please try this?
Good idea, this solved the inconsistency.
> Looking at xterm.c, I think you also want a test against
> window-minibuffer-p.
...
> My gut is to assume that the X and GTK behavior is most likely to be
> better tested and more correct, but I defer to Eli here.
>> I tend to agree. But, just to be sure, can you or Olaf describe the
>> exact issue and how it could happen, and perhaps show a recipe to try
>> reproducing it? I'd like to take a closer look at the relevant code.
Jared alreaddy answered your question. I added the test against the
minibuffer, like xterm.c and pgtkterm.c do.
>>> I also commented out a condition, which ensures that the selection of a
>>> window can only occur, if the mouse is in the text area of the window.
>>> This matches the following sentence of the documentation:
>>> "In either case, the mouse pointer must enter the text area of a window
>>> in order to trigger its selection."
>>> But I found no situation, where it did matter and msdos.c didn't have
>>> that test, either. WDYT?
>> I think the documentation is incorrect and this commented out case
>> should be removed. Local testing on PGTK and Mac shows that the mouse
>> pointer can be over the window dividers, widget scroll bars, or
>> fringes and still have autoselect behavior activate.
> Is this at all relevant for TTY frames? Everything is "text area" on
> TTY frames, right? If not, what are the use cases where the mouse
> would be "not in the text area" on a TTY frame, in the context of
> auto-selecting a window?
I interpreted the phrase "text area" as those parts of the frame, which
show the contents of buffers, i.e. without modeline, window separators,
tab-bar, menu-bar. In other words, anything where posn-area returns nil.
Nevertheless, since no other backend checks for the text area, I removed
the out-commented test.
>> I can't find the documentation of the format of the select-window
>> event. Maybe its a good idea to add it.
> Agreed. I think it should be added to Focus Events in commands.texi.
But probaly by someone who knows the texi format and has a better
command of the english language than I do. Sorry.
Olaf
PS: sorry for the horrible formatting of the previous messages: I
usually do not use my gmail account ... Hope, this one comes out better.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-user-option-mouse-autoselect-window-for-tty-emac.patch --]
[-- Type: text/x-patch, Size: 2732 bytes --]
From 8de818075ff5e583e25d4f408b9333fac2c37a3c Mon Sep 17 00:00:00 2001
From: Olaf Rogalsky <olaf.rogalsky@gmail.com>
Date: Sat, 30 Mar 2024 17:00:51 +0100
Subject: [PATCH] Fix user option mouse-autoselect-window for tty emacs
Generate select-window events, so that mouse-autoselect-window takes
effect in tty emacs, when xterm-mouse-mode is enabled (Bug#69915).
* lisp/xt-mouse.el (xterm-mouse-translate-1):
If mouse-autoselect-window is non-nil, add select-window events to
unread-command-events.
---
lisp/xt-mouse.el | 25 +++++++++++++++++++++----
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/lisp/xt-mouse.el b/lisp/xt-mouse.el
index 081b8f32456..783718b4ba4 100644
--- a/lisp/xt-mouse.el
+++ b/lisp/xt-mouse.el
@@ -60,7 +60,9 @@ xterm-mouse-translate-1
(let* ((event (xterm-mouse-event extension))
(ev-command (nth 0 event))
(ev-data (nth 1 event))
+ (ev-window (nth 0 ev-data))
(ev-where (nth 1 ev-data))
+ (last-window (terminal-parameter nil 'xterm-mouse-last-window))
(vec (vector event))
(is-move (eq 'mouse-movement ev-command))
(is-down (string-match "down-" (symbol-name ev-command))))
@@ -73,6 +75,9 @@ xterm-mouse-translate-1
'mouse-movement
'mouse-click)))
+ ;; remember window of current mouse position
+ (set-terminal-parameter nil 'xterm-mouse-last-window ev-window)
+
(cond
((null event) nil) ;Unknown/bogus byte sequence!
(is-down
@@ -84,10 +89,22 @@ xterm-mouse-translate-1
vec)
(is-move
(xterm-mouse--handle-mouse-movement)
- (if track-mouse vec
- ;; Mouse movement events are currently supposed to be
- ;; suppressed. Return no event.
- []))
+ ;; after mouse movement autoselect the mouse window, but ...
+ (cond ((and mouse-autoselect-window
+ ;; ignore modeline, tab-bar, menu-bar and so forth ...
+ (windowp ev-window)
+ ;; and don't deselect the minibuffer ...
+ (not (window-minibuffer-p (selected-window)))
+ ;; and select only, if mouse is over a new window ...
+ (not (eq ev-window last-window))
+ ;; which is different from the selected window
+ (not (eq ev-window (selected-window))))
+ (put 'select-window 'event-kind 'switch-frame)
+ (push `(select-window (,ev-window)) unread-command-events)
+ [])
+ ;;(vector `(select-window (,ev-window))))
+ (track-mouse vec)
+ (t [])))
(t
(let* ((down (terminal-parameter nil 'xterm-mouse-last-down))
(down-data (nth 1 down))
^ permalink raw reply related [flat|nested] 22+ messages in thread
* bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal
2024-03-20 14:29 bug#69915: 30.0.50; mouse-autoselect-window has no effect in terminal Olaf Rogalsky
` (2 preceding siblings ...)
2024-03-27 21:47 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-03-30 20:18 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <handler.69915.D69915.17123985538558.notifdone@debbugs.gnu.org>
4 siblings, 0 replies; 22+ messages in thread
From: Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-03-30 20:18 UTC (permalink / raw)
To: Olaf Rogalsky; +Cc: 69915, Eli Zaretskii
[-- Attachment #1: Type: text/plain, Size: 895 bytes --]
I am happy with the contents of Olaf's patch. I would just do some
minor reformatting at this point: converting tabs to spaces, removing
commented out line, change comment wording slightly.
On 2024-03-30 10:03, Olaf Rogalsky wrote:
> Hi Jared and Eli,
>
>>> I can't find the documentation of the format of the select-window
>>> event. Maybe its a good idea to add it.
>> Agreed. I think it should be added to Focus Events in commands.texi.
>
> But probaly by someone who knows the texi format and has a better
> command of the english language than I do. Sorry.
I took a stab at generating documentation here. I'm not that familiar
with texi format either, so I'd appreciate a review.
> PS: sorry for the horrible formatting of the previous messages: I
> usually do not use my gmail account ... Hope, this one comes out
> better.
No worries, everything looked fine to me!
-- MJF
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Adding-documentation-for-switch-window-event.patch --]
[-- Type: text/x-diff; name=0001-Adding-documentation-for-switch-window-event.patch, Size: 5358 bytes --]
From 7cd83458caa3940f8a826233c1903bc69aafdef8 Mon Sep 17 00:00:00 2001
From: Jared Finder <jared@finder.org>
Date: Sat, 30 Mar 2024 13:14:43 -0700
Subject: [PATCH] Adding documentation for <switch-window> event
* doc/lispref/commands.texi (Focus Events): Adding documentation
for the structure of <switch-window> events. Making sure to be
clear when referring to window system windows vs Emacs windows.
* doc/lispref/windows.texi (Mouse Window Auto-selection): Adding
link to Focus Events.
---
doc/lispref/commands.texi | 66 ++++++++++++++++++++++++++++-----------
doc/lispref/windows.texi | 2 +-
2 files changed, 48 insertions(+), 20 deletions(-)
diff --git a/doc/lispref/commands.texi b/doc/lispref/commands.texi
index 4fe4969c0db..335a41dbb44 100644
--- a/doc/lispref/commands.texi
+++ b/doc/lispref/commands.texi
@@ -2303,15 +2303,34 @@ Focus Events
@subsection Focus Events
@cindex focus event
+This section talks about both window systems and Emacs frames. When
+talking about just ``frames'' or ``windows'', it refers to Emacs frames
+and Emacs windows. When talking about window system windows, which are
+also Emacs frames, this section always says ``window system window''.
+
+@noindent
Window systems provide general ways for the user to control which window
-gets keyboard input. This choice of window is called the @dfn{focus}.
-When the user does something to switch between Emacs frames, that
-generates a @dfn{focus event}. The normal definition of a focus event,
-in the global keymap, is to select a new frame within Emacs, as the user
-would expect. @xref{Input Focus}, which also describes hooks related
-to focus events.
+system window, or Emacs frame, gets keyboard input. This choice of
+window system window is called the @dfn{focus}. When the user does
+something to switch between Emacs frames, that generates a @dfn{focus
+event}. Emacs also generates focus events when using
+@var{mouse-autoselect-window} to switch between Emacs windows within
+Emacs frames.
+
+A focus event in the middle of a key sequence would garble the
+sequence. So Emacs never generates a focus event in the middle of a key
+sequence. If the user changes focus in the middle of a key
+sequence---that is, after a prefix key---then Emacs reorders the events
+so that the focus event comes either before or after the multi-event key
+sequence, and not within it.
-Focus events are represented in Lisp as lists that look like this:
+@heading Focus events for frames
+
+The normal definition of a focus event that switches frames, in the
+global keymap, is to select that new frame within Emacs, as the user
+would expect. @xref{Input Focus}, which also describes hooks related to
+focus events for frames. Focus events for frames are represented in
+Lisp as lists that look like this:
@example
(switch-frame @var{new-frame})
@@ -2321,19 +2340,28 @@ Focus Events
where @var{new-frame} is the frame switched to.
Some X window managers are set up so that just moving the mouse into a
-window is enough to set the focus there. Usually, there is no need
-for a Lisp program to know about the focus change until some other
-kind of input arrives. Emacs generates a focus event only when the
-user actually types a keyboard key or presses a mouse button in the
-new frame; just moving the mouse between frames does not generate a
-focus event.
+frame is enough to set the focus there. Usually, there is no need for a
+Lisp program to know about the focus change until some other kind of
+input arrives. Emacs generates a focus event only when the user
+actually types a keyboard key or presses a mouse button in the new
+frame; just moving the mouse between frames does not generate a focus
+event.
-A focus event in the middle of a key sequence would garble the
-sequence. So Emacs never generates a focus event in the middle of a key
-sequence. If the user changes focus in the middle of a key
-sequence---that is, after a prefix key---then Emacs reorders the events
-so that the focus event comes either before or after the multi-event key
-sequence, and not within it.
+@heading Focus events for windows
+
+When @var{mouse-autoselect-window} is set, moving the mouse over a new
+window within a frame can also switch the selected window. @xref{Mouse
+Window Auto-selection}, which describes the behavior for different
+values. When the mouse is moved over a new window, a focus event for
+switching windows is generated. Focus events for windows are
+reperesented in Lisp as lists that look like this:
+
+@example
+(select-window @var{new-window})
+@end example
+
+@noindent
+where @var{new-window} is the window switched to.
@node Xwidget Events
@subsection Xwidget events
diff --git a/doc/lispref/windows.texi b/doc/lispref/windows.texi
index eef05d94fdb..54ef3851820 100644
--- a/doc/lispref/windows.texi
+++ b/doc/lispref/windows.texi
@@ -6177,7 +6177,7 @@ Mouse Window Auto-selection
the mouse pointer. This accomplishes a policy similar to that of
window managers that give focus to a frame (and thus trigger its
subsequent selection) whenever the mouse pointer enters its
-window-system window (@pxref{Input Focus}).
+window-system window (@pxref{Input Focus}, @pxref{Focus Events}).
@defopt mouse-autoselect-window
If this variable is non-@code{nil}, Emacs will try to automatically
--
2.39.2
^ permalink raw reply related [flat|nested] 22+ messages in thread
[parent not found: <handler.69915.D69915.17123985538558.notifdone@debbugs.gnu.org>]