[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Window change functions

From: Eli Zaretskii
Subject: Re: Window change functions
Date: Sat, 05 Jan 2019 09:20:45 +0200

> From: Stefan Monnier <address@hidden>
> Cc: martin rudalics <address@hidden>, address@hidden
> Date: Sat, 05 Jan 2019 01:17:57 -0500
> >>  > If it's run "at the end of redisplay", then I think it's too late: those
> >>  > hooks will often want to change something visual, and they will want it
> >>  > to appear right away, so it should be run just *before* redisplay.
> >> Note that 'window-size-change-functions' are currently already run
> >> right in the middle of redisplay.  Often, window sizes are correct
> >> only *after* redisplay.  Think of minibuffer window resizing or
> >> changes in the fringes, margins or modeline sub-structures.  But a
> >> final word on the location of the call will have to be told by Eli.
> > I don't think I can utter that final word, primarily because I don't
> > understand Stefan's concerns.  Stefan, could you please elaborate?
> For example, I have a window-size-change-functions which I use to
> re-balance windows (using balance-window-area) after a frame resize.
> It doesn't care about the exact window sizes when it's called, so having
> correct window sizes when it's called is not necessary.  OTOH redisplay
> will need to happen right after it was run, because it changes
> window sizes.  So the best time to run it is right before redisplay.

Since redisplay never resizes windows, except when it resizes the
mini-window, I don't see how redisplay is relevant to this issue.  And
if resizing a mini-window is the reason why Martin decided to run this
hook at the end of redisplay, we can arrange for an immediate
additional redisplay cycle given some special return value of the hook
function, then the user will never see an inaccurate display.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]