Re: Temporarily select-window, without updating mode-line face and cursor fill?

[JD Smith]

On May 3, 2021, at 3:50 AM, martin rudalics <rudalics@gmx.at> wrote:

>> Sure, but the event gives you the window, and through it the buffer of
>> that window, so I see no particular reason to make the window
>> selected.
>
>
> A given buffer may appear in multiple windows, which likely will have
> different “window-start” and “window-end”.  So you have to find the
> line position in the buffer relevant for that particular window.  Also
> tying me to this is the fact that the format-mode-line method
> obviously uses windows, not buffers.

I'm still missing you.  Both `window-start' and `window-point' have a
WINDOW argument.  So running `get-buffer-window-list' for the buffer you
want to manage and calling the former for each window you get that way
should all do what you want.

Since I’m working on the mode line, I am managing windows, not buffers. Mode line :eval forms handle this issue for you automatically, by quietly selecting the appropriate window (even inactive ones).  So nothing is needed there.  Only on modeline _mouse events_ do I need to target a specific window (the one mentioned in the event).  

For calculating the line number in a window which may or may not be selected, (format-mode-line "%l” 0 win) has a window argument, but it does *not* have a position argument.  It takes its position from (as far as I can tell) the window-point of its window argument.  So I need to move window-point and immediately restore it if I want to use format-mode-line.  If the window were selected, a simple save-excursion would be enough.  But I cannot first select the window or I get “mode line flashing".  I need a mythical `save-excursion-in-window', if you will.

But perhaps I am missing you?  If you think there’s a simpler approach that permits the format-mode-line line number workaround without set-window-point, could you share some pseudo-code?

I recognize I could avoid this issue if an optimization like Stefan’s nlinum caching would work well enough, in which case I can drop the use of format-mode-line, and avoid moving window-point at all.  The cost is an after-change-function always running, which some people might object to (me included).   And now simply 

If line-number-at-pos were more performant, and not dependent on position within the buffer, I could avoid both of these things (format-mode-line and an after-change-function).  Quick overview of timing per line-num calc on /usr/dict/words (236k lines) @ (point-max):

line-number-at-pos: 21ms

set-window-point, (string-to-number (format-line-mode %l), restore window-point: 2ms

And please keep in mind: Calling `select-window' in an :eval form within
`mode-line-format' means asking for trouble.  Calling `set-window-start'
and `set-window-point' anywhere within `mode-line-format' or a hook like
`window-scroll-functions' or `window-state-change-functions' means
asking for more trouble.  All these serve to react to changes in the
window configuration but should never change that configuration itself.

I’m not using select-window at all now.  On set-window-point, see above; I admit it’s not clear to me why setting and restoring window-point is any worse than a save-excursion.  

But I will certainly need set-window-start for handling mouse-based events on the mode line (click/drag/scroll).  Perhaps I didn’t make it clear that set-window-start will only be called in mouse-based event callbacks on the mode line; apologies if so.  If even this is problematic in your view, could you clarify the sort of “trouble” it would cause?  Other mouse events in the mode-line call things like ‘previous-buffer, so it’s not clear to me why set-window-start would lead to any special issues when driven by mouse events.