bug#19576: write-file writes the wrong buffer

[Anders Lindgren]

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