all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.





  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.