GNU bug report logs - #21333
25.0.50; window-size-change-functions not called after mini-window resize

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: pipcet <at> gmail.com, 21333 <at> debbugs.gnu.org
Subject: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize
Date: Thu, 27 Aug 2015 18:29:11 +0300

> Date: Thu, 27 Aug 2015 09:57:15 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: pipcet <at> gmail.com, 21333 <at> debbugs.gnu.org
> 
>  > OK, but if you want to stick to this example, please explain how is
>  > mini-window resizing relevant to follow-mode, because I think it
>  > isn't.  I think follow-mode should not care at all about this
>  > automatic resizing.
> 
> `follow-mode' has to synchronize the ‘window-end’ of one window with the
> ‘window-start’ of another.

Not when one of them is temporarily obscured by a resized mini-window,
IMO.

> Since mini-window resizing can persistently
> change the end position of the first of these windows

Any command that clears the echo area will resize it back, AFAIK.  So
it's not persistent.

> OT1H we do care about point being visible when its window is partially
> obscured by the mini-window and deliberately scroll the window in that
> case.  OTOH we'd say that `follow-mode' should not care about keeping
> its text coherent in that case.  Is that fair?

Yes.  In that situation, the user most probably reads the mini-window
text anyway, and if not, then she reads the text at point.  The
probability that she is reading the text that will be scrolled out of
view as result of the mini-window resize is IMO minuscule.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.