bug#19576: write-file writes the wrong buffer

[Eli Zaretskii]

> Date: Thu, 19 Nov 2015 07:54:32 +0100
> From: Anders Lindgren <andlind@gmail.com>
> Cc: Juri Linkov <juri@linkov.net>, martin rudalics <rudalics@gmx.at>, Alan 
> Mackenzie <acm@muc.de>, 
>       19576@debbugs.gnu.org
> 
>      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.

I could only understand that if whatever you do following a call to
set-window-start includes resizing of windows or creation/deletion of
windows.  Or maybe you meant editing in that window?  Even then at
least the simple commands I tried don't do that.

The display engine generally doesn't do anything unless the screen
should change.  So if you work outside of the window whose starting
point you forced, Emacs should never do anything with that window.

> 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.

The display engine doesn't recenter because it needs recentering.
Recentering is a means to achieve a specific goal, it isn't the goal
itself.  The goal is to determine the window's starting point when the
previous starting point cannot be used for some reason.  This is a
crucial part of the display of each window -- without determining
window-start, the display engine cannot proceed with displaying the
window.

So you cannot tell the display engine not to recenter, because it
won't know how to proceed.  I could understand if you'd ask for a way
to tell the display engine not to try redisplaying a certain window.
But disabling just the recentering is not in general possible, AFAIU.

(Actually, Emacs doesn't necessarily recenter: user options like
scroll-conservatively dictate how it finds a good candidate for
window-start, and recentering is just the simplest and the fastest
method.  But this doesn't seem to matter for the purposes of this
discussion, since you'd like to suppress _any_ kind of scrolling, I
believe.)

> 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.

I'm not sure I understand: how many lines are visible is determined by
the window height and the height of the font(s) used by the text
displayed there.  Once these parameters are fixed, you cannot control
the number of lines visible in a window, except by changing the window
height.  What am I missing?

>     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.

ispell and gdb-mi come to mind, and there are probably more examples.

> 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.

Thanks.