bug#19576: write-file writes the wrong buffer

[Eli Zaretskii]

> Date: Tue, 17 Nov 2015 22:15:07 +0100
> From: Anders Lindgren <andlind@gmail.com>
> Cc: martin rudalics <rudalics@gmx.at>, Alan Mackenzie <acm@muc.de>, 
> 19576@debbugs.gnu.org, 
>       Eli Zaretskii <eliz@gnu.org>
> 
> * The Emacs display engine tries to recenter windows when window-start ==
> buffer-end, to ensure that no window would appear empty. When follow-mode
> is enabled, this is not what we want (except for the leftmost window). To
> counter the recentering efforts of Emacs, follow-mode sets window-start
> whenever it gets a chance. I would prefer if it was possible to tell the
> display engine to leave some windows alone, preferably with some kind of
> buffer-local `recenter-window-functions' variable. It could be made generic
> so that the return value would be an integer telling Emacs to show this
> many lines (if positive) or place the last line X lines from the bottom
> (when negative). If such hook existed, follow-mode could return 0 for all
> (except the leftmost) windows. Note that the user can change the content of
> any window at any time, so this property isn't static.

I don't understand why

    (set-window-start WINDOW POS t)

is not sufficient.  It does force the display engine to honor the
window-start position requested by the call; no recentering will take
place.  You say you "would prefer if it was possible to tell the
display engine to leave some windows alone", but that's exactly what
the above call does, wrt the starting position of the window.  So why
isn't it sufficient?

> * Make it easier for other packages to use it. By this I mean packages that
> display information, like "grep", should be able to use follow mode to
> display a buffer using side by side windows.

But Follow is a minor-mode, right?  So why cannot Grep etc. just turn
it on?

> * When follow-mode is enabled, there is a noticeable lag when updating the
> region. You can see this by pressing C-c SPACE and holding the up or down
> key. When follow-mode is disabled, the region is updated as fast as the
> cursor moves, when enabled, it is updated in chunks.

I guess follow-mode's post-command-hook interferes with
pre-redisplay-functions used to display the region nowadays.  Please
look into this, it would be good to fix this before Emacs 25.1 is out.

> * Process output: In early versions of follow-mode, it could be used with
> any process. This was accomplished using `defadvice' on a handful of
> process-related functions. At some point in time, this system was replaced
> with a system specific to comint and compilation buffers -- as part of the
> great defadvice sweep. Personally, I would like to Emacs to provide
> `pre-process-output-functions' and `post-process-output-functions',
> allowing packages like follow-mode to perform whatever action they would
> like to the output of any process.

Such hooks will be almost trivial to provide, I think.  But I don't
think I understand what problems would such hooks solve.  Could you
elaborate?

> * If a user have columns with different widths, follow-mode can't correctly
> display long lines stretching from one window to the next. The reason for
> this is that the start position can't be placed at an arbitrary location on
> a long line, only on positions that are a multiple of the column width. I
> don't see any way to solve this without modifying the display engine.

This is a tough nut, and the real problem is not necessarily obvious.
The real problem is that the display engine _assumes_ the lines above
and below the window edge are of the same pixel width.  It uses this
assumption in its layout code and decisions.  But when follow-mode us
used in windows of unequal width, that assumption breaks.  This is a
very serious problem, because the basic design of the Emacs display
engine is that it does its job one window at a time, i.e. it assumes
that displaying a window is possible by examining only the data of
that single window, and its associated buffer.