From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: feature/icomplete-vertical Date: Mon, 05 Oct 2020 16:44:31 +0300 Message-ID: <838sckdby8.fsf@gnu.org> References: <83lfh4zfml.fsf@gnu.org> <838sd4z6lz.fsf@gnu.org> <20201001164804.mqqyxtet4ttweuyv@Ergus> <83blhhdy3w.fsf@gnu.org> <87d01xghmt.fsf@gmail.com> <83sgatc8er.fsf@gnu.org> <83mu11c78j.fsf@gnu.org> <87tuv9eygk.fsf@gmail.com> <87imbogb6k.fsf@gmail.com> <83eemcdgg2.fsf@gnu.org> <83d01wdf8p.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13630"; mail-complaints-to="usenet@ciao.gmane.io" Cc: joaotavora@gmail.com, spacibba@aol.com, juri@linkov.net, casouri@gmail.com, emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 05 15:45:42 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kPQo9-0003Mg-TE for ged-emacs-devel@m.gmane-mx.org; Mon, 05 Oct 2020 15:45:41 +0200 Original-Received: from localhost ([::1]:36080 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kPQo8-0007vj-Vy for ged-emacs-devel@m.gmane-mx.org; Mon, 05 Oct 2020 09:45:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51470) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kPQn4-0007Ug-9h for emacs-devel@gnu.org; Mon, 05 Oct 2020 09:44:34 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58945) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kPQn2-0007HT-F0; Mon, 05 Oct 2020 09:44:32 -0400 Original-Received: from [176.228.60.248] (port=2049 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kPQn1-0000sU-FN; Mon, 05 Oct 2020 09:44:31 -0400 In-Reply-To: (message from Gregory Heytings on Mon, 05 Oct 2020 13:19:53 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:257128 Archived-At: > Date: Mon, 05 Oct 2020 13:19:53 +0000 > From: Gregory Heytings > 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.