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: Sun, 19 Apr 2020 22:06:42 +0300 Message-ID: <83a737i9bx.fsf@gnu.org> References: <20200403174757.GA8266@ACM> <20200405195753.GG5049@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> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="94015"; 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 Sun Apr 19 21:07:34 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 1jQFHx-000OMi-AL for ged-emacs-devel@m.gmane-mx.org; Sun, 19 Apr 2020 21:07:33 +0200 Original-Received: from localhost ([::1]:46682 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQFHw-0003lA-Ab for ged-emacs-devel@m.gmane-mx.org; Sun, 19 Apr 2020 15:07:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43454 helo=eggs1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQFHQ-0003FA-0R for emacs-devel@gnu.org; Sun, 19 Apr 2020 15:07:01 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55079) by eggs1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQFHN-0005Wr-Ti; Sun, 19 Apr 2020 15:06:57 -0400 Original-Received: from [176.228.60.248] (port=3701 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jQFHG-0004Ir-1n; Sun, 19 Apr 2020 15:06:51 -0400 In-Reply-To: <3ddcec07-079f-18e8-81a7-76eaf9a8187a@yandex.ru> (message from Dmitry Gutov on Sun, 19 Apr 2020 20:09:04 +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:247325 Archived-At: > Cc: acm@muc.de, rudalics@gmx.at, rrandresf@gmail.com, rms@gnu.org, > emacs-devel@gnu.org > From: Dmitry Gutov > Date: Sun, 19 Apr 2020 20:09:04 +0300 > > > It doesn't happen when next-line only moves by one line, then stops > > (as opposed to continue moving by one more line). > > But next-line only moves by one line. It's the other invocations of it > that perform subsequent movements. The fact that Emacs sometimes chooses > to "merge" several invocations into one is a speed optimization. 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 display engine has no idea what happened or why. All it knows is > > that point is more than one line below the window-bottom. That's the > > basics of the MVC design of Emacs: redisplay is uncoupled from the > > changes made by the commands. > > It seems that scrolling is rather coupled to redisplay, however. Not sure what you mean by "coupled" here. As I explained, scrolling is _implemented_ in redisplay. The scrolling commands just calculate where the window-start should be, they don't scroll anything. > Which is something I've never been aware of in the many years of > using Emacs. With Emacs, one learns something new every day. That includes myself, of course. > 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? 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. What you describe might be relevant to "scrolling" that happens if you lean on C-n, not on C-v.