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

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 56682 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#56682: Fix the long lines font locking related slowdowns
Date: Wed, 03 Aug 2022 16:33:24 -0400

> I'd say it is realistic, based on the observation that half of the
> programming language modes in core do use widen, which they weren't supposed
> to do.

AFAICT, most uses of widen in lisp/progmodes is *not* within code
related to font-lock (unsurprinsingly, since font-lock.el has been
widening "for ever", so widening in the major mode has always been
redundant).

> But this discussion is leading nowhere.  If you could point out to an
> actual (or even potential) problem caused by this locked narrowing,
> apart from an occasional mis-fontification, that would perhaps help it
> to advance.

If I were maintainer I'd just refuse such a change without corresponding
escape hatch, based on the experience gained over the years about how
Emacs is and should be designed.

As a package contributor I just find it offensive that the C code would
go to extra trouble in order to cut me out under the premise that "Elisp
programmers would take the habit of using (widen-unlock) instead of
(widen) in their programs", which I read as "we have to protect ELisp
contributors from themselves".

Also, I'm trying to imagine  scenario that leads to such an abuse:
- under normal circumstances, there are no long lines, so they'll never
  hit a "locked" narrowing and it will thus never occur to them to use
  a `widen-unlock`.
- when they get a bug report with a locked narrowing because of long
  lines, using `widen-unlock` naively is likely to lead to an immediate
  performance problem, so it's unlikely they'll use it.
I just don't buy it.


        Stefan

Previous Next

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