From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Scrolling commands and skipping redisplay, was: Re: emacs rendering comparisson between emacs23 and emacs26.3 Date: Mon, 20 Apr 2020 18:01:48 +0300 Message-ID: <83mu76gq03.fsf@gnu.org> References: <20200403174757.GA8266@ACM> <542b48ba-4dfa-820f-ba50-4b147ab6d8e2@yandex.ru> <0a5f70aa-4985-8f8d-81d6-6ac4a60a94f9@yandex.ru> <838sj8sphk.fsf@gnu.org> <834ktwsmfw.fsf@gnu.org> <83imibqsmm.fsf@gnu.org> <478c2aab-a5fc-61c2-02e2-2d9846b95273@yandex.ru> <83v9m9nltx.fsf@gnu.org> <83tv1rn8fx.fsf@gnu.org> <4f8bb277-b376-97bf-8539-799688d8e66d@yandex.ru> <83eesvmj15.fsf@gnu.org> <6eec7f68-770e-b3b1-4627-6222f3ef7216@yandex.ru> <83ftd9kwlu.fsf@gnu.org> <1de9d24f-eeb7-7d0a-3768-4baba4365066@yandex.ru> <83zhbcdmyi.fsf@gnu.org> <61f565cd-4fee-d48c-a9ef-b78419b3d058@yandex.ru> <83wo6ed4kb.fsf@gnu.org> <464b5639-7790-fdbc-b519-22a6b0e8c016@yandex.ru> <83o8rqaucp.fsf@gnu.org> <551c7634-f614-c5a7-c089-33a0dc56574d@yandex.ru> <83imhyaqyw.fsf@gnu.org> <3ddcec07-079f-18e8-81a7-76eaf9a8187a@yandex.ru> <83a737i9bx.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="18953"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, rrandresf@gmail.com, emacs-devel@gnu.org, rms@gnu.org, rudalics@gmx.at To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 20 17:02:44 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 1jQXwZ-0004n6-Qa for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Apr 2020 17:02:43 +0200 Original-Received: from localhost ([::1]:37424 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQXwY-00073z-TE for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Apr 2020 11:02:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54462 helo=eggs1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQXvt-0006EV-KN for emacs-devel@gnu.org; Mon, 20 Apr 2020 11:02:02 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48842) by eggs1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQXvs-0004pP-O7; Mon, 20 Apr 2020 11:02:00 -0400 Original-Received: from [176.228.60.248] (port=4543 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jQXvk-0003Z2-Fe; Mon, 20 Apr 2020 11:01:53 -0400 In-Reply-To: (message from Dmitry Gutov on Mon, 20 Apr 2020 06:17:55 +0300) 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:247392 Archived-At: > Cc: acm@muc.de, rudalics@gmx.at, rrandresf@gmail.com, rms@gnu.org, > emacs-devel@gnu.org > From: Dmitry Gutov > Date: Mon, 20 Apr 2020 06:17:55 +0300 > > > It's not a "merge" and not an optimization, it's how Emacs was > > designed. It only enters redisplay when it's idle. If you invoke > > commands one after another quickly enough, more than one command will > > be executed before the next redisplay cycle. > > The fact that Emacs's behavior can depend on when redisplay happens, and > the user cannot reliably control it, is problematic IMHO. Please be specific: what Emacs's behavior can depend on when redisplay happens, apart from whether something was or wasn't updated on display? > >> At the beginning of each command, we can save the value of point. If, at > >> the end, we're still in the same buffer, and the new value of point > >> fails the scroll-conservatively check, count the lines between the > >> previous value of point and the new one. If that number is <= > >> scroll-conservatively, then scroll "conservatively" anyway. > > > > And if not, then what? > > Then give up and move point to the middle of the window. But that's again "not good" according to your opinion, isn't it? Or maybe you assume this will solve most of the cases when we currently recenter under scroll-conservatively < 101? > > Anyway, scrolling commands don't normally move point, they move the > > window-start. Point then moves because redisplay brings it into > > view. So I don't think your algorithm will work, at least not in the > > usual case. > > I'm a lot less worried about scrolling "conservatively" when the user > actually invokes the scrolling commands. Ahem... the thread's title begins with "scrolling commands",so I thought we were still discussing that? > > What you describe might be relevant to "scrolling" that happens if you > > lean on C-n, not on C-v. > > C-n, or C-M-e, or C-s. These are indeed scenarios when the current > behavior can be most surprising. Is it? Just out of habit, I suppose. What Emacs does make a lot of sense: it shows you the optimal amount of context. By contrast, scroll-conservatively shows you only one side of that context, and usually the wrong side.