Hi Jared and Eli, Jared Finder writes: > On 2024-03-26 16:50, Olaf Rogalsky wrote: >> Hi Jared, >> >>> >> 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 > event, try pushing the 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.