From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: JD Smith Newsgroups: gmane.emacs.devel Subject: Re: Temporarily select-window, without updating mode-line face and cursor fill? Date: Mon, 3 May 2021 12:16:15 -0400 Message-ID: <40C17378-A4BF-4E70-A77D-E5034FA42C91@gmail.com> References: <56F746A2-B842-421E-8FBF-EA5E93EA26CE@gmail.com> <83pmya8d49.fsf@gnu.org> <6168853E-E5B1-4247-A0D7-4D4191DCED0A@gmail.com> <83im418wap.fsf@gnu.org> <1941D505-E603-41DD-904E-9BD7E4F28155@gmail.com> <16ddb4bc-2027-37db-326f-5b11b24a2132@gmx.at> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_DB71022C-275F-4950-A5D7-BCAC825C2222" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30138"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 03 18:17:55 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ldbGc-0007hK-9K for ged-emacs-devel@m.gmane-mx.org; Mon, 03 May 2021 18:17:54 +0200 Original-Received: from localhost ([::1]:50818 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ldbGb-0004Uc-AY for ged-emacs-devel@m.gmane-mx.org; Mon, 03 May 2021 12:17:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34406) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ldbFC-0003rr-Jx for emacs-devel@gnu.org; Mon, 03 May 2021 12:16:27 -0400 Original-Received: from mail-qv1-xf2b.google.com ([2607:f8b0:4864:20::f2b]:33664) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ldbFA-0003IK-43; Mon, 03 May 2021 12:16:26 -0400 Original-Received: by mail-qv1-xf2b.google.com with SMTP id i8so2862589qvv.0; Mon, 03 May 2021 09:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+Y45e+nN1KK/qUISr5cRo/wPWsSLjuzcn7ga2ALe6Ek=; b=XBmi2As7DLQ5dVYT2VL8ixJvkGFW2ltKEP8eBEczWan5orWqnL4Pwh8vnkL+UXLaNl spZOD6NCAz3Dfed7nVktYewvWINWyAW311nbO0peSziZAD/UpABzGrxPSzA8uL30llbc fwvBYePNE+1BQymRiAoXjGNAcD6gOheWeNYKBvOlBHnCYkd8dV8jyRzCYEpqTxI6jsLU inipIGjwVprUzjzLq056dhFujRiyJmEsMcbtleM9lk+vjUWOBu4Ghn2KNKpgqrtgClgN j8+E49m6dg/8YalrWBdTBZN85Pb/1Spx/VxqK6Re4ItgcnUs2jABPbe+qutR+oeQsXRO iqAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=+Y45e+nN1KK/qUISr5cRo/wPWsSLjuzcn7ga2ALe6Ek=; b=t6dxQvnOdgNtRdBnFhMMBryFUxhZRTSmcs1Y7vHZaC1NvHdj1nfRSGkSZLDjPUjGik Kg3Mes2GkObQcfZjYrFDFKCeoTSzsoVFGT/9lEYrmUl9SKMKYRTOzEtuZFl/6A45U7sT KQzf8R5RjXvRfBD8xNswdUs8KKwE7Gl9jeEkWwghYw+k/XRyMkyToFAr/B+RR0ue6hgu OTZXuwHxzEMaeX29N6gzESggfBOvWPcA5yGEOZvpuPcnEbkKkcerW6+2MtL5EVKrN92w RBjKnzctx/2GxCPHJR/1fBx45+D71SHpC+IE4/5vnTlGwT9F9vx2nbE2/pypZGMZ4jsz gnUA== X-Gm-Message-State: AOAM530lKVqDytv4rDSX8CfHSqE3kvThCNqYYOTGHKKKxd0wGEiueTxP qAVbVmjS413gSdx/TbcC27n/UXFb7tlmqA== X-Google-Smtp-Source: ABdhPJzpEMpLUTy8lGDfwOvFb7EldV3MtTVHCHtmvrC7qC1u3LtJ4OfrQ2BrW0m8hn05vxH2l0AcDw== X-Received: by 2002:a05:6214:12d0:: with SMTP id s16mr20354559qvv.60.1620058579662; Mon, 03 May 2021 09:16:19 -0700 (PDT) Original-Received: from smtpclient.apple (cm-134-228-25-135.buckeyecom.net. [134.228.25.135]) by smtp.gmail.com with ESMTPSA id b15sm199981qtg.82.2021.05.03.09.16.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 May 2021 09:16:18 -0700 (PDT) In-Reply-To: <16ddb4bc-2027-37db-326f-5b11b24a2132@gmx.at> X-Mailer: Apple Mail (2.3654.80.0.2.43) Received-SPF: pass client-ip=2607:f8b0:4864:20::f2b; envelope-from=jdtsmith@gmail.com; helo=mail-qv1-xf2b.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:268822 Archived-At: --Apple-Mail=_DB71022C-275F-4950-A5D7-BCAC825C2222 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 3, 2021, at 3:50 AM, martin rudalics wrote: >=20 > >> 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 =E2=80=9Cwindow-start=E2=80=9D and =E2=80=9Cwindow-end=E2=80= =9D. 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. >=20 > 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=E2=80=99m 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). =20 For calculating the line number in a window which may or may not be = selected, (format-mode-line "%l=E2=80=9D 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 =E2=80=9Cm= ode line flashing". I need a mythical `save-excursion-in-window', if = you will. But perhaps I am missing you? If you think there=E2=80=99s 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=E2=80=99= 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=20 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=E2=80=99m not using select-window at all now. On set-window-point, = see above; I admit it=E2=80=99s not clear to me why setting and = restoring window-point is any worse than a save-excursion. =20 But I will certainly need set-window-start for handling mouse-based = events on the mode line (click/drag/scroll). Perhaps I didn=E2=80=99t = 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 =E2=80=9Ctrouble=E2= =80=9D it would cause? Other mouse events in the mode-line call things = like =E2=80=98previous-buffer, so it=E2=80=99s not clear to me why = set-window-start would lead to any special issues when driven by mouse = events.=20= --Apple-Mail=_DB71022C-275F-4950-A5D7-BCAC825C2222 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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 =E2=80=9Cwindow-start=E2=80=9D and =E2=80=9Cwindow-end=E2=80=9D.=  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=E2=80=99m 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=E2=80=9D 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 =E2=80=9Cmode line flashing".  I need a mythical = `save-excursion-in-window', if you will.

But perhaps I am missing you?  If you think = there=E2=80=99s 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=E2=80=99s 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=E2=80=99m not using select-window at all now. =  On set-window-point, see above; I admit it=E2=80=99s 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=E2=80=99t 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 =E2=80=9Ctrouble=E2= =80=9D it would cause?  Other mouse events in the mode-line call = things like =E2=80=98previous-buffer, so it=E2=80=99s not clear to me = why set-window-start would lead to any special issues when driven by = mouse events. 
= --Apple-Mail=_DB71022C-275F-4950-A5D7-BCAC825C2222--