GNU bug report logs - #56682
Fix the long lines font locking related slowdowns

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
Subject: bug#56682: Fix the long lines font locking related slowdowns
Date: Sun, 14 Aug 2022 18:37:34 +0300

On 14.08.2022 16:02, Eli Zaretskii wrote:
>> Date: Sun, 14 Aug 2022 12:41:33 +0300
>> Cc:56682 <at> debbugs.gnu.org,gregory <at> heytings.org,monnier <at> iro.umontreal.ca
>> From: Dmitry Gutov<dgutov <at> yandex.ru>
>>
>>> Stuttering in redisplay (and I think you actually mean stuttering in
>>> cursor motion commands, but let's ignore that difference for now) is a
>>> known issue, but it is NOT the goal of this effort.  The goal of this
>>> effort is to avoid making Emacs_completely_unusable_  due to the need
>>> to wait for many seconds for commands to complete and their results to
>>> be shown on display.  Stuttering, while somewhat annoying, doesn't
>>> make Emacs unusable.
>>>
>>> So if you are talking about the cases of stuttering, you are focused
>>> on cases that are of no particular interest to us here.  Of course,
>>> any improvement in those other cases will also be welcome, but it is
>>> not directly related to what we are trying to do here, and may or may
>>> not solve the cases that are of interest to us.
>> They*are*  solved by Gregory's work.
> Not in all cases and not on all systems.  I still see stuttering in
> some cases, at least with my unoptimized builds, and I don't consider
> that a problem.

Point is, Gregory's work improves performance in many real-world 
scenarios, not just in rare special files.

So being able to fine-tune the behavior makes sense. Certainly not a 
"maintenance nightmare".

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.