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.bugs Subject: bug#56393: Actually fix the long lines display bug Date: Wed, 06 Jul 2022 19:19:49 +0300 Message-ID: <834jzu6wnu.fsf@gnu.org> References: <38c1a31040d2d2bc47ae@heytings.org> <38c1a310405bd4bbe370@heytings.org> <87a69n98yy.fsf@yahoo.com> <38c1a31040f5546dbd3a@heytings.org> <83a69n90t8.fsf@gnu.org> <38c1a31040ad21b41adc@heytings.org> <835ykb8x3z.fsf@gnu.org> <38c1a310403dbabc7270@heytings.org> <834jzv8sv4.fsf@gnu.org> <38c1a31040ba2976eb4d@heytings.org> <83y1x77c2w.fsf@gnu.org> <87k08rkvgb.fsf@gnus.org> <38c1a31040e94458bd3d@heytings.org> <83o7y277b8.fsf@gnu.org> <762d224809bcab0d6bbc@heytings.org> <83fsje74pz.fsf@gnu.org> <762d224809bc038d2030@heytings.org> <838rp672p7.fsf@gnu.org> <762d224809114fbaf4af@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22855"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 56393@debbugs.gnu.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jul 06 18:21:30 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1o97mL-0005kw-ID for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 06 Jul 2022 18:21:29 +0200 Original-Received: from localhost ([::1]:54384 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o97mK-0001qm-88 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 06 Jul 2022 12:21:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44322) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o97lv-0001Yb-Cv for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2022 12:21:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:32808) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o97lu-0002Ny-5P for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2022 12:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o97lt-00037d-Vx for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2022 12:21:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Jul 2022 16:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56393 X-GNU-PR-Package: emacs Original-Received: via spool by 56393-submit@debbugs.gnu.org id=B56393.165712440911887 (code B ref 56393); Wed, 06 Jul 2022 16:21:01 +0000 Original-Received: (at 56393) by debbugs.gnu.org; 6 Jul 2022 16:20:09 +0000 Original-Received: from localhost ([127.0.0.1]:54938 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o97l2-00035d-Qw for submit@debbugs.gnu.org; Wed, 06 Jul 2022 12:20:09 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:59036) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o97kv-00034w-E1 for 56393@debbugs.gnu.org; Wed, 06 Jul 2022 12:20:08 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:50164) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o97kp-00024J-Ql; Wed, 06 Jul 2022 12:19:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=zu3Svp7bhCLeR5H0ewW072JnU+ATNqnZg53ySQKaAj4=; b=asUj3Cu9lHUx efsIcL6frix8GYq1uIdP9ArjJyjZhPJ70dAoGORqUo7VbqYyuTmPNEBrVoPEEH0Cvb11PvsALuxkU dXwKRizxaYUymq4gt7aykj8YZ5+lI6BV/mobTa2k3pdxzHBrI1eHkkP5pwtYWpzdIFQF1cUl6eptW ihrDjG0fyn3ihZysYry5h29XAKv2op6sJYj2cCYHQGGWuAxWdvg6+2r7B7RRtoTxf9lJfvFu9sWmB RFQ3En4ucpSHFayJcC/7D9CZ+/VmgX7bpMbFq79Il8DXuz4MFxSRHiCVW1SP1uZPxHjGZlrk6gdQy TzaGQQfUWCUgT/VBYNaX2g==; Original-Received: from [87.69.77.57] (port=2147 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o97ko-0005Hg-OW; Wed, 06 Jul 2022 12:19:55 -0400 In-Reply-To: <762d224809114fbaf4af@heytings.org> (message from Gregory Heytings on Wed, 06 Jul 2022 14:41:08 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:236271 Archived-At: > Date: Wed, 06 Jul 2022 14:41:08 +0000 > From: Gregory Heytings > cc: larsi@gnus.org, 56393@debbugs.gnu.org > > > I think we must, because font-lock is run by the display engine, and if > > font-lock makes redisplay significantly slower, it's part of the same > > problem. > > I disagree. It's not the redisplay part that make font-lock slower, but > how it parses the buffer. So it's a different problem. How is it different from the code in the display engine that calls next-single-char-property-change or remove-text-properties, or loops over all the overlays at certain position calling overlay-get? In Emacs nowadays font-lock is almost always called as part of redisplay, so I don't see how we can separate them and say that this is a different problem. > > Oh, we agree here: it's definitely way better. I'm just saying that a > > complete solution cannot force users to make such sacrifices. > > Users can reasonably expect and understand that in exceptional > circumstances a non-essential editing feature is, by default, turned off, > if the purpose of doing that is to maintain responsiveness. If you load a > very big file in a browser (or for that matter in any application), it > will become sluggish. Try to open the 1GB hugedictionay.json file with > vim, nano, VS Code, Atom, and try opening it with the patched Emacs. > > (Atom is the only one that displays a warning: "Atom will be unresponsive > during the loading of very large files. Do you still want to load this > file?" If you proceed, Atom becomes unuseable.) I invite you to look at this from a different aspect angle. Your idea is basically to present to the display engine a small portion of the buffer, whose size is 30K characters. If you actually cut 30K characters from any of the files we are using for this work, do you see Emacs choking on any of them if you don't turn off font-lock and leave 'recenter' as it behaves on master? If not, then why doesn't the same work with auto-narrow-mode? And if a 30K-character cut is still clunky, then maybe 30K is not the right default value? For example, why not use 2 window-fulls before and after the window (assuming that gives us a smaller chunk)? The point is that we should try to squeeze the most out of this narrowing idea, before we start disabling up features. Because disabling features is a kind of retreat, an indication that we turned every stone and couldn't make Emacs fast enough, so we are kinda giving up. And it's too early to give up, IMO. > > Why is 'recenter' at all relevant, btw? It isn't called by the display > > code, AFAIR, so why do we have to disable it? > > Because commands in auto-narrow-widen-automatically might call "recenter" > for aesthetic purposes. One example is end-of-buffer. Which means that > what you have is (progn (widen) (recenter)), which takes a few seconds > without fundamentally changing what is on display. That's what I thought. And to me this means that you see an example of a problem I mentioned earlier: code from the display engine is used in commands that basically have nothing to do with redisplay per se, and your current implementation doesn't take care of those calls into the display code by commands like recenter, C-v, C-n, etc. I think sooner or later we will need to present a narrowed buffer to them as well. > > I think there's a misunderstanding here: what these Lisp programs don't > > expect is to find narrowing that is different from what the user sees or > > expects top have. Narrowing is largely a user-level feature, so using > > it for internal purposes is problematic at best. > > > > Sorry, I don't get what you mean. Do you have a concrete example of a > problematic function? What kind of example do you want to see? What do you mean by "problematic" in this context? > A Lisp program that takes into account the possibility that the user uses > narrowing and that needs to have access to the whole buffer will use > (save-restriction (widen) ...). A Lisp program that requires the user to > narrow the buffer to work properly will still work, because explicit > narrowing can still be used with auto-narrow mode. What are the remaining > possibilities? When the user narrows the buffer, he/she doesn't expect the parts outside the restriction to be accessible. But when the user didn't narrow, the results of having some part of a command being able to access only 30K around point _will_ surprise users. Which is why I'm saying that it is better to restrict the display code via some other means, and leave the narrowing alone. After all, it is our code that deliberately references BEGV and ZV in the display engine, so using some other values shouldn't be that difficult, I think.