From: JD Smith <jdtsmith@gmail.com>
To: martin rudalics <rudalics@gmx.at>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: Temporarily select-window, without updating mode-line face and cursor fill?
Date: Mon, 3 May 2021 12:16:15 -0400 [thread overview]
Message-ID: <40C17378-A4BF-4E70-A77D-E5034FA42C91@gmail.com> (raw)
In-Reply-To: <16ddb4bc-2027-37db-326f-5b11b24a2132@gmx.at>
[-- Attachment #1: Type: text/plain, Size: 3842 bytes --]
> 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.
[-- Attachment #2: Type: text/html, Size: 5098 bytes --]
next prev parent reply other threads:[~2021-05-03 16:16 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-01 18:46 Temporarily select-window, without updating mode-line face and cursor fill? JD Smith
2021-05-01 19:31 ` Eli Zaretskii
2021-05-01 20:32 ` JD Smith
2021-05-02 6:49 ` Eli Zaretskii
2021-05-03 2:15 ` JD Smith
2021-05-03 7:50 ` martin rudalics
2021-05-03 16:16 ` JD Smith [this message]
2021-05-03 17:32 ` martin rudalics
2021-05-02 7:40 ` martin rudalics
2021-05-03 2:23 ` JD Smith
2021-05-01 22:17 ` JD Smith
2021-05-02 6:55 ` Eli Zaretskii
2021-05-03 2:08 ` JD Smith
2021-05-03 2:25 ` Stefan Monnier
2021-05-03 2:49 ` JD Smith
2021-05-04 19:28 ` JD Smith
2021-05-04 19:40 ` Stefan Monnier
2021-05-05 0:49 ` Stefan Kangas
2021-05-05 11:54 ` Eli Zaretskii
2021-05-05 19:32 ` Stefan Kangas
2021-05-05 19:47 ` Stefan Monnier
2021-05-06 0:16 ` JD Smith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40C17378-A4BF-4E70-A77D-E5034FA42C91@gmail.com \
--to=jdtsmith@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.