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: Thu, 07 Jul 2022 08:53:47 +0300 Message-ID: <83ilo95uz8.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> <834jzu6wnu.fsf@gnu.org> <762d224809c7a439895e@heytings.org> <83wncq5dvu.fsf@gnu.org> <3ffab1919622ce555e12@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31817"; 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 Thu Jul 07 07:54:34 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 1o9KTB-00088E-Io for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 07 Jul 2022 07:54:33 +0200 Original-Received: from localhost ([::1]:50376 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o9KTA-0002Md-2E for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 07 Jul 2022 01:54:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56548) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o9KSg-0002Le-PH for bug-gnu-emacs@gnu.org; Thu, 07 Jul 2022 01:54:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33397) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o9KSg-0006SK-FK for bug-gnu-emacs@gnu.org; Thu, 07 Jul 2022 01:54:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o9KSg-0005is-4d for bug-gnu-emacs@gnu.org; Thu, 07 Jul 2022 01:54:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 07 Jul 2022 05:54: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.165717324021990 (code B ref 56393); Thu, 07 Jul 2022 05:54:02 +0000 Original-Received: (at 56393) by debbugs.gnu.org; 7 Jul 2022 05:54:00 +0000 Original-Received: from localhost ([127.0.0.1]:55527 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o9KSe-0005ic-1A for submit@debbugs.gnu.org; Thu, 07 Jul 2022 01:54:00 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:43354) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o9KSc-0005iP-0z for 56393@debbugs.gnu.org; Thu, 07 Jul 2022 01:53:58 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39720) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o9KSW-0006Rh-09; Thu, 07 Jul 2022 01:53:52 -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=+81rLF2rHxbW9jDNfxSZ7BT49wCRRnPcX3KlKTOGvoQ=; b=oBX0yqJ12t4z Sww6tfv7o/uJC2v6qh3ZiylLCv457NC4FJqqtPpBWZ3LxuUi1URr7OvZDAzONhzk9nK/7bRAIWTOd tXj0YM7c8fLwhy0smFHG4LrOrCCvAIy4lUvbmZhEj0/NB7xjnHRozAjN8qM0XKQslp1So/8h8r2I2 TCRJiTG3XSXzk+cwfqqrd6Q6rmcxG89DyzX8BDxx6NQgRG3m/5skJl6l1hk5X83BZm61QOmvSi517 qcXqc+Ngq63t4RuAqCltghFt+b+ry9qOycjX4E/JePrMlf93CvNoUdC04BWcSZbrHpZPtB/MA/rBu Cb6PlYppxFCjPgKfUnhNXQ==; Original-Received: from [87.69.77.57] (port=4050 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 1o9KSV-0006dm-FQ; Thu, 07 Jul 2022 01:53:51 -0400 In-Reply-To: <3ffab1919622ce555e12@heytings.org> (message from Gregory Heytings on Thu, 07 Jul 2022 00:38:22 +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:236317 Archived-At: > Date: Thu, 07 Jul 2022 00:38:22 +0000 > From: Gregory Heytings > cc: larsi@gnus.org, 56393@debbugs.gnu.org > > > 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. That's possible, but limiting that search should in most cases still produce reasonable fontifications. At least that's the hope. > > 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. Let's see if your feeling is right, okay? > > 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. I think we should defer discussing tradeoffs until we hit a brick wall of sorts, i.e. get to the point where no significant further improvements can be made, and we understand why. The tradeoffs should be based on such an understanding, because it's not smart giving up features we could maybe have. > >> 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. C-p takes an inordinate amount of time in those cases because it calls functions of the display engine (see vertical-motion). Limiting the display code to some small enough region of the buffer will speed that up as well, since it's the same code in both cases. The somewhat tricky part with the likes of C-p is where and how to compute the restriction.