> On May 1, 2021, at 3:31 PM, Eli Zaretskii wrote: > >> From: JD Smith >> Date: Sat, 1 May 2021 14:46:31 -0400 >> >> I’m working on a small “in mode-line” scroll bar, and have implemented mouse events for it, which are working well. When I interact using the mouse with the mode line of a non-selected window, I need to have that window temporarily selected, so I can calculate its line offsets and move within it. But (just as for regular scrollbars), I’d like to retain the originally active window afterwards. > > Please explain in more detail why do you think you need to select the > window. What are those "line offsets", and why "move within it" > requires to select the window? Sure, thanks. I compute line positions at a number of points (window-start, window-end, and point-max) inside a mode line :eval form. To compute line numbers at these positions, for speed in very long files, I’m actually using: (defun mlscroll-fast-line-number-at-pos (pos) (save-excursion (goto-char pos) (string-to-number (format-mode-line "%l")))) The operative bits of the “move within” look like: (when (/= targ start) (forward-line (- targ start)) (recenter)) During normal automatic mode-line update, the selected window is automatically bound correctly while the mode line string is computed (without updating the mode line face, I might add!). But during the mouse event callback, I must use the starting window of the mouse event (a press) as the window to target, since the user could click on any of them. I believe I can re-task all of the “computing lines” code to take a window argument, i.e. to avoid actually selecting the window itself. But less clear is how to move forward and back a given number of lines (forward-line) and recenter in an unselected window, without selecting it temporarily and causing the mode line face flashing.