GNU bug report logs - #19576
24.4; Broken function in `window-size-change-functions' cause `write-file' to write the wrong buffer

Previous Next

Full log

Message #71 received at 19576 <at> debbugs.gnu.org (full text, mbox):

From: Anders Lindgren <andlind <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 19576 <at> debbugs.gnu.org,
 Alan Mackenzie <acm <at> muc.de>, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#19576: write-file writes the wrong buffer
Date: Thu, 19 Nov 2015 07:54:32 +0100

[Message part 1 (text/plain, inline)]

Hi,


> I don't see any spontaneous recentering after that, so a reproducible
> test case will be appreciated.  Maybe something that makes the
> difference hides behind "work with Emacs for a while", I don't know.
>

It's hard to give an exact recipe, because the recentering occurs
stochastically. Sometimes, it occurs within a few seconds, sometimes within
a minute and sometimes the window stays like it is for a long period of
time.

The fact remains that a window where window-start equals point-max (i.e. a
window displaying nothing) do recenter itself from time to time.

Today, follow-mode actively prevents this by updating window-start of "tail
windows" whenever it gets a change (in the post-command-hook and in all
display-related hooks). Clearly, this is not an elegant solution, but in
practice it works.

My proposal is to modify the display engine so that instead of simply
recentering a window, it should call a hook to determine if the recentering
should take place. This can be made more of less fancy -- a simple solution
would be to return a boolean. A more advances solution could let a lisp
function in packages to decide how many lines should be visible.

Clearly, this is not something that would affect efficiency negatively as
this would be called relative seldom, maybe once a minute, and only if the
hook variable is non-nil. In fact, it will have a positive effect on
efficiency as the current solution isn't very efficient.

Anyway, this is not something that we have to change. The current solution,
albeit clumsy, have been working for 20 years.


> These all sound like application-level problems to me, not issues with
> the display engine.  At least not in the first approximation.

Yes, I agree on this. The list I originally mailed contained all
follow-mode related thoughts, not just the display-engine related.


Doesn't this mean that you need a way to hook buffer text changes?
> Hooking processes is not necessarily what you want, since a process
> filter could eat up the output completely and not show it in any
> window, in which case follow-mode shouldn't be bothered.  Right?
>

Right. However, the difference is rather academic since it would probably
few cases where a prior filter would eat all output.


> However, one way to handle this is to respect an explicit
> `set-window-start'
> > position even if the column isn't a multiple of the screen width.
>
> Ask Alain how easy that is.
>
> I'm telling you: this is the tip of a huge iceberg.  The display
> engine was never designed to handle windows whose redisplay depends on
> other windows.


OK, lets leave it as it is for now.


When it comes to bug#19576 (write-file saves the wrong buffer). As both
John and Eli think this shouldn't be fixed in the Emacs core, I will
correct the code in follow-mode and (if needed) update the documentation to
warn others of the dragons in these waters.

Anyway, I will pull out the this follow-mode discussion, partly because I
feel it has taken the focus away from the work Alan is doing, and partly
for personal reasons. The little time I have for Emacs-related work, I will
focus on NextStep issues.

Sincerely,
    Anders Lindgren

[Message part 2 (text/html, inline)]

Previous Next

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