From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov 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 20:09:04 +0300 Message-ID: <3ddcec07-079f-18e8-81a7-76eaf9a8187a@yandex.ru> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="126042"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 Cc: acm@muc.de, rrandresf@gmail.com, emacs-devel@gnu.org, rms@gnu.org, rudalics@gmx.at To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 19 19:09:58 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 1jQDSA-000WfG-HW for ged-emacs-devel@m.gmane-mx.org; Sun, 19 Apr 2020 19:09:58 +0200 Original-Received: from localhost ([::1]:45760 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQDS9-00088b-HL for ged-emacs-devel@m.gmane-mx.org; Sun, 19 Apr 2020 13:09:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52556 helo=eggs1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jQDRO-0007eg-Vu for emacs-devel@gnu.org; Sun, 19 Apr 2020 13:09:11 -0400 Original-Received: from Debian-exim by eggs1p.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jQDRO-000510-7I for emacs-devel@gnu.org; Sun, 19 Apr 2020 13:09:10 -0400 Original-Received: from mail-wm1-x331.google.com ([2a00:1450:4864:20::331]:53925) by eggs1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jQDRN-00050E-Qb; Sun, 19 Apr 2020 13:09:09 -0400 Original-Received: by mail-wm1-x331.google.com with SMTP id t63so7248348wmt.3; Sun, 19 Apr 2020 10:09:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ceK9yp3JW/A+I3mQrfLseMxE8+e4LQXsjXyC3Kz6DLI=; b=nnn+XPBVherdznGSyYIT7eQ5KW1IPqBmW6r8b0ToAhQLCe6DHAiOc5m2IyI9AF9MwQ c+6jYMEJ1wGdZ6HpohAWXVOTox8CUbw6DJZ8OUUxnKIC16m2JKazRzitLOLtYYPUM06/ Fdx1cO8SMIMoOm6t8TFbItecSz+90EByuYqrcjQrwTF3aYMgkLS0hp3LFlfJgWnZbVK+ WybgraRUdEV+FCRBRxkj9Yfn2JsG/UUMRX5h3Ld0lrv16XrHFjDyqJT2XzMZVFElwevI P/EmuAa5uvfUvUShXEtGWTkgnKbnQYHuVjmCK+Pwr4lEefkmdGXNWb124Um1AdOTBAUS q30A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ceK9yp3JW/A+I3mQrfLseMxE8+e4LQXsjXyC3Kz6DLI=; b=Gcqf7jQUjBudSJFYjybLQ0iQWJw6lopIvZ+6xk6XRn9qY5UK+5TU3KLSFDkfsxYMcg P4+w8g0eQ5X+K4gPbvl8IeaVBqGlObqTgdHoGSuVlOnQM50ZcYpgPupiRN3lNz/pQJWH mA2zufdx6h5Nh60C42dWvvjoYajvNwxNVXPc7hWuMGClKAeCjTa9LspQfW5S8YaPZjlj Jw1CWkYiob4hKC3qqjvIeQqfdWXM5kob7tTvVvuJG+Ys2bYF98XqjEnbMZYvJ7AlRcK3 ab3b4XfVETQaLQpcAKpT4aAvFyvi+WolH2HcLVCWT9mSCgWQkZMHeKgy8yWnDF1DlWQV 2ICg== X-Gm-Message-State: AGi0PuZnWkgTfQySryodoAfGzgYtlu3liPGiVs5k/VHtEWAJN9Aw3LB/ DIDrAfbn5E/+XrVqiTjGRvlfHMVWXpk= X-Google-Smtp-Source: APiQypLo2tlQiTrlDnQsTgnAhOMb6Xrg1xvqbgzJbDQeluPwqq7fCQ7kSE4cc1ZDnnSdtPAPDnOKXA== X-Received: by 2002:a1c:7215:: with SMTP id n21mr14112069wmc.145.1587316147075; Sun, 19 Apr 2020 10:09:07 -0700 (PDT) Original-Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id z16sm43214224wrl.0.2020.04.19.10.09.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Apr 2020 10:09:06 -0700 (PDT) In-Reply-To: <83imhyaqyw.fsf@gnu.org> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::331; envelope-from=raaahh@gmail.com; helo=mail-wm1-x331.google.com X-detected-operating-system: by eggs1p.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::331 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:247319 Archived-At: On 17.04.2020 21:48, Eli Zaretskii wrote: >>>> 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). 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. One that's not obvious to the casual user. And even many advanced ones, I'm fairly sure. >>> 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. It seems that scrolling is rather coupled to redisplay, however. Which is something I've never been aware of in the many years of using Emacs. There are different directions in which that could be changed, but maybe this one could be improved without changing the architecture. > 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. The current implementation is too rich for my blood (starting with no documentation for try_scrolling's arguments). But here's the idea: 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.