From: Juri Linkov <juri@linkov.net>
To: martin rudalics <rudalics@gmx.at>
Cc: 32637@debbugs.gnu.org
Subject: bug#32637: 27.0.50; window-size-change-functions not run from local hook
Date: Sun, 09 Sep 2018 02:56:35 +0300 [thread overview]
Message-ID: <87zhwrzgp8.fsf@mail.linkov.net> (raw)
In-Reply-To: <5B92296A.4020603@gmx.at> (martin rudalics's message of "Fri, 07 Sep 2018 09:31:54 +0200")
>> But in bug#32536 you agreed that Man-window-size-change has to
>> take care of cases where buffer-local window-size-change-functions
>> needs to find all Man windows on the frame to compare their sizes
>> and reformat the buffer with the minimim width from all its windows.
>>
>> So the window-size-change-functions hook should call the function not
>> with the window as argument, but with the whole frame, as it already
>> does now. And to call the buffer-local hook only once for all
>> affected windows, as it already does now (the hook has responsibility
>> to find all its windows from the frame).
>
> I meant that running 'window-size-change-functions' in a buffer-local
> fashion when no window showing that buffer has changed its size might
> be misleading.
window-size-change-functions calling code could detect if a window with
a buffer-local hook changed its size, and not to call its hook in this
case. This would be even better than using global hook where you can't
implement such optimization.
> But put a buffer-local function on 'window-configuration-change-hook'
> and show the buffer in two windows. The function gets called twice
> with the respective window selected. So if we implemented
> 'window-size-change-functions' in the same way as you suggested
> earlier, you would "find all Man windows on the frame to compare their
> sizes and reformat the buffer with the minimim width from all its
> windows" twice. How would you deal with that?
window-size-change-functions calling code could call it only once
for every frame, even if the same buffer is displayed in multiple
windows.
>>> And I still think that running 'window-configuration-change-hook'
>>> buffer-locally in its current from hardly makes sense either: For
>>> example, we don't call it for a buffer when that buffer has been
>>> removed from a window which incidentally is the case that would allow
>>> Man to remove its function from 'window-configuration-change-hook'.
>>
>> There is no need to remove function from the buffer-local hook,
>> because it is called only when the buffer is displayed
>> in a window.
>
> As you noted earlier, a buffer-local 'window-size-change-functions'
> function gets called regardless of whether the buffer is shown in a
> window on the frame in question.
I see that it's not called when the buffer is not displayed in any
window on the frame - this is correct. But what I noted earlier is that
it's not called when the buffer with the buffer-local hook is not the
current-buffer in the selected window (but it's displayed in a
non-selected window on the frame) - this should be fixed to call the hook
regardless if its window is currently selected or not.
> And if we wanted to fix that, we probably need something better than
> imitating 'window-configuration-change-hook'.
I think window-configuration-change-hook is a step forward in the
right direction.
next prev parent reply other threads:[~2018-09-08 23:56 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-04 21:03 bug#32637: 27.0.50; window-size-change-functions not run from local hook Juri Linkov
2018-09-05 7:47 ` martin rudalics
2018-09-05 15:26 ` Eli Zaretskii
2018-09-05 21:56 ` Juri Linkov
2018-09-06 2:35 ` Eli Zaretskii
2018-09-06 22:17 ` Juri Linkov
2018-09-05 21:54 ` Juri Linkov
2018-09-06 7:05 ` martin rudalics
2018-09-06 22:06 ` Juri Linkov
2018-09-07 7:31 ` martin rudalics
2018-09-08 23:56 ` Juri Linkov [this message]
2018-09-09 6:03 ` Eli Zaretskii
2018-09-09 8:40 ` martin rudalics
2018-09-09 15:59 ` Eli Zaretskii
2018-09-10 8:29 ` martin rudalics
2018-09-09 16:17 ` Juri Linkov
2018-09-10 8:29 ` martin rudalics
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=87zhwrzgp8.fsf@mail.linkov.net \
--to=juri@linkov.net \
--cc=32637@debbugs.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.