GNU bug report logs - #56637
28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 56637 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, yantar92 <at> gmail.com
Subject: Re: bug#56637: 28.1.90;
 [FR] Allow a way around font-lock-mode being unconditionally disabled
 in " *hidden*" buffers
Date: Sat, 23 Jul 2022 11:55:05 +0300

> Cc: 56637 <at> debbugs.gnu.org, Ihor Radchenko <yantar92 <at> gmail.com>
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Sat, 23 Jul 2022 09:53:55 +0200
> 
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> 
> >> Sorry, it is a typo. I did mean "the fontification *is* using
> >> (font-lock-ensure)".
> >
> > Ah, good, thanks.
> >
> >> We do use `font-lock-ensure', but it does not always produce the same
> >> results with/without font-lock-mode enabled.
> >
> > I'm not completely surprised, because I remember when writing
> > `font-lock-ensure` that there are many corner cases some of which seem
> > very difficult to fix without actually enabling `font-lock-mode`, but we
> > should still strive to be "as close as possible", so ... do you have
> > a bug report with some concrete cases we could try to fix?
> 
> Would it make sense to make `font-lock-ensure' try harder here, and
> (temporarily) force font-lock mode on (even in temporary buffers) if it
> isn't already?

That could be a good alternative, yes.  We could even add a new
optional argument for that, if it makes sense to allow controlling
this behavior.

Previous Next

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