Re: feature/icomplete-vertical

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 05 Oct 2020 13:19:53 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: spacibba@aol.com, emacs-devel@gnu.org, casouri@gmail.com,
>         joaotavora@gmail.com, juri@linkov.net
> 
> > Using a buffer-local variable doesn't necessarily eliminate the problems 
> > with recursive-edit. And using window-scroll-functions for this purpose 
> > is a no-no.  So I cannot endorse this others solution, either.
> 
> Once again I have to stop a discussion with you, because I do not want to 
> start a public dispute with you.

You say that, and then you start a public dispute anyway.  Not sure
what to make of that.

> You reject everything I propose with vague statements about
> "potential problems", without any detail or recipe that would help
> me or others to see whether these "potential problems" are real or
> minor ones.

I'm not sure what detail I need to provide.  Isn't it clear that using
a buffer-local variable doesn't resolve problems with using that same
buffer in another level of recursive-edit?  Or that changing the
window-start position from under the feet of the display engine is
something that should be avoided?  Why would you need examples to
realize that a design based on this cannot be clean, in the sense that
use cases where it causes trouble will eventually surface?

> Note that what you object to (using set-window-start in 
> window-scroll-functions) is, in fact, already used twice in Emacs core.
> 
> In em-smart.el, eshell-smart-initialize adds eshell-smart-scroll-window to 
> window-scroll-functions, eshell-smart-scroll-window calls 
> eshell-smart-redisplay, and eshell-smart-redisplay uses set-window-start. 
> Likewise, follow.el adds follow-avoid-tail-recenter to 
> window-scroll-functions, and follow-avoid-tail-recenter uses 
> set-window-start.
> 
> In both cases, the code was already present in Emacs 21.  Which means that 
> it has been used for twenty years without known problems.

We routinely fix bugs in code that was written 20 and 30 years ago.
So the age of a problematic code doesn't mean it won't one day surface
as a bug.  As users and third-party packages write more and more
complex code for Emacs, we discover bugs that lay hidden for many
years.

Yes, the display engine includes some extra safety nets that might let
these bad practices work, at least in some use cases.  But that
doesn't mean the warnings in the documentation and in this discussion
should be disregarded.  You have just shown here how that can lead to
redisplay glitches.