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: Fri, 17 Apr 2020 21:48:23 +0300 Message-ID: <83imhyaqyw.fsf@gnu.org> References: <20200403174757.GA8266@ACM> <97c4254e-ff43-8402-3645-f713c408c245@gmx.at> <83y2r9syby.fsf@gnu.org> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="21199"; 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 Fri Apr 17 20:49:32 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 1jPW3Q-0005On-Bd for ged-emacs-devel@m.gmane-mx.org; Fri, 17 Apr 2020 20:49:32 +0200 Original-Received: from localhost ([::1]:50772 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jPW3P-0004ob-Dx for ged-emacs-devel@m.gmane-mx.org; Fri, 17 Apr 2020 14:49:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56686) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jPW2e-0003lm-4Z for emacs-devel@gnu.org; Fri, 17 Apr 2020 14:48:45 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:42387) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jPW2d-00011d-MR; Fri, 17 Apr 2020 14:48:43 -0400 Original-Received: from [176.228.60.248] (port=3962 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jPW2V-00009N-Fm; Fri, 17 Apr 2020 14:48:36 -0400 In-Reply-To: <551c7634-f614-c5a7-c089-33a0dc56574d@yandex.ru> (message from Dmitry Gutov on Fri, 17 Apr 2020 20:52:32 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:247194 Archived-At: > Cc: acm@muc.de, rudalics@gmx.at, rrandresf@gmail.com, rms@gnu.org, > emacs-devel@gnu.org > From: Dmitry Gutov > Date: Fri, 17 Apr 2020 20:52:32 +0300 > > >> 4. From time to time, you will see point jump into the middle of the > >> screen, when font-lock takes too long, apparently (or maybe it > >> corresponds to GC pauses). > >> > >> This shouldn't happen because next-line only moves by one line. > > And it doesn't. > > What doesn't? It doesn't happen when next-line only moves by one line, then stops (as opposed to continue moving by one more line). > > What happens is that Emacs is sometimes unable to > > keep up with input, so when it comes to displaying the next screenful, > > point is already more than 1 line below the window's end. So Emacs > > recenters. > > I know. But these are internal details, which shouldn't affect the > observable behavior this much. 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. That said, if you can find a way of avoiding that, by all means propose a patch, I'm sure many users will be happier. > And I'm not convinced that, if redisplay didn't happen, Emacs can't > decide that scrolling happened anyway. What do you mean by "scrolling happened"? Scrolling happens because the display engine decides to move the window-start point. But you seem to use this in some other meaning. > After all, if that was the case, then in the original problem > scenario (floor C-v, see Emacs freeze after a while), after Emacs > unfreezes, the window start would have been the same (or almost the > same) as when Emacs stopped updating the screen. What happens when Emacs "freezes" is that point moves, but the display is not updated to reflect that. When redisplay does have an opportunity to kick in, it looks at the position of point, and decides where to put the window-start given that (by default, the window-start will be half-window above the line containing point). > > That's why the special value of 101 was introduced: so that this > > recentering never happens. > > This bug basically makes lower values (which I personally would > otherwise choose to use, probably even the value of 1) frustratingly > unreliable. Larger values become more and more reliable. > Emacs clearly doesn't honor scroll-conservatively's description. The description says: Scroll up to this many lines, to bring point back on screen. If point moves off-screen, redisplay will scroll by up to ‘scroll-conservatively’ lines in order to bring point just barely onto the screen again. If that cannot be done, then redisplay recenters point as usual.^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^ So I think we are okay wrt the description. But once again, patches are welcome to improve this behavior.