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: Wed, 26 Aug 2015 18:29:28 +0300

> Date: Wed, 26 Aug 2015 09:09:30 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: pipcet <at> gmail.com, 21333 <at> debbugs.gnu.org
> 
> > You are our window-management czar:
> 
> A carpenter, at best.

I see no contradiction here.

> > No, by arranging the buffer contents and letting redisplay do its
> > job.  Problems of this kind happen only when a mode changes buffer
> > contents and related data structures (such as properties and overlays)
> > in response to redisplay, something that is bad idea to begin with,
> > because at the very least it immediately triggers another redisplay
> > cycle, and kills many redisplay optimizations.
> 
> ‘follow-mode’, to stick to one of the examples I cited earlier, uses
> neither properties nor overlays.  It must, however, know the exact
> ‘window-end’ position of any window that could be followed by another.
> This also means that a correct implementation of ‘follow-mode’ should be
> allowed to specify the order in which windows are redisplayed.  So
> ideally, redisplay would be able to process each window separately, tell
> us its new start and end positions and allow modes to react properly.

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.

Previous Next

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