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

Previous Next

Full log

Message #625 received at 56682 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Tue, 02 Aug 2022 05:31:55 +0300

> Date: Tue, 2 Aug 2022 00:54:55 +0300
> Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> On 01.08.2022 15:12, Eli Zaretskii wrote:
> > But the problem here is that it isn't "people shooting themselves in
> > the foot", it's that "major modes shoot their users in the foot".
> > IOW, the ones who shoot and the ones who get shot are not the same
> > people.
> > 
> > What do you want a user to do when he/she is faced with a mode which
> > makes Emacs very slow?  Such a user cannot blame his/herself; in many
> > cases the use doesn't even know enough to realize it's the major mode
> > and its fontifications that are the culprit.
> 
> Just like we do in such cases where an Emacs feature is not optimized 
> enough for a given use case: wait for the user to realize the situation 
> can and should be improved, and file a bug report/feature request.

The intent of this activity is to make Emacs reasonably performant and
responsive in the relevant use cases without asking them to wait for
something that likely won't happen.

IOW, in this case the Emacs developers, due to long-standing bug
reports about this situation, recognized that it _can_ be improved,
albeit in slightly unorthodox ways, and have taken the measures to
optimize Emacs for the users.

Previous Next

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