From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.bugs Subject: bug#56393: Actually fix the long lines display bug Date: Thu, 07 Jul 2022 00:38:22 +0000 Message-ID: <3ffab1919622ce555e12@heytings.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> <834jzu6wnu.fsf@gnu.org> <762d224809c7a439895e@heytings.org> <83wncq5dvu.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20260"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 56393@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jul 07 02:39:24 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 1o9FYC-00056C-9v for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 07 Jul 2022 02:39:24 +0200 Original-Received: from localhost ([::1]:52256 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o9FYA-0007y7-Hh for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 06 Jul 2022 20:39:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59286) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o9FXr-0007vh-0W for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2022 20:39:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33241) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o9FXq-0003Gv-OT for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2022 20:39:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o9FXq-000606-Aw for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2022 20:39:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 07 Jul 2022 00:39:02 +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.165715430723024 (code B ref 56393); Thu, 07 Jul 2022 00:39:02 +0000 Original-Received: (at 56393) by debbugs.gnu.org; 7 Jul 2022 00:38:27 +0000 Original-Received: from localhost ([127.0.0.1]:55371 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o9FXG-0005zI-JM for submit@debbugs.gnu.org; Wed, 06 Jul 2022 20:38:26 -0400 Original-Received: from heytings.org ([95.142.160.155]:55886) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o9FXE-0005z8-PG for 56393@debbugs.gnu.org; Wed, 06 Jul 2022 20:38:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1657154302; bh=epLjM/I0KBJXGtmQtyocSFZRMEYTF/cyyFtqWZKhgK0=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=ydWI04TkwfZS9JJUkepx6okhnSqBVGdYOVcy7C6D2PmDHzZk3UI/Fmyklc785a4hh hbvFp2BBLKgiCw3UAhhwGSGz1XHHoRzigP101vB1rytcJhq1kKtWW9s3bGIJPVI68q Wfr28Q6fRRnwcN76WRi9soWEyHhMrynL4DmRc0A8Nm2klLYTl/9tETT9zCF3Q7YmP5 SxZF1VhVa+WvSLJ5O44otKso/x1PEcmmOUUtrjTQ+VS+dIFv5kf3OmiiyYC4pUmVhq UA0kiQ0Z+llFivwLdvomwsGpkYlMIcIIQ2OI48mDuNxsTizQKKpZtFovwXd90ep5LV +gHIcuUMhUSzg== In-Reply-To: <83wncq5dvu.fsf@gnu.org> 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:236306 Archived-At: > > I can help with the latter. When Emacs is about to display some chunk > of text, it checks whether the text has a non-nil 'fontified' property. > If it does, that chunk of text was already fontified, but if not, the > display engine calls font-lock (via jit-lock.el) to fontify the next > 1500 characters, and puts a non-nil 'fontified' property on those 1500 > characters. The result is face properties, which are then actually > displayed. > > So if font-lock is slow for some reason, it will slow down redisplay. > Thanks. I meant the former, but this is very useful nonetheless. It means that the Lisp code which calculates these properties is (or at least can be) a bottleneck. To determine which properties must be placed on these 1500 characters, it must presumably look further away, possibly much further away. > > I think we should understand why it becomes slow before we decide > whether to turn it off or speed it up somehow. Other editors fontify > text using very different methods, so their limitations are not > necessarily similar to ours. > We can try, yes. But my feeling so far is that this won't get us anywhere. > > Btw, what happens if you turn on jit-lock-debug-mode? > I'll try that. >> I mean, an actual example of "Lisp code that expects to have access to >> the entire buffer when it has no reason to expect narrowing", that is, >> Lisp code that expects to have access to the entire buffer without >> using (save-restriction (widen) ...). > > Are you saying that you don't believe in the existence of such code? > Every Lisp program expects to see the same narrowing (or lack thereof) > as the user sees. So anything different is a time bomb waiting to go > off. > I don't say that I don't believe in the existence of such code. I get your point, and agree that narrow-mode (ab)uses a feature in a way that it was never intended to be (ab)used. But I also say that files with extremely long lines are rare, and that it's in my opinion much better to see some rare functions fail when opening such files than to see Emacs becoming unusable. Or in other words: if all essential editing commands work on these files, that's already a big step forward. >> Yes, I've understood that you want to do something else. > > No, it's the same idea, just implemented differently, and thus without > some of the problems we are discussing. (But slowness of font-lock will > still need a separate solution -- or the conclusion that we have no > alternative but turn it off.) > I tried to do that, and so far I don't see how your alternative approach could work. The problem with long lines is not only that redisplay takes forever in some cases, it's also (and perhaps mainly) that commands take forever. With dictionary.json, with point on the last character, C-p takes (on my computer) about 26 seconds outside of redisplay. I don't see how we could tell all that code that it should work on a narrowed buffer without actually narrowing the buffer.