GNU bug report logs - #57804
An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Pogonyshev <pogonyshev <at> gmail.com>
Cc: gregory <at> heytings.org, 57804 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes
 Emacs to hang indefinitely
Date: Fri, 16 Sep 2022 09:40:50 +0300

> From: Paul Pogonyshev <pogonyshev <at> gmail.com>
> Date: Fri, 16 Sep 2022 00:53:37 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 57804 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
> 
> > It is for example possible to parse the buffer outside of
> > fontification-functions
> 
> You are ignoring that this is not only about fontification. It can
> happen anywhere, because I may need full access to the buffer at any
> time.

Your mode is requested to be able to run in some kind of "simplified
mode" when long-line-threshold is exceeded, in a way that doesn't
require such full access.

> > Yet another method would be to use a simpler fontification method in
> > buffers with too long lines.  Yet another method would be to turn
> > font locking off in buffers with too long lines.
> 
> I don't want to lose fontification in a 10 MB buffer because one line
> somewhere there is over 10000 characters.

The locked restriction leaves accessible a region of the buffer that
is quite large.  So if you are fontifying a line that is not very long
in such a buffer, you should still be able to access enough text
before and after the window to be able to fontify.  It is expected
that modes which need to access more than that will be amended to
perform, perhaps sub-optimally, in such cases.  In extreme cases, you
can simply not fontify if there's no reasonable way of fontifying even
approximately.  (I don't believe such extreme measures should be
necessary, but they are a possibility.)

IOW, we fully expect that in some cases and with some features, there
will be partial loss of functionality in these cases.  We consider
that still much better than a locked-up Emacs that can only be killed.

> Security against what, for fuck's sake?

Language!

Previous Next

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