GNU logs - #56637, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 19 Jul 2022 04:15:02 +0000
Resent-Message-ID: <handler.56637.B.165820407530197 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 56637 <at> debbugs.gnu.org
From: Ihor Radchenko <yantar92@HIDDEN>
Date: Tue, 19 Jul 2022 12:15:33 +0800
Message-ID: <874jzdhh5m.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=2607:f8b0:4864:20::1035;
 envelope-from=yantar92@HIDDEN; helo=mail-pj1-x1035.google.com
X-Spam_score_int: -18
X-Spam_score: -1.9
X-Spam_bar: -
X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.1 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.1 (--)

Hi,

font-lock-mode contains the follow clause:

  ;; Don't turn on Font Lock mode if we don't have a display (we're running a
  ;; batch job) or if the buffer is invisible (the name starts with a space).
  (when (or noninteractive (eq (aref (buffer-name) 0) ?\s))
    (setq font-lock-mode nil))

which interferes with Org mode's fontification code in some edge cases.

Org mode fontifies code blocks using "hidden" temporary buffers with
their name starting from " ": " *org-src-fontification:major-mode*".

The buffers are kept around to avoid extra major-mode loading overheads
and the fontification is not using (font-lock-ensure).

(font-lock-ensure) usually fontifies the buffer correctly even though
font-lock-mode is disabled. However, not always.

We just got some edge case
https://teddit.net/r/orgmode/comments/w2b0tw/syntax_highlighting_in_orgsource_blocks/igqdx18/
with web-mode, which directly sets 'font-lock-face text properties.

Without font-lock-mode being enabled, 'font-lock-face is not
automatically remapped to 'face text property and hence some part of the
fontification may not be reflected by simply looking into 'face
property.

While Org can work around this particular case by looking into
'font-lock-face, I am not sure if disabled font-lock may not trigger
similar issues in other cases.

It would be nice if we could somehow enable font-lock inside " *hidden*"
buffers. Would it be possible?

Best,
Ihor

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Ihor Radchenko <yantar92@HIDDEN>
Subject: bug#56637: Acknowledgement (28.1.90; [FR] Allow a way around
 font-lock-mode being unconditionally disabled in " *hidden*" buffers)
Message-ID: <handler.56637.B.165820407530197.ack <at> debbugs.gnu.org>
References: <874jzdhh5m.fsf@localhost>
X-Gnu-PR-Message: ack 56637
X-Gnu-PR-Package: emacs
Reply-To: 56637 <at> debbugs.gnu.org
Date: Tue, 19 Jul 2022 04:15:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 56637 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
56637: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D56637
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 19 Jul 2022 12:57:01 +0000
Resent-Message-ID: <handler.56637.B56637.165823538221342 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Ihor Radchenko <yantar92@HIDDEN>, Stefan Monnier <monnier@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org
Date: Tue, 19 Jul 2022 15:55:59 +0300
Message-Id: <837d49ntwg.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <874jzdhh5m.fsf@localhost> (message from Ihor Radchenko on Tue,
 19 Jul 2022 12:15:33 +0800)
References: <874jzdhh5m.fsf@localhost>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> From: Ihor Radchenko <yantar92@HIDDEN>
> Date: Tue, 19 Jul 2022 12:15:33 +0800
> 
> font-lock-mode contains the follow clause:
> 
>   ;; Don't turn on Font Lock mode if we don't have a display (we're running a
>   ;; batch job) or if the buffer is invisible (the name starts with a space).
>   (when (or noninteractive (eq (aref (buffer-name) 0) ?\s))
>     (setq font-lock-mode nil))
> 
> which interferes with Org mode's fontification code in some edge cases.
> 
> Org mode fontifies code blocks using "hidden" temporary buffers with
> their name starting from " ": " *org-src-fontification:major-mode*".
> 
> The buffers are kept around to avoid extra major-mode loading overheads
> and the fontification is not using (font-lock-ensure).
> 
> (font-lock-ensure) usually fontifies the buffer correctly even though
> font-lock-mode is disabled. However, not always.
> 
> We just got some edge case
> https://teddit.net/r/orgmode/comments/w2b0tw/syntax_highlighting_in_orgsource_blocks/igqdx18/
> with web-mode, which directly sets 'font-lock-face text properties.
> 
> Without font-lock-mode being enabled, 'font-lock-face is not
> automatically remapped to 'face text property and hence some part of the
> fontification may not be reflected by simply looking into 'face
> property.
> 
> While Org can work around this particular case by looking into
> 'font-lock-face, I am not sure if disabled font-lock may not trigger
> similar issues in other cases.
> 
> It would be nice if we could somehow enable font-lock inside " *hidden*"
> buffers. Would it be possible?

Depends on the "somehow" part.  I generally prefer that obscure corner
cases be solved in the software which creates those obscure cases.  In
this case, it seems like web-mode is that place?  I'm not sure why
you say Org should solve this, but perhaps I didn't understand the
description well enough.  But if this indeed needs to be solved in
Org, how about not using buffers whose names begin with a space?

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 19 Jul 2022 16:14:02 +0000
Resent-Message-ID: <handler.56637.B56637.165824722311936 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <874jzdhh5m.fsf@localhost> (Ihor Radchenko's message of "Tue, 19
 Jul 2022 12:15:33 +0800")
Message-ID: <jwvzgh5m6fq.fsf-monnier+emacs@HIDDEN>
References: <874jzdhh5m.fsf@localhost>
Date: Tue, 19 Jul 2022 12:13:29 -0400
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> Org mode fontifies code blocks using "hidden" temporary buffers with
> their name starting from " ": " *org-src-fontification:major-mode*".
>
> The buffers are kept around to avoid extra major-mode loading overheads
> and the fontification is not using (font-lock-ensure).

IIUC they're never displayed, right?  So, `font-lock-ensure` does sound
like "the right tool".  Could you give a short explanation for why you
don't use `font-lock-ensure`?

> (font-lock-ensure) usually fontifies the buffer correctly even though
> font-lock-mode is disabled. However, not always.

Sounds like a bug we should fix.

> It would be nice if we could somehow enable font-lock inside " *hidden*"
> buffers.  Would it be possible?

FWIW, I do think it would be good to remove the rule that font-lock is
never enabled in temp buffers.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 19 Jul 2022 16:37:02 +0000
Resent-Message-ID: <handler.56637.B56637.165824861014355 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org, yantar92@HIDDEN
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.165824861014355
          (code B ref 56637); Tue, 19 Jul 2022 16:37:02 +0000
Received: (at 56637) by debbugs.gnu.org; 19 Jul 2022 16:36:50 +0000
Received: from localhost ([127.0.0.1]:55068 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oDqDJ-0003jS-M7
	for submit <at> debbugs.gnu.org; Tue, 19 Jul 2022 12:36:49 -0400
Received: from eggs.gnu.org ([209.51.188.92]:51948)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1oDqDH-0003jD-JR
 for 56637 <at> debbugs.gnu.org; Tue, 19 Jul 2022 12:36:48 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:38472)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1oDqDC-0007CW-0J; Tue, 19 Jul 2022 12:36:42 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=4EI2eFOwxucQByrogWhxoeyd3Hz8TNPBBX3gb4DZi/0=; b=jFkVQ4Ydysnu
 zBT3qzXMN9vrkDXqWVwu5ubthUtrkeqecmpSOyOqzOL7yQeD7+RmnZ1GcIo9Jz6Qs5ywQwkXxqD2d
 LN5oJKq0kzAlB3ohaLYbD0Gx68oFBPxU9J/hvOu171DYU3qqRw52ab/WILGLk69hdDfYrifwwm5AA
 Omg1q3yDL0wHamKtAeKapw2mH3qscqqIinBTe/7/y7gv4GJ0zNBbOjzz9lhttw559tx+UE+oBdHk9
 fI2Y45l4JhYjK/NnQhkdAyz2EVVHLkjgFCvrqBC/v4s7fIlHdodcy03qOEOkjhdPUchFa/67BjP0q
 4+4vg3C991lL+vE8vn+N/Q==;
Received: from [87.69.77.57] (port=3065 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1oDqDB-0007AI-Cw; Tue, 19 Jul 2022 12:36:41 -0400
Date: Tue, 19 Jul 2022 19:36:30 +0300
Message-Id: <83mtd5m54h.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwvzgh5m6fq.fsf-monnier+emacs@HIDDEN> (bug-gnu-emacs@HIDDEN)
References: <874jzdhh5m.fsf@localhost> <jwvzgh5m6fq.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: 56637 <at> debbugs.gnu.org
> Date: Tue, 19 Jul 2022 12:13:29 -0400
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
> 
> FWIW, I do think it would be good to remove the rule that font-lock is
> never enabled in temp buffers.

I don't.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 19 Jul 2022 17:02:02 +0000
Resent-Message-ID: <handler.56637.B56637.165825011416871 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org, yantar92@HIDDEN
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.165825011416871
          (code B ref 56637); Tue, 19 Jul 2022 17:02:02 +0000
Received: (at 56637) by debbugs.gnu.org; 19 Jul 2022 17:01:54 +0000
Received: from localhost ([127.0.0.1]:55083 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oDqbY-0004O2-PP
	for submit <at> debbugs.gnu.org; Tue, 19 Jul 2022 13:01:53 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:56592)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1oDqbS-0004Nh-P0
 for 56637 <at> debbugs.gnu.org; Tue, 19 Jul 2022 13:01:50 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 20B6B802B3;
 Tue, 19 Jul 2022 13:01:41 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 923C88025B;
 Tue, 19 Jul 2022 13:01:39 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1658250099;
 bh=17IF3A27f5fVNdfNjiQ2EJzQuaGUDJ97loSj+AaQI+w=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=JZ/d/6LRb49mKQsvrmUQmp+/OpENbYpSNFogyg8T1hsNGizMHf1yU4iWI2fGjBdUq
 6UB2OaU6oDzRG9ToWaVGK/WKO5TtlYzIvv0UmcXQR/iTfKZ+NfIEmC5BAD+igJescG
 y0k+CWwSYG6Eft4zXKutUm/xINRhcP0Rt9hsNXrwRYXg7a4WCp4sk0y24BmlUumgIw
 tbUWEHAtsZwheHic0G7F7zLoQrCV/cX9SoPuTb8oqvKO5ry79ek/DVxWxnWhzZ5PRh
 ev8gFfGZeqXzBw9/YjfW2FILszjnu99LVKkS/zwB/E3c2x21RffnOsKxWM3PXrb4uK
 HDatpp7CcUUlw==
Received: from pastel (unknown [45.72.196.165])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5546912020A;
 Tue, 19 Jul 2022 13:01:39 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <83mtd5m54h.fsf@HIDDEN> (Eli Zaretskii's message of "Tue, 19 Jul
 2022 19:36:30 +0300")
Message-ID: <jwvy1wpkpt7.fsf-monnier+emacs@HIDDEN>
References: <874jzdhh5m.fsf@localhost> <jwvzgh5m6fq.fsf-monnier+emacs@HIDDEN>
 <83mtd5m54h.fsf@HIDDEN>
Date: Tue, 19 Jul 2022 13:01:38 -0400
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.059 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> FWIW, I do think it would be good to remove the rule that font-lock is
>> never enabled in temp buffers.
> I don't.

I think we agree :-)

More seriously, I didn't mean to remove it willy-nilly, but that it's
a desirable goal and the question is how to get there.

We could start by adding a new variable
`font-lock-allow-in-temporary-buffer`, which packages could set
buffer-locally in those rare temp buffers where they do want to enable
font-lock, as in the untested patch below.

Of course, the problem in `font-lock-ensure` is orthogonal to this.


        Stefan


diff --git a/lisp/font-core.el b/lisp/font-core.el
index f92d1e38306..f74d1d854a0 100644
--- a/lisp/font-core.el
+++ b/lisp/font-core.el
@@ -78,6 +78,13 @@ font-lock-function
 ;; The mode for which font-lock was initialized, or nil if none.
 (defvar font-lock-major-mode)
 
+(defvar-local font-lock-allow-in-temporary-buffer nil
+  "If non-nil, override the temp-buffer limitation.
+Normally `font-lock-mode' cannot be enabled in buffers never intended
+to be displayed (i.e. temp buffers and batch mode).
+Set this variable to non-nil in those rare buffers where `font-lock-mode'
+is needed even though they'll never be displayed.")
+
 (define-minor-mode font-lock-mode
   "Toggle syntax highlighting in this buffer (Font Lock mode).
 
@@ -131,13 +138,14 @@ font-lock-mode
   :after-hook (font-lock-initial-fontify)
   ;; Don't turn on Font Lock mode if we don't have a display (we're running a
   ;; batch job) or if the buffer is invisible (the name starts with a space).
-  (when (or noninteractive (eq (aref (buffer-name) 0) ?\s))
+  (when (and (or noninteractive (eq (aref (buffer-name) 0) ?\s))
+             (not font-lock-allow-in-temporary-buffers))
     (setq font-lock-mode nil))
   (funcall font-lock-function font-lock-mode)
   ;; Arrange to unfontify this buffer if we change major mode later.
   (if font-lock-mode
-      (add-hook 'change-major-mode-hook 'font-lock-change-mode nil t)
-    (remove-hook 'change-major-mode-hook 'font-lock-change-mode t)))
+      (add-hook 'change-major-mode-hook #'font-lock-change-mode nil t)
+    (remove-hook 'change-major-mode-hook #'font-lock-change-mode t)))
 
 ;; Get rid of fontification for the old major mode.
 ;; We do this when changing major modes.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 19 Jul 2022 18:06:02 +0000
Resent-Message-ID: <handler.56637.B56637.165825394723012 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org, yantar92@HIDDEN
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.165825394723012
          (code B ref 56637); Tue, 19 Jul 2022 18:06:02 +0000
Received: (at 56637) by debbugs.gnu.org; 19 Jul 2022 18:05:47 +0000
Received: from localhost ([127.0.0.1]:55122 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oDrbP-0005z4-4p
	for submit <at> debbugs.gnu.org; Tue, 19 Jul 2022 14:05:47 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:15582)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1oDrbM-0005yj-TU
 for 56637 <at> debbugs.gnu.org; Tue, 19 Jul 2022 14:05:45 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 37FC98067B;
 Tue, 19 Jul 2022 14:05:39 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B79F98025B;
 Tue, 19 Jul 2022 14:05:37 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1658253937;
 bh=1lzQGIKkhBWe9witV/r9sjt37/J+PP+uDBz2S+Dtdcs=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=KCU69hbpPMdduLUOsyR3clraMNRYfxdR2guMV2abSb1VfZvNmVDDbkm3w72Td7k4x
 ZdIYCT3ZeRoVyosvLuBLJLbSudIjicc6ZIdwCybVAn74qr4/F+jUSKCmPtsf2bKpbX
 BHmGUFqPGJsSKoH4Q9KeYoWAld/aNGSXHa/n1BJVRVK8oa+2vEE0cDkSfQ0oyZ29v+
 h164OxhjoZ7gy/1zVuT5QhkcFaofHNNLcyymBQJjjwEIYlttFeJ9l90UwYTCqmtYyn
 UdBy1+7tBa5J/30qXaOXcIzVoADKsj9ypd8TQUwdtOBnGm9Ql9PJwnWS+p67LSa0x8
 r1MQ7uq6yNOWQ==
Received: from pastel (unknown [45.72.196.165])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8A9931204B7;
 Tue, 19 Jul 2022 14:05:37 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwvy1wpkpt7.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
 of "Tue, 19 Jul 2022 13:01:38 -0400")
Message-ID: <jwvr12hkmu4.fsf-monnier+emacs@HIDDEN>
References: <874jzdhh5m.fsf@localhost> <jwvzgh5m6fq.fsf-monnier+emacs@HIDDEN>
 <83mtd5m54h.fsf@HIDDEN> <jwvy1wpkpt7.fsf-monnier+emacs@HIDDEN>
Date: Tue, 19 Jul 2022 14:05:36 -0400
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.059 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> More seriously, I didn't mean to remove it willy-nilly, but that it's
> a desirable goal and the question is how to get there.

Of course, for that we need to know what effect this code has in
practice, so I tried the patch below a the first few messages I got
were:

    Enabling font-lock for mode minibuffer-inactive-mode in hidden buffer #<buffer  *Minibuf-0*>
    Enabling font-lock for mode fundamental-mode in hidden buffer #<buffer  *load*>
    Enabling font-lock for mode fundamental-mode in hidden buffer #<buffer  *Echo Area 0*>
    Enabling font-lock for mode fundamental-mode in hidden buffer #<buffer  *Echo Area 1*>
    Enabling font-lock for mode fundamental-mode in hidden buffer #<buffer  *load*-628722>
    Enabling font-lock for mode checkdoc-output-mode in hidden buffer #<buffer  *checkdoc-temp*>
    Enabling font-lock for mode minibuffer-mode in hidden buffer #<buffer  *Minibuf-1*>
    Enabling font-lock for mode minibuffer-inactive-mode in hidden buffer #<buffer  *Minibuf-0*>
    Enabling font-lock for mode minibuffer-inactive-mode in hidden buffer #<buffer  *Minibuf-1*>

Maybe it would be mostly "harmless" to enable font-lock in those buffers/modes,
but even if it is, it would clearly be wasteful.

Side note: the *checkdoc-temp* seems like an odd case.  Its major mode is
clearly designed for a "normal/visible" buffer (and IIUC it is indeed
used in buffers that are displayed), so I'm not sure how *checkdoc-temp*
ends up using that mode.


        Stefan


diff --git a/lisp/font-core.el b/lisp/font-core.el
index f92d1e38306..5678ab22da5 100644
--- a/lisp/font-core.el
+++ b/lisp/font-core.el
@@ -132,12 +132,15 @@ font-lock-mode
   ;; Don't turn on Font Lock mode if we don't have a display (we're running a
   ;; batch job) or if the buffer is invisible (the name starts with a space).
   (when (or noninteractive (eq (aref (buffer-name) 0) ?\s))
-    (setq font-lock-mode nil))
+    ;; (setq font-lock-mode nil)
+    (when font-lock-mode
+      (message "Enabling font-lock for mode %S in hidden buffer %S"
+               major-mode (current-buffer))))
   (funcall font-lock-function font-lock-mode)
   ;; Arrange to unfontify this buffer if we change major mode later.
   (if font-lock-mode
-      (add-hook 'change-major-mode-hook 'font-lock-change-mode nil t)
-    (remove-hook 'change-major-mode-hook 'font-lock-change-mode t)))
+      (add-hook 'change-major-mode-hook #'font-lock-change-mode nil t)
+    (remove-hook 'change-major-mode-hook #'font-lock-change-mode t)))
 
 ;; Get rid of fontification for the old major mode.
 ;; We do this when changing major modes.
@@ -270,7 +273,7 @@ global-font-lock-mode
   font-lock-mode turn-on-font-lock-if-desired
   ;; What was this :extra-args thingy for?  --Stef
   ;; :extra-args (dummy)
-  :initialize 'custom-initialize-delay
+  :initialize #'custom-initialize-delay
   :init-value (not (or noninteractive emacs-basic-display))
   :group 'font-lock
   :version "22.1")

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 19 Jul 2022 19:03:01 +0000
Resent-Message-ID: <handler.56637.B56637.165825735228497 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org, yantar92@HIDDEN
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.165825735228497
          (code B ref 56637); Tue, 19 Jul 2022 19:03:01 +0000
Received: (at 56637) by debbugs.gnu.org; 19 Jul 2022 19:02:32 +0000
Received: from localhost ([127.0.0.1]:55152 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oDsUJ-0007PZ-Kk
	for submit <at> debbugs.gnu.org; Tue, 19 Jul 2022 15:02:31 -0400
Received: from eggs.gnu.org ([209.51.188.92]:43084)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1oDsUF-0007PH-6M
 for 56637 <at> debbugs.gnu.org; Tue, 19 Jul 2022 15:02:30 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:41936)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1oDsU9-0002ck-UW; Tue, 19 Jul 2022 15:02:21 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=5RVZp3e7fPX4YG81TXa8x0+io3a1NmLjurTwfVlKUKU=; b=GHUFx7YwFyNC
 /tHRe460GfS0V0nZSccKXLl3lzZ2QCpIHAr0ISo+qb4jBwZG8eYNVJDN8XD6pwWS+nZU/FKNmc1b1
 hQ3CWbOYa+TIpaJGPlmDWXeGC47a/loCbyvllvqALuS1WQSagRO8sHt+K3INCid745Wa4yFarezpV
 N/3AvDaAVOXmAyGUVAEgNL88FduVr/qtNzANhdib21Galz/TJr4wyPUzJhLKudgwKKI80nUr5mk59
 2m/eCk4ErKt2qC2OnJ/rsQjxpYgY6b1iK24xBl8KWz6zWvYNLAJ48hkeqUfWEOAW4DodKBBFY3M6h
 dOS9DO+41qVSOQEzMSWE5g==;
Received: from [87.69.77.57] (port=4003 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1oDsU6-0006pw-Th; Tue, 19 Jul 2022 15:02:20 -0400
Date: Tue, 19 Jul 2022 22:02:04 +0300
Message-Id: <83ilntlydv.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwvy1wpkpt7.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Tue, 19 Jul 2022 13:01:38 -0400)
References: <874jzdhh5m.fsf@localhost> <jwvzgh5m6fq.fsf-monnier+emacs@HIDDEN>
 <83mtd5m54h.fsf@HIDDEN> <jwvy1wpkpt7.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: yantar92@HIDDEN,  56637 <at> debbugs.gnu.org
> Date: Tue, 19 Jul 2022 13:01:38 -0400
> 
> >> FWIW, I do think it would be good to remove the rule that font-lock is
> >> never enabled in temp buffers.
> > I don't.
> 
> I think we agree :-)
> 
> More seriously, I didn't mean to remove it willy-nilly, but that it's
> a desirable goal and the question is how to get there.

Why is that a desirable goal?  It slows down stuff that is never
displayed.  And if that buffer has very long lines, it slows Emacs
down considerably.  I see no reason whatsoever to pay this price, let
alone the garbage font-lock generates.

From my POV, this has "non-starter" written all over it.

> We could start by adding a new variable
> `font-lock-allow-in-temporary-buffer`, which packages could set
> buffer-locally in those rare temp buffers where they do want to enable
> font-lock, as in the untested patch below.

This is a slippery slope.  Next some other corner case will want to
run buffer-modification hooks in a temporary buffer, so we invent
another variable, and so on and so forth.

I'd rather introduce a macro like with-temp-buffer, but one that can
accept a buffer name, and ask such applications to please name their
temporary buffers something that doesn't begin with a space.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 19 Jul 2022 19:22:02 +0000
Resent-Message-ID: <handler.56637.B56637.165825849530388 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org, yantar92@HIDDEN
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.165825849530388
          (code B ref 56637); Tue, 19 Jul 2022 19:22:02 +0000
Received: (at 56637) by debbugs.gnu.org; 19 Jul 2022 19:21:35 +0000
Received: from localhost ([127.0.0.1]:55176 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oDsmk-0007u4-Jw
	for submit <at> debbugs.gnu.org; Tue, 19 Jul 2022 15:21:34 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:3106)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1oDsmi-0007to-1C
 for 56637 <at> debbugs.gnu.org; Tue, 19 Jul 2022 15:21:33 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4F05A10012E;
 Tue, 19 Jul 2022 15:21:26 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2972C100102;
 Tue, 19 Jul 2022 15:21:24 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1658258484;
 bh=G1pHpHQguQ17hEHsN8aBnkB0akOA2PkUxw1zwc0s5XY=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=ULsHYix4iuE6WPa2o370NsFSVW4d2Aknc+kkzm8SDrIg+MPkRqCDGM8tAfnq7nwWI
 xryutmGN22sMB3zCbO2/bsvyYKcvHto4WyF3iybC9povR3JqvqVMEIlPOmsJ33wL71
 Az/sHiryuw7lqKK3gzPo+buqp1P/jUapQEgsWqXrZswSPDnGV5IokgvhhdnRp+KH6u
 fhDiarGUz+7NremjjgFPneoql6pc/Ie3NZ2hfpolDTev+DecIqjyOo5axYnJX4bhI2
 KMOIX9GmdlVlVTVvffqdbGnieD7NdYDbQ3gXFpcnAk2I4k2U03I3kxa/UrDyxycI6a
 FNP1Xgs1tjtOg==
Received: from pastel (unknown [45.72.196.165])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id DF30512013E;
 Tue, 19 Jul 2022 15:21:23 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <83ilntlydv.fsf@HIDDEN> (Eli Zaretskii's message of "Tue, 19 Jul
 2022 22:02:04 +0300")
Message-ID: <jwvedyglxzl.fsf-monnier+emacs@HIDDEN>
References: <874jzdhh5m.fsf@localhost> <jwvzgh5m6fq.fsf-monnier+emacs@HIDDEN>
 <83mtd5m54h.fsf@HIDDEN> <jwvy1wpkpt7.fsf-monnier+emacs@HIDDEN>
 <83ilntlydv.fsf@HIDDEN>
Date: Tue, 19 Jul 2022 15:21:22 -0400
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.050 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> >> FWIW, I do think it would be good to remove the rule that font-lock is
>> >> never enabled in temp buffers.
>> > I don't.
>> I think we agree :-)
>> More seriously, I didn't mean to remove it willy-nilly, but that it's
>> a desirable goal and the question is how to get there.
> Why is that a desirable goal?

Because testing `noninteractive` and the presence of a leading space are
just heuristics and they aren't quite right.  IOW it's a handy hack but
it's just a hack.

> It slows down stuff that is never displayed.

That's why I say that we shouldn't do it "willy-nilly".

> And if that buffer has very long lines, it slows Emacs down considerably.

I think currently it should basically never be the case, because the
actual fontification (the part which pays attention to lines) only
happens via jit-lock, which should never trigger if those buffers
aren't displayed.

Also, most of those buffers have no font-lock rules installed so
(font-lock-specified-p mode) should return nil and
`font-lock-default-function` won't call `font-lock-mode-internal`.

But yes, if we do it naively, we'll surely bump into corner cases where
there happens to be font-lock rules setup and where jit-lock is disabled
for some reason, or something else ends up causing some of the font-lock
machinery to be run.

Or maybe just running font-lock's setup code itself ends up too costly
for some reason.

>> We could start by adding a new variable
>> `font-lock-allow-in-temporary-buffer`, which packages could set
>> buffer-locally in those rare temp buffers where they do want to enable
>> font-lock, as in the untested patch below.
> This is a slippery slope.  Next some other corner case will want to
> run buffer-modification hooks in a temporary buffer, so we invent
> another variable, and so on and so forth.

Hmm... we do run buffer-modification hooks in temp buffers.

> I'd rather introduce a macro like with-temp-buffer, but one that can
> accept a buffer name, and ask such applications to please name their
> temporary buffers something that doesn't begin with a space.

The purpose of the leading space, AFAIK is to avoid displaying the
buffer in `read-buffer`.  Forcing those buffers to appear in
`read-buffer` just because we need to run font-lock in there
sounds wrong.

If you don't like `font-lock-allow-in-temporary-buffer`, we could have
a new function `font-lock-enable-unconditionally` which does the same as
`font-lock-mode` but skips the (or noninteractive (eq (aref
(buffer-name) 0) ?\s)) test.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 19 Jul 2022 19:33:02 +0000
Resent-Message-ID: <handler.56637.B56637.165825915731538 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org, yantar92@HIDDEN
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.165825915731538
          (code B ref 56637); Tue, 19 Jul 2022 19:33:02 +0000
Received: (at 56637) by debbugs.gnu.org; 19 Jul 2022 19:32:37 +0000
Received: from localhost ([127.0.0.1]:55201 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oDsxR-0008Cb-1D
	for submit <at> debbugs.gnu.org; Tue, 19 Jul 2022 15:32:37 -0400
Received: from eggs.gnu.org ([209.51.188.92]:49662)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1oDsxP-0008CQ-U1
 for 56637 <at> debbugs.gnu.org; Tue, 19 Jul 2022 15:32:36 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:42414)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1oDsxJ-0007SZ-Th; Tue, 19 Jul 2022 15:32:29 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=z8b5+8SU1pnfq34WumF00sKXv4vGt5nix0uwNFT5Yqs=; b=CSHVjNtIF+IF
 YbimNxa3ka332ItxMujCUXRj4oehNlqNRFIc+cqEJvbff/OoZ+1FCoh5ZdUK9ZpdSOSxq9vmo+En+
 Rp9/tdeWjiSSuPmMb7N/+NDQ/dWGsBu6w0H28tBJbLqr/o8bZtzHq3ENigIZz8vDDPnFqno/eNXn1
 8viLeL8qD9Bnh5txFCwYaCii/grE5Zzj+51Ql7pBCkcjXQxGUlixP53s5H2ow4rUdKDcyn3oKA9ST
 TLd4Ele41/s6/kreW2yj8OIbv60jL5GPnVXkp27HcgzF4xbyD4W2+FbN1YcW2wdAoAS7Ny8rEJALR
 wc2XAbvadEKPpaKC3CEAwA==;
Received: from [87.69.77.57] (port=1882 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1oDsxH-0003Tn-RS; Tue, 19 Jul 2022 15:32:29 -0400
Date: Tue, 19 Jul 2022 22:32:13 +0300
Message-Id: <83cze0nbk2.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwvedyglxzl.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Tue, 19 Jul 2022 15:21:22 -0400)
References: <874jzdhh5m.fsf@localhost> <jwvzgh5m6fq.fsf-monnier+emacs@HIDDEN>
 <83mtd5m54h.fsf@HIDDEN> <jwvy1wpkpt7.fsf-monnier+emacs@HIDDEN>
 <83ilntlydv.fsf@HIDDEN> <jwvedyglxzl.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: yantar92@HIDDEN,  56637 <at> debbugs.gnu.org
> Date: Tue, 19 Jul 2022 15:21:22 -0400
> 
> >> >> FWIW, I do think it would be good to remove the rule that font-lock is
> >> >> never enabled in temp buffers.
> >> > I don't.
> >> I think we agree :-)
> >> More seriously, I didn't mean to remove it willy-nilly, but that it's
> >> a desirable goal and the question is how to get there.
> > Why is that a desirable goal?
> 
> Because testing `noninteractive` and the presence of a leading space are
> just heuristics and they aren't quite right.  IOW it's a handy hack but
> it's just a hack.

I agree with its being a heuristic, but disagree that they aren't
quite right, and definitely not that they are a hack.  Its our way to
have cheap temporary buffers, and it works quite well.

> > It slows down stuff that is never displayed.
> 
> That's why I say that we shouldn't do it "willy-nilly".
> 
> > And if that buffer has very long lines, it slows Emacs down considerably.
> 
> I think currently it should basically never be the case, because the
> actual fontification (the part which pays attention to lines) only
> happens via jit-lock, which should never trigger if those buffers
> aren't displayed.

jit-lock _will_ trigger if you invoke some APIs that call display
routines.  And that's just one way font-lock can slow down there.

> >> We could start by adding a new variable
> >> `font-lock-allow-in-temporary-buffer`, which packages could set
> >> buffer-locally in those rare temp buffers where they do want to enable
> >> font-lock, as in the untested patch below.
> > This is a slippery slope.  Next some other corner case will want to
> > run buffer-modification hooks in a temporary buffer, so we invent
> > another variable, and so on and so forth.
> 
> Hmm... we do run buffer-modification hooks in temp buffers.

Sorry, I meant kill-buffer-hook, kill-buffer-query-functions, and
buffer-list-update-hook.

> > I'd rather introduce a macro like with-temp-buffer, but one that can
> > accept a buffer name, and ask such applications to please name their
> > temporary buffers something that doesn't begin with a space.
> 
> The purpose of the leading space, AFAIK is to avoid displaying the
> buffer in `read-buffer`.  Forcing those buffers to appear in
> `read-buffer` just because we need to run font-lock in there
> sounds wrong.

That's fixable, and even if we do that in core (something that I'm not
sure is needed), it is still better than having variables to
selectively enable what we generally want to disable in temporary
buffers.

And then, of course, people are free to write their own macros that
are like with-temp-buffer, but different in some way.  Why do we need
to cater for every corner case in core?

> If you don't like `font-lock-allow-in-temporary-buffer`, we could have
> a new function `font-lock-enable-unconditionally` which does the same as
> `font-lock-mode` but skips the (or noninteractive (eq (aref
> (buffer-name) 0) ?\s)) test.

Ouch!

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 19 Jul 2022 21:13:01 +0000
Resent-Message-ID: <handler.56637.B56637.165826517817400 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org, yantar92@HIDDEN
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.165826517817400
          (code B ref 56637); Tue, 19 Jul 2022 21:13:01 +0000
Received: (at 56637) by debbugs.gnu.org; 19 Jul 2022 21:12:58 +0000
Received: from localhost ([127.0.0.1]:55312 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oDuWX-0004Wa-IL
	for submit <at> debbugs.gnu.org; Tue, 19 Jul 2022 17:12:57 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:10612)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1oDuWS-0004WK-EH
 for 56637 <at> debbugs.gnu.org; Tue, 19 Jul 2022 17:12:55 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0D6E610012E;
 Tue, 19 Jul 2022 17:12:47 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3A6C6100102;
 Tue, 19 Jul 2022 17:12:45 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1658265165;
 bh=P+V5bW5ZHPheNQQdkAcQdWukPQ74+0TYPNCCG8zbbrY=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=bQUI9L933ZM1Y1x00DkpD3xjz8f9PUP/6fWtkWkVPuR9xgrvQ5t+uhkm8V4ZqCkdz
 6LUmWjtSV1V9Q8rXpHIUrDbN2FIiki40fXQVHd1oh5vo4tEXyku8ggBmdItG3SnAje
 EvFwOBj5K2Ekj+jzgPrM76B4ydSptEswudK73loRslxJNiHluzMVms4V2RsHqPrKlU
 raF3gqW8O/xGUyzhplY/sZN2NK/MZXV2g4veUytO3DMioynzduGN19226P18u/OxaP
 w7adphRRHpEoWh+oEgwbKqCvkzLi4TxSvweS3L1IFkth5naRgvrel6lAyeMrEHofWC
 436Zm1XPzDPMw==
Received: from alfajor (modemcable117.17-80-70.mc.videotron.ca [70.80.17.117])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 149CD120169;
 Tue, 19 Jul 2022 17:12:45 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <83cze0nbk2.fsf@HIDDEN> (Eli Zaretskii's message of "Tue, 19 Jul
 2022 22:32:13 +0300")
Message-ID: <jwv4jzcbz6x.fsf-monnier+emacs@HIDDEN>
References: <874jzdhh5m.fsf@localhost> <jwvzgh5m6fq.fsf-monnier+emacs@HIDDEN>
 <83mtd5m54h.fsf@HIDDEN> <jwvy1wpkpt7.fsf-monnier+emacs@HIDDEN>
 <83ilntlydv.fsf@HIDDEN> <jwvedyglxzl.fsf-monnier+emacs@HIDDEN>
 <83cze0nbk2.fsf@HIDDEN>
Date: Tue, 19 Jul 2022 17:12:44 -0400
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> >> We could start by adding a new variable
>> >> `font-lock-allow-in-temporary-buffer`, which packages could set
>> >> buffer-locally in those rare temp buffers where they do want to enable
>> >> font-lock, as in the untested patch below.
>> > This is a slippery slope.  Next some other corner case will want to
>> > run buffer-modification hooks in a temporary buffer, so we invent
>> > another variable, and so on and so forth.
>> Hmm... we do run buffer-modification hooks in temp buffers.
> Sorry, I meant kill-buffer-hook, kill-buffer-query-functions, and
> buffer-list-update-hook.

IIUC these used to be run also in temp buffers, so I don't have yet much
intuition for how likely it is that we'll need to avoid those cases.
But, AFAIK these *are* run in batch mode, so it's a slightly
different situation.

>> > I'd rather introduce a macro like with-temp-buffer, but one that can
>> > accept a buffer name, and ask such applications to please name their
>> > temporary buffers something that doesn't begin with a space.
>> The purpose of the leading space, AFAIK is to avoid displaying the
>> buffer in `read-buffer`.  Forcing those buffers to appear in
>> `read-buffer` just because we need to run font-lock in there
>> sounds wrong.
> That's fixable, and even if we do that in core (something that I'm not
> sure is needed), it is still better than having variables to
> selectively enable what we generally want to disable in temporary
> buffers.

Basically, there is a need to have buffers which have font-lock enabled yet
should be hidden from `read-buffer`.  We could try to fix that on the
side of `internal-complete-buffer`, admittedly.

But there is also a need for buffers with font-lock in batch mode
(typically for testing purposes), so changing `internal-complete-buffer`
is not sufficient.

> And then, of course, people are free to write their own macros that
> are like with-temp-buffer, but different in some way.  Why do we need
> to cater for every corner case in core?

Whether you use `with-temp-buffer` or your own macro, you're still stuck
with the choice between "either can't use font-lock or it shows up in `C-x b`".
Of course, people can use hacks like

   (defun really-turn-on-font-lock ()
     (unwind-protect
         (let ((noninteractive nil))
           (rename-buffer (concat "\0" (buffer-name)))
           (font-lock-mode 1))
       (when (eq ?\0 (aref (buffer-name) 0))
         (rename-buffer (substring (buffer-name) 1)))))

But I can't see why we shouldn't accommodate those needs more directly.
It's not like there a deep technical reason why font-lock should not be
enabled under any circumstance in those cases.

>> If you don't like `font-lock-allow-in-temporary-buffer`, we could have
>> a new function `font-lock-enable-unconditionally` which does the same as
>> `font-lock-mode` but skips the (or noninteractive (eq (aref
>> (buffer-name) 0) ?\s)) test.
>
> Ouch!

I don't understand this reaction.  The code would be just as clean as
the current `font-lock-mode` and it's not like there's any reason to
think that people would abuse such a function.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 20 Jul 2022 04:13:01 +0000
Resent-Message-ID: <handler.56637.B56637.165829033825537 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.165829033825537
          (code B ref 56637); Wed, 20 Jul 2022 04:13:01 +0000
Received: (at 56637) by debbugs.gnu.org; 20 Jul 2022 04:12:18 +0000
Received: from localhost ([127.0.0.1]:55537 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oE14M-0006dp-17
	for submit <at> debbugs.gnu.org; Wed, 20 Jul 2022 00:12:18 -0400
Received: from mail-pl1-f179.google.com ([209.85.214.179]:38494)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1oE14I-0006dY-Vl
 for 56637 <at> debbugs.gnu.org; Wed, 20 Jul 2022 00:12:15 -0400
Received: by mail-pl1-f179.google.com with SMTP id w7so1397352plp.5
 for <56637 <at> debbugs.gnu.org>; Tue, 19 Jul 2022 21:12:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=from:to:cc:subject:in-reply-to:references:date:message-id
 :mime-version; bh=s4UPdkevpMttPRxO/l0TGVMnttA4RU1xugbTN7ttxtI=;
 b=F5kjSsOMiIb7TdYzs2cdjV4wtIgsPgSuXw3OP7oVQY97PGOLXM19kqZPIlHoCrC2B8
 N5rl2vv0X6A36e2r7ksAWEdDhprz1wr9z5O5H4xdxFfqImczXsUTUsOPLPxRAwRvGAw0
 x5S+3iL6bwmx+6xfzwaNyg8n3Tceshfxs9tBwmLxIfJqSMYw2Vq+UjhnF5u25IptSrH+
 2rAOrLxt3XHQwcHzPTI/FJVn2iDP3k9ixoIKRbAs3xptQLoc5NtHbKR5eg0gp3yFdTA2
 HaFoxjLzlpfGedztgTLSaGf5XVyOZPtg9zgKcrXUioIFsQ26UoZe6wDCu/ndPD/OiExR
 pGug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date
 :message-id:mime-version;
 bh=s4UPdkevpMttPRxO/l0TGVMnttA4RU1xugbTN7ttxtI=;
 b=aaQkTDsj1bzmt6rHWAWUSPLKr8Hif7I1q+nNxkBoItPEaxF8Ih5LsEs49Xz79ouIFk
 DVY762IL1E9y/igs2r8kUMJ1FUbK6sxowQ6b/4wCvhSBTNHWprCEbiHV0NdLFCJ5EyxG
 9CqbgDyW7XLXPuk6L7wmFb28sZaV+EMkLrChVZPr0wCdRIxhBCJDq+SmcSgwr3YpusLn
 y0/78ZsEAfD4TLiYF9vqQgVTEga9fRvWdALPGuFQiWGXNoOwTodD7KJqKm7hpGobEa8a
 j6i85HnqhUgP5hRqrPk42SoJ05RQGQRZT/U7yfJOYuZp/9p1SQoZ4grX5fq1NCf7tT3d
 io+Q==
X-Gm-Message-State: AJIora8oUbMn1yF/dTGBHdgQ24sBeJwfxtvn6hHEHYl9LQKoigBCFlj6
 KYVeQPwJRSqQ4QcjYKryzeLQ8hDfgCuWoQ==
X-Google-Smtp-Source: AGRyM1sJ233PxHWBLQQ/Wp7JL6deRcvyWTfyA2H14pHgZcc2Bm3ddX7Z+4qfVkDV9UKg0m8hRnVM7w==
X-Received: by 2002:a17:903:2d0:b0:16c:39bc:876 with SMTP id
 s16-20020a17090302d000b0016c39bc0876mr16505496plk.42.1658290328787; 
 Tue, 19 Jul 2022 21:12:08 -0700 (PDT)
Received: from localhost ([115.154.175.57]) by smtp.gmail.com with ESMTPSA id
 125-20020a620483000000b005286697ec68sm12299975pfe.133.2022.07.19.21.12.07
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 19 Jul 2022 21:12:08 -0700 (PDT)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <837d49ntwg.fsf@HIDDEN>
References: <874jzdhh5m.fsf@localhost> <837d49ntwg.fsf@HIDDEN>
Date: Wed, 20 Jul 2022 12:13:14 +0800
Message-ID: <874jzc4e1x.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.2 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.8 (/)

Eli Zaretskii <eliz@HIDDEN> writes:

>> It would be nice if we could somehow enable font-lock inside " *hidden*"
>> buffers. Would it be possible?
>
> Depends on the "somehow" part.  I generally prefer that obscure corner
> cases be solved in the software which creates those obscure cases.  In
> this case, it seems like web-mode is that place?  I'm not sure why
> you say Org should solve this, but perhaps I didn't understand the
> description well enough.  But if this indeed needs to be solved in
> Org, how about not using buffers whose names begin with a space?

While this particular case might be solved on web-mode side (I guess
that directly setting 'font-lock-face property is not recommended?), I
am more concerned about similar issues that might popup in future.

Is it always guaranteed by Emacs that font-lock-fontify-buffer correctly
fontifies that buffer even when font-lock-mode is disabled? If not, Org
has to make sure that font-lock-mode can be enabled when we need to
compute fontification programmatically.

The need to compute fontification is not limited to the described Reddit
report. Org also needs fontification for export purposes - we copy the
Emacs code colours into exported documents. With current behaviour of
font-lock-mode, programmatic fontification may be problematic not only
when we use "hidden" buffers starting with space, but also in
non-interactive mode as in recent related bug report
https://orgmode.org/list/wxaUFiqi8BmIPv8pcYRVHAFa0hTzM35roQxpVVRkgddjRkesPGX1kVBL3G0fr42FonlRq5FNjapV8RiovXV-RGEDehXn-cmIebf4HWBhzIQ=@protonmail.com

As for not using buffers with names starting with a space, we do need
such buffers as means to fontify foreign major mode blocks inside Org.
How else do you suggest computing fontification of an arbitrary text in
arbitrary major-mode (not org-mode) without polluting the buffer list?

Best,
Ihor

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 20 Jul 2022 04:15:01 +0000
Resent-Message-ID: <handler.56637.B56637.165829046125728 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.165829046125728
          (code B ref 56637); Wed, 20 Jul 2022 04:15:01 +0000
Received: (at 56637) by debbugs.gnu.org; 20 Jul 2022 04:14:21 +0000
Received: from localhost ([127.0.0.1]:55541 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oE16K-0006gu-J5
	for submit <at> debbugs.gnu.org; Wed, 20 Jul 2022 00:14:20 -0400
Received: from mail-pj1-f41.google.com ([209.85.216.41]:36601)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1oE16H-0006gd-FU
 for 56637 <at> debbugs.gnu.org; Wed, 20 Jul 2022 00:14:19 -0400
Received: by mail-pj1-f41.google.com with SMTP id
 t3-20020a17090a3b4300b001f21eb7e8b0so285003pjf.1
 for <56637 <at> debbugs.gnu.org>; Tue, 19 Jul 2022 21:14:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=from:to:cc:subject:in-reply-to:references:date:message-id
 :mime-version; bh=ALyausyaBB5+ovW/94xLu/U/l5k4UzPIuE5ojAUbqck=;
 b=hX4cd3GLbmdyuEpOMixvGyUAzlJP7c9+TdfJJUS/3nUbj10gvmip+yL0yvVruro57p
 7K4CksQQlFgCpIyozxwgfy4D/1t8jX75jSpgZ3Cv90jFiHSd+WqPw7YaFnDx92TSCxD9
 REEdP+/rSFAVKLym+vK6GQwVrpC6CduRhye7pn4eoNB53OMGRtZnKlVrDeEXfJ+HAN0o
 msUZr9amzSX0GOkrPVgKKybjPpdNE57apZ4NpWOwRl9VQqH4LlBJB3y0Z3O6C9C9yAhs
 MUSMTTxjYHOBRcK1GsjbwEKpjL0upbTxJn2gPqVplmfZquVRrMSO4oHzzMhpGr9vi1Mg
 TITw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date
 :message-id:mime-version;
 bh=ALyausyaBB5+ovW/94xLu/U/l5k4UzPIuE5ojAUbqck=;
 b=5IAkwnIFO7a6nhRQ4kINSbGfyPYoPU6Khyau1QHqPNKS754jc/afeonfFihsjBT/qv
 DGLMQqNWRPIJQh384WNmpbVJiJ2PXzn4k4N6aoiNeIXiOsATyu0/FgWhhKe3eAh1KN8i
 cY3pgdA6z0cn98sLlI0vTDVIIDIAZ3pokTkVr9A3DxGTtyYcAUhRCeDKtr7yNpj7Xegl
 6fFE1BZ6LsKWFQcWoU6ctP6Pl/DGm/5+GCcuY6FoSQ3WNhL863xtAI69gcchsECkPGb2
 Y1dwWcsXNXmDdmAYXU1Yn61fmHOqK5Yp7x2GnqdQi22GvhcM0q8siq7p8F3HlvobM7Ur
 hr+g==
X-Gm-Message-State: AJIora9EyTO3bJ7WrQyZTlHY2kGZtoxF1AnNNzhwdYdbjDzXdZUghIP8
 9CsmHGh74JIlMlBUN0H0CCdLyjypdXIGFQ==
X-Google-Smtp-Source: AGRyM1tnaEgt3fKpJpyUtek2/DhgF8dZ6e5JAwUrhyYfwgnflw8B2Rr8mRyVN7YeOydfKpldkvWoUg==
X-Received: by 2002:a17:903:41c2:b0:16c:52f8:9240 with SMTP id
 u2-20020a17090341c200b0016c52f89240mr36959038ple.161.1658290450295; 
 Tue, 19 Jul 2022 21:14:10 -0700 (PDT)
Received: from localhost ([115.154.175.57]) by smtp.gmail.com with ESMTPSA id
 r14-20020a63204e000000b0041166bf9ca8sm10692885pgm.34.2022.07.19.21.14.08
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 19 Jul 2022 21:14:09 -0700 (PDT)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <jwvzgh5m6fq.fsf-monnier+emacs@HIDDEN>
References: <874jzdhh5m.fsf@localhost> <jwvzgh5m6fq.fsf-monnier+emacs@HIDDEN>
Date: Wed, 20 Jul 2022 12:15:15 +0800
Message-ID: <871qug4dyk.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.2 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.8 (/)

Stefan Monnier <monnier@HIDDEN> writes:

>> Org mode fontifies code blocks using "hidden" temporary buffers with
>> their name starting from " ": " *org-src-fontification:major-mode*".
>>
>> The buffers are kept around to avoid extra major-mode loading overheads
>> and the fontification is not using (font-lock-ensure).
>
> IIUC they're never displayed, right?  So, `font-lock-ensure` does sound
> like "the right tool".  Could you give a short explanation for why you
> don't use `font-lock-ensure`?

Sorry, it is a typo. I did mean "the fontification *is* using
(font-lock-ensure)". We do use `font-lock-ensure', but it does not
always produce the same results with/without font-lock-mode enabled.

Best,
Ihor

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 20 Jul 2022 11:13:02 +0000
Resent-Message-ID: <handler.56637.B56637.16583155675248 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org, yantar92@HIDDEN
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.16583155675248
          (code B ref 56637); Wed, 20 Jul 2022 11:13:02 +0000
Received: (at 56637) by debbugs.gnu.org; 20 Jul 2022 11:12:47 +0000
Received: from localhost ([127.0.0.1]:55973 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oE7dG-0001Ma-SY
	for submit <at> debbugs.gnu.org; Wed, 20 Jul 2022 07:12:47 -0400
Received: from eggs.gnu.org ([209.51.188.92]:44408)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1oE7dF-0001MM-CV
 for 56637 <at> debbugs.gnu.org; Wed, 20 Jul 2022 07:12:46 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:55762)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1oE7dA-0007Yn-2z; Wed, 20 Jul 2022 07:12:40 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=J9wDVT1Njf1tIB+dfyTdsuAut1gqgQk22Wy5+Pov56Y=; b=rZUpjd4bOPnz
 pxgffONx3nN7TJ8LzZTj4rkxEvlGb4SD/nwp1P6dmPnIwfBRDH2IuFHcuZYhTObOFayPK/oRyvstb
 KEw+fmjbof18wOwC6aBuHU/5Y5Ika0R8reaDTA23BNdb9CXY23hF5dz6auqapsUz2iDtVBRGHslaG
 L6JnB7yulVTH3bhnMfaj9zLjyR3g711Fc2uMR+8+yose3KOn/QvW6lllDfF0dXlKxCUTv8Fdvzj/8
 0PyP7wvfCGKv6gBlcMG0jwZeK9fjktYoZ1+0h4+HAcf8ZQKU1BH28w6wZeTcABjUjVWe/1ub+o3rF
 EetBNdwHeA8dnnU5Pgrkfw==;
Received: from [87.69.77.57] (port=3417 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1oE7d9-00071L-Fq; Wed, 20 Jul 2022 07:12:39 -0400
Date: Wed, 20 Jul 2022 14:12:29 +0300
Message-Id: <83a694m40y.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwv4jzcbz6x.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Tue, 19 Jul 2022 17:12:44 -0400)
References: <874jzdhh5m.fsf@localhost> <jwvzgh5m6fq.fsf-monnier+emacs@HIDDEN>
 <83mtd5m54h.fsf@HIDDEN> <jwvy1wpkpt7.fsf-monnier+emacs@HIDDEN>
 <83ilntlydv.fsf@HIDDEN> <jwvedyglxzl.fsf-monnier+emacs@HIDDEN>
 <83cze0nbk2.fsf@HIDDEN> <jwv4jzcbz6x.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: yantar92@HIDDEN,  56637 <at> debbugs.gnu.org
> Date: Tue, 19 Jul 2022 17:12:44 -0400
> 
> Of course, people can use hacks like
> 
>    (defun really-turn-on-font-lock ()
>      (unwind-protect
>          (let ((noninteractive nil))
>            (rename-buffer (concat "\0" (buffer-name)))
>            (font-lock-mode 1))
>        (when (eq ?\0 (aref (buffer-name) 0))
>          (rename-buffer (substring (buffer-name) 1)))))
> 
> But I can't see why we shouldn't accommodate those needs more directly.

I can: we don't need, and really shouldn't, attempt to cater to each
corner use case in core.  Doing that (and we've been doing that for
quite some time) makes Emacs a larger and less maintainable monster
than it needs to be or already is.  The gain for everyone is minimal,
the gain for those who must for some reason cope with such situations
is small (compared with the above alternative or something like it),
while the damage in terms of being able to know what Emacs does
without stepping through the code with a debugger -- that damage is
quite significant.  You already have one symptom of the monster's
size: I already cannot tell which hooks are and aren't running in
temporary buffers without consulting the sources.  Way to go, Emacs!

> It's not like there a deep technical reason why font-lock should not be
> enabled under any circumstance in those cases.

There are practical reasons why it shouldn't in the vast majority of
cases.  The few rare cases which do have easy workarounds, and I see
absolutely no reason why they couldn't take one of them.

> >> If you don't like `font-lock-allow-in-temporary-buffer`, we could have
> >> a new function `font-lock-enable-unconditionally` which does the same as
> >> `font-lock-mode` but skips the (or noninteractive (eq (aref
> >> (buffer-name) 0) ?\s)) test.
> >
> > Ouch!
> 
> I don't understand this reaction.

See above.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 20 Jul 2022 11:34:01 +0000
Resent-Message-ID: <handler.56637.B56637.165831679823896 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org, monnier@HIDDEN
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.165831679823896
          (code B ref 56637); Wed, 20 Jul 2022 11:34:01 +0000
Received: (at 56637) by debbugs.gnu.org; 20 Jul 2022 11:33:18 +0000
Received: from localhost ([127.0.0.1]:56022 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oE7x6-0006DK-VZ
	for submit <at> debbugs.gnu.org; Wed, 20 Jul 2022 07:33:18 -0400
Received: from eggs.gnu.org ([209.51.188.92]:49372)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1oE7wv-0006Cg-Rs
 for 56637 <at> debbugs.gnu.org; Wed, 20 Jul 2022 07:33:15 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:56184)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1oE7wq-0002sN-6x; Wed, 20 Jul 2022 07:33:00 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=sQ4i+hjn+Z9Mlj+wYK85lYGkOs33c/wQtANSW5tUZ94=; b=rGALnGCq+PHm
 TYgILUS9r67y5IH01txowW4NRmrZkeTrm4mBZxykL8DqU4Kk50G7nfeYkxDyvQ8xMgNXSLmrtNfhv
 vw7cpU/gz4i5tu6IACWJGj6CPwlILoOPUPx1Gn3D7BMLUg1uFvoS5oYfMLDcrfFVflM+Rw7TQ+Ey4
 2JCs6Dkftz3M3rehhwiBTI25g0uULtndJ6g5HqiJNHUIscYcb+7pgvsZmArBOGPHsyD7F1+VJSyrT
 6RqUloQAWgo2Hzwdk9boY7pf9ExOSAemz/tbWbyJdYItcONJYimf4cHM1SoV8WVf0fu2IvWjhxufN
 a78kqbUDHqCuAvW2bY1mlQ==;
Received: from [87.69.77.57] (port=4648 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1oE7wp-00043F-0y; Wed, 20 Jul 2022 07:32:59 -0400
Date: Wed, 20 Jul 2022 14:32:49 +0300
Message-Id: <837d48m332.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <874jzc4e1x.fsf@localhost> (message from Ihor Radchenko on Wed,
 20 Jul 2022 12:13:14 +0800)
References: <874jzdhh5m.fsf@localhost> <837d49ntwg.fsf@HIDDEN>
 <874jzc4e1x.fsf@localhost>
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: Stefan Monnier <monnier@HIDDEN>,  56637 <at> debbugs.gnu.org
> Date: Wed, 20 Jul 2022 12:13:14 +0800
> 
> Eli Zaretskii <eliz@HIDDEN> writes:
> 
> >> It would be nice if we could somehow enable font-lock inside " *hidden*"
> >> buffers. Would it be possible?
> >
> > Depends on the "somehow" part.  I generally prefer that obscure corner
> > cases be solved in the software which creates those obscure cases.  In
> > this case, it seems like web-mode is that place?  I'm not sure why
> > you say Org should solve this, but perhaps I didn't understand the
> > description well enough.  But if this indeed needs to be solved in
> > Org, how about not using buffers whose names begin with a space?
> 
> While this particular case might be solved on web-mode side (I guess
> that directly setting 'font-lock-face property is not recommended?), I
> am more concerned about similar issues that might popup in future.

We don't necessarily need to solve future problems.  Let's leave
something for those who will come after us.

> Is it always guaranteed by Emacs that font-lock-fontify-buffer correctly
> fontifies that buffer even when font-lock-mode is disabled?

IMO, if it doesn't, it's a bug that should be fixed.  If you have
recipes where it happens, please submit a bug report.

> The need to compute fontification is not limited to the described Reddit
> report. Org also needs fontification for export purposes - we copy the
> Emacs code colours into exported documents. With current behaviour of
> font-lock-mode, programmatic fontification may be problematic not only
> when we use "hidden" buffers starting with space, but also in
> non-interactive mode as in recent related bug report
> https://orgmode.org/list/wxaUFiqi8BmIPv8pcYRVHAFa0hTzM35roQxpVVRkgddjRkesPGX1kVBL3G0fr42FonlRq5FNjapV8RiovXV-RGEDehXn-cmIebf4HWBhzIQ=@protonmail.com

If you create buffer, process text in it, then write it out and kill
the buffer, all in one go, there should be no reason to use a buffer
whose name begins with a space, because interactive users will not
have an opportunity to see such a buffer in the Emacs session.

This problem is only real when a temporary buffer is left around
because, for example, it is being collected/processed asynchronously,
or in several stages with the user being able to interact with Emacs
in-between.

> As for not using buffers with names starting with a space, we do need
> such buffers as means to fontify foreign major mode blocks inside Org.
> How else do you suggest computing fontification of an arbitrary text in
> arbitrary major-mode (not org-mode) without polluting the buffer list?

Once again, if the buffer is killed before the user can see it,
there's no problem to use a name which doesn't start with a space.

But let me turn the table and ask you: how have you been doing this
till now?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 20 Jul 2022 15:00:02 +0000
Resent-Message-ID: <handler.56637.B56637.165832915615327 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.165832915615327
          (code B ref 56637); Wed, 20 Jul 2022 15:00:02 +0000
Received: (at 56637) by debbugs.gnu.org; 20 Jul 2022 14:59:16 +0000
Received: from localhost ([127.0.0.1]:58525 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oEBAR-0003z9-Su
	for submit <at> debbugs.gnu.org; Wed, 20 Jul 2022 10:59:16 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:36670)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1oEBAQ-0003yt-D4
 for 56637 <at> debbugs.gnu.org; Wed, 20 Jul 2022 10:59:14 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id EB538100154;
 Wed, 20 Jul 2022 10:59:08 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D9B0D100120;
 Wed, 20 Jul 2022 10:59:06 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1658329146;
 bh=MeaGzcg85hTsMOLyDmFZqUJsOu4lFpH8NPG7GD9ZHpk=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=QRS5Y0oy5zWSxNpjgHqyeXTl0WNQGMyM+alO1EZ54FBh7aobqXu64v6pQFdle8hOH
 JtWZFVIGLDcgl+QX2c7sshw7/TTag94e40mtjQt0tCgTum/VfyuIXirqcbFxfoAc/O
 MDGZVVgq0iroOhwtKlu/+JQCiBIIkJQGewTmlkPjmNSpH98WrztUrzZzp/HdQ1IiTE
 edAKC83Bm17e1o/m/YFFKTVPJLhgekaM3+4yAyJ0Sy4YCApEDUSW8IdDshSZ8Rq4N4
 gzTxzIVRdpT6qmf0EL7ryLhWiLKlmvl/AQngWDxkEqYXrQ4Y8mwqT00Ea8rHr/W3IG
 0S5F8HEbqHRoA==
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C9232120180;
 Wed, 20 Jul 2022 10:59:06 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <871qug4dyk.fsf@localhost> (Ihor Radchenko's message of "Wed, 20
 Jul 2022 12:15:15 +0800")
Message-ID: <jwvbktj6ddp.fsf-monnier+emacs@HIDDEN>
References: <874jzdhh5m.fsf@localhost> <jwvzgh5m6fq.fsf-monnier+emacs@HIDDEN>
 <871qug4dyk.fsf@localhost>
Date: Wed, 20 Jul 2022 10:58:58 -0400
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.175 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> 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?


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 20 Jul 2022 15:16:01 +0000
Resent-Message-ID: <handler.56637.B56637.165833014117430 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org, yantar92@HIDDEN
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.165833014117430
          (code B ref 56637); Wed, 20 Jul 2022 15:16:01 +0000
Received: (at 56637) by debbugs.gnu.org; 20 Jul 2022 15:15:41 +0000
Received: from localhost ([127.0.0.1]:58609 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oEBQK-0004X3-NA
	for submit <at> debbugs.gnu.org; Wed, 20 Jul 2022 11:15:41 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:8130)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1oEBQG-0004Wn-Rb
 for 56637 <at> debbugs.gnu.org; Wed, 20 Jul 2022 11:15:39 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 710E4441705;
 Wed, 20 Jul 2022 11:15:31 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 256A14416F2;
 Wed, 20 Jul 2022 11:15:29 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1658330129;
 bh=Cm1XpRRpeR5OyrDaCGkXMQdNGcPoO8r5tjY5/GXgY9I=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=Vqb/PXcO0/mO6QSPe+6oKEuOEFw7PS9QFurBkk8y2ZhRNCP3e35uztEtaiHEpEX5f
 1it8v9/FH2VGia18+e3KYPzNRHrJuDLGAUnTg5mNUAcyMf9ielo5Oc0JbeTkJg/3XE
 D+oebCeT7qINoHf/z2bIMz0FHJcKssSJr7705SYcwkZZRXh2orFUCcVJn8Lk0eQ33i
 vttDR87ZU/1r9DvfA2eDOlN1+GVUAZ6QC4BXGTyEuSwWjC9kF8vcyywTYVQDBj0V44
 eMmcUL9tWIHiDmc15ggmRKZ70XkLGoNTvsvfOnCb+Gc+yWqm+WFFGObWTBbzknU4cM
 IfxOnGvFc0KPA==
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0FC62120161;
 Wed, 20 Jul 2022 11:15:29 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <83a694m40y.fsf@HIDDEN> (Eli Zaretskii's message of "Wed, 20 Jul
 2022 14:12:29 +0300")
Message-ID: <jwv5yjr6d94.fsf-monnier+emacs@HIDDEN>
References: <874jzdhh5m.fsf@localhost> <jwvzgh5m6fq.fsf-monnier+emacs@HIDDEN>
 <83mtd5m54h.fsf@HIDDEN> <jwvy1wpkpt7.fsf-monnier+emacs@HIDDEN>
 <83ilntlydv.fsf@HIDDEN> <jwvedyglxzl.fsf-monnier+emacs@HIDDEN>
 <83cze0nbk2.fsf@HIDDEN> <jwv4jzcbz6x.fsf-monnier+emacs@HIDDEN>
 <83a694m40y.fsf@HIDDEN>
Date: Wed, 20 Jul 2022 11:15:20 -0400
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.224 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>>    (defun really-turn-on-font-lock ()
>>      (unwind-protect
>>          (let ((noninteractive nil))
>>            (rename-buffer (concat "\0" (buffer-name)))
>>            (font-lock-mode 1))
>>        (when (eq ?\0 (aref (buffer-name) 0))
>>          (rename-buffer (substring (buffer-name) 1)))))
>> 
>> But I can't see why we shouldn't accommodate those needs more directly.
>
> I can: we don't need, and really shouldn't, attempt to cater to each
> corner use case in core.  Doing that (and we've been doing that for
> quite some time) makes Emacs a larger and less maintainable monster
> than it needs to be or already is.

I can't see why adding the patch below would make it less maintainable.
It sure seems much cleaner than the horror quoted above (which suffers
from all kinds of corner case misbehaviors).

> You already have one symptom of the monster's size: I already cannot
> tell which hooks are and aren't running in temporary buffers without
> consulting the sources.  Way to go, Emacs!

And for that reason, I think we should try and avoid such special cases
(such the special case of not enabling font-lock in temp buffers), by
replacing them with other measures which give similar results but
without such special casing.

Regarding `inhibit-buffer-hooks`, I wonder if we shouldn't instead
change `with-temp-buffer` so it sets `kill-buffer-hook` (and the other
2 hooks) buffer-locally to nil.
This way, we get pretty much the same end result (in terms of
performance benefits when there are many buffers) yet the hooks get run
normally.

>> >> If you don't like `font-lock-allow-in-temporary-buffer`, we could have
>> >> a new function `font-lock-enable-unconditionally` which does the same as
>> >> `font-lock-mode` but skips the (or noninteractive (eq (aref
>> >> (buffer-name) 0) ?\s)) test.
>> > Ouch!
>> I don't understand this reaction.
> See above.

"Ouch" to me implies something like an ugly code or the introduction of
something that breaks an abstraction or some such.  Having to write the
above quote would qualify, whereas the patch below doesn't seem
to qualify.


        Stefan


diff --git a/lisp/font-core.el b/lisp/font-core.el
index f92d1e38306..dc6aac98828 100644
--- a/lisp/font-core.el
+++ b/lisp/font-core.el
@@ -133,6 +133,12 @@ font-lock-mode
   ;; batch job) or if the buffer is invisible (the name starts with a space).
   (when (or noninteractive (eq (aref (buffer-name) 0) ?\s))
     (setq font-lock-mode nil))
+  (font-lock-mode-unconditionally (not font-lock-mode)))
+
+(defun font-lock-mode-unconditionally (&optional disable)
+  "Enable font-lock unconditionally.
+If DISABLE is non-nil, then disable unconditionally."
+  (setq font-lock-mode (not disable)
   (funcall font-lock-function font-lock-mode)
   ;; Arrange to unfontify this buffer if we change major mode later.
   (if font-lock-mode

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 20 Jul 2022 16:10:01 +0000
Resent-Message-ID: <handler.56637.B56637.165833339131710 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org, yantar92@HIDDEN
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.165833339131710
          (code B ref 56637); Wed, 20 Jul 2022 16:10:01 +0000
Received: (at 56637) by debbugs.gnu.org; 20 Jul 2022 16:09:51 +0000
Received: from localhost ([127.0.0.1]:58710 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oECGl-0008FO-Cx
	for submit <at> debbugs.gnu.org; Wed, 20 Jul 2022 12:09:51 -0400
Received: from eggs.gnu.org ([209.51.188.92]:34586)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1oECGk-0008FA-7b
 for 56637 <at> debbugs.gnu.org; Wed, 20 Jul 2022 12:09:50 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:33262)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1oECGe-0004Sn-WD; Wed, 20 Jul 2022 12:09:45 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=AYW9LrMzhdUUTglHJz3ikwxvMSteIN4WJKymG25Sd14=; b=hA185uej14lN
 dR8MjRVvFhw4pIF/QGyalW6/8snG0TySJUYB5B5sflxzujq97ISknpJvxPWFoO9LKVzqXQAnB1dcO
 fLMEDuPPywQNliHOgE/6OGIBomLzVqn7KYfBg/xULIH/FoYQcCo4Ata9wy3M8uu1b0olIXLlWt4J1
 j5S/Ekv/CIReN6lQZd1ESI+Nehyt9KGFqU7DeUmd896678N6DwNpSNUK887ERJSopUFzi+HWEFPKV
 uIeFBKLVczCmNPYotGiq89r9foZQgp4Sk4W1MwUiH/K7NrDgZGHhjSWdSK4Xq+SpWYWOdnhkwRHYx
 pufuV2IrMw9oVgd4Ic2tdQ==;
Received: from [87.69.77.57] (port=2168 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1oECGe-0007iV-EN; Wed, 20 Jul 2022 12:09:44 -0400
Date: Wed, 20 Jul 2022 19:09:34 +0300
Message-Id: <83lesnlq9t.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwv5yjr6d94.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Wed, 20 Jul 2022 11:15:20 -0400)
References: <874jzdhh5m.fsf@localhost> <jwvzgh5m6fq.fsf-monnier+emacs@HIDDEN>
 <83mtd5m54h.fsf@HIDDEN> <jwvy1wpkpt7.fsf-monnier+emacs@HIDDEN>
 <83ilntlydv.fsf@HIDDEN> <jwvedyglxzl.fsf-monnier+emacs@HIDDEN>
 <83cze0nbk2.fsf@HIDDEN> <jwv4jzcbz6x.fsf-monnier+emacs@HIDDEN>
 <83a694m40y.fsf@HIDDEN> <jwv5yjr6d94.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: yantar92@HIDDEN,  56637 <at> debbugs.gnu.org
> Date: Wed, 20 Jul 2022 11:15:20 -0400
> 
> >> But I can't see why we shouldn't accommodate those needs more directly.
> >
> > I can: we don't need, and really shouldn't, attempt to cater to each
> > corner use case in core.  Doing that (and we've been doing that for
> > quite some time) makes Emacs a larger and less maintainable monster
> > than it needs to be or already is.
> 
> I can't see why adding the patch below would make it less maintainable.

Well, I explained that.  If you still don't see it, I guess we'll have
to agree to disagree.

> It sure seems much cleaner than the horror quoted above (which suffers
> from all kinds of corner case misbehaviors).

The horror quoted above won't be in Emacs, so it is of no concern to
us.

> > You already have one symptom of the monster's size: I already cannot
> > tell which hooks are and aren't running in temporary buffers without
> > consulting the sources.  Way to go, Emacs!
> 
> And for that reason, I think we should try and avoid such special cases
> (such the special case of not enabling font-lock in temp buffers), by
> replacing them with other measures which give similar results but
> without such special casing.

Temporary buffers _are_ special cases, whether we want it or not.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 20 Jul 2022 19:17:02 +0000
Resent-Message-ID: <handler.56637.B56637.165834458318425 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org, yantar92@HIDDEN
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.165834458318425
          (code B ref 56637); Wed, 20 Jul 2022 19:17:02 +0000
Received: (at 56637) by debbugs.gnu.org; 20 Jul 2022 19:16:23 +0000
Received: from localhost ([127.0.0.1]:58884 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oEFBG-0004n7-UD
	for submit <at> debbugs.gnu.org; Wed, 20 Jul 2022 15:16:23 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:43608)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1oEFBB-0004mo-OF
 for 56637 <at> debbugs.gnu.org; Wed, 20 Jul 2022 15:16:21 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 54629100154;
 Wed, 20 Jul 2022 15:16:12 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 6B238100120;
 Wed, 20 Jul 2022 15:16:02 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1658344562;
 bh=2QXbcARtfMv8rjb6fAEWn9df5me+E3HZZrbtiZcFtcY=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=AyV+pSCahWhmcNiUo42PDwzeIvykUCnbTNpM6RvWjd9zw3QxtA3XpdBXXDj6g/uHQ
 Xi5BLYMcwnD6TLlN/vF+JYMxmzw3le7I20Eq3BsCi4PdsesjyuGbg2Pge/oST9m0WA
 G31A2StnTOCETwUdRdEBBWlJCQ1rfZLEVvka6QGGEWIWvCL0AeDsFGhX153/r+DHlY
 tKOx6flTCG3w2U5QPX58HvkMpMn6ZQnkwNl3d4XLaznhtFeEkaPztmoumaS7ihmahT
 uDETUNLPDkXh6Dh3ZC0bzZwJd3/pQ+aUiabhB9OS3oc6dTqIf6Nmhyddks7f7tbBxz
 u48+jW8QcJpBw==
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 57BE6120249;
 Wed, 20 Jul 2022 15:16:02 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <83lesnlq9t.fsf@HIDDEN> (Eli Zaretskii's message of "Wed, 20 Jul
 2022 19:09:34 +0300")
Message-ID: <jwvlesn7fzg.fsf-monnier+emacs@HIDDEN>
References: <874jzdhh5m.fsf@localhost> <jwvzgh5m6fq.fsf-monnier+emacs@HIDDEN>
 <83mtd5m54h.fsf@HIDDEN> <jwvy1wpkpt7.fsf-monnier+emacs@HIDDEN>
 <83ilntlydv.fsf@HIDDEN> <jwvedyglxzl.fsf-monnier+emacs@HIDDEN>
 <83cze0nbk2.fsf@HIDDEN> <jwv4jzcbz6x.fsf-monnier+emacs@HIDDEN>
 <83a694m40y.fsf@HIDDEN> <jwv5yjr6d94.fsf-monnier+emacs@HIDDEN>
 <83lesnlq9t.fsf@HIDDEN>
Date: Wed, 20 Jul 2022 15:15:53 -0400
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.174 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> It sure seems much cleaner than the horror quoted above (which suffers
>> from all kinds of corner case misbehaviors).
> The horror quoted above won't be in Emacs, so it is of no concern to us.

I'm pretty sure it will end up in Emacs.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 21 Jul 2022 12:09:02 +0000
Resent-Message-ID: <handler.56637.B56637.16584053401294 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org, monnier@HIDDEN
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.16584053401294
          (code B ref 56637); Thu, 21 Jul 2022 12:09:02 +0000
Received: (at 56637) by debbugs.gnu.org; 21 Jul 2022 12:09:00 +0000
Received: from localhost ([127.0.0.1]:36809 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oEUzE-0000Ko-8D
	for submit <at> debbugs.gnu.org; Thu, 21 Jul 2022 08:09:00 -0400
Received: from mail-pl1-f181.google.com ([209.85.214.181]:37464)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1oEUzA-0000KZ-Ku
 for 56637 <at> debbugs.gnu.org; Thu, 21 Jul 2022 08:08:59 -0400
Received: by mail-pl1-f181.google.com with SMTP id f11so1616588plr.4
 for <56637 <at> debbugs.gnu.org>; Thu, 21 Jul 2022 05:08:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=from:to:cc:subject:in-reply-to:references:date:message-id
 :mime-version; bh=dcn3YiliHf7cH4Dghebb0KUyPfQTS0G2tmB7BP8R7Vo=;
 b=Kww8Z5QaNWXYAFP6JpGQUalPBkKGY/PYivSzc2mp59UL2kNF9Prq5RDxsqYqB/3HiW
 qvWVu4CPSXy0jjtVEv3RvvBoeTGiRB8hA9od5jCdjFQMd+SdbcCwKqPw6AMETTpEGVGK
 +CJKmqYp1clvdUdIGRsGPTx6+THJ5gdy0dBuBT8MvgAb6imVTgh0W793K5eEcuhZpjC/
 SjInfc2LIIcwL2IwLDG87Paf7D94Pt0YGG3Ag7xcDBztOCo4D50cMk5Lgw8Y4znDfXsV
 cdpytKzoiqsuVuztNkwa8uei5q0eF5XiAWvcLDzqB1xW+H9QffSF3AcvS/b+sPc/VuC5
 29bQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date
 :message-id:mime-version;
 bh=dcn3YiliHf7cH4Dghebb0KUyPfQTS0G2tmB7BP8R7Vo=;
 b=Lz6KhjVoznJwlM9NINQD1cWb2yE7vXpDk1q3cFreSSbDbw78W0qidZqPOvPqPcbu5Y
 GoDcqvuHK9hN4eqWcJizXLh7q7THzRj4o7s8J7u/x1gTizyPZDFtOC3awiRgrykq9kVV
 mPAAerwGPjofzN3OAgpMt1hEqibTkUr/T8Povf88r+mnIJsTvmNyCreacgSNR7TGqge2
 v++QNEovsMe+YuzWfJDEOtt4Okj3NfJ+F7kvwlL24vx/NS2r22E/B0pnsuCPZuHTDwtN
 IEbbSS5TT8p2DJeQN7fS+9bj4nX+1IGDNdhs2g7pm4Hy6E0beGkzJN4yuczz8cXWTzo6
 0JeA==
X-Gm-Message-State: AJIora9VLaNnUvFiNw0MSsd/gBxfQjI9FfEoXAI63lNzZEMttvgjfhL+
 CABAyWMRdVMBiqIJUu9gkuQ=
X-Google-Smtp-Source: AGRyM1v5JcP20SCUxglRe6AZiDhPOeh/pFr4cMPAvz6UUcZj3tSd0V80o4L5fk5mOacydjAQf77ujw==
X-Received: by 2002:a17:90b:4b82:b0:1f0:196d:4204 with SMTP id
 lr2-20020a17090b4b8200b001f0196d4204mr11063091pjb.194.1658405330645; 
 Thu, 21 Jul 2022 05:08:50 -0700 (PDT)
Received: from localhost ([2409:8a70:2b7:3fb0:8ec6:81ff:fe70:339d])
 by smtp.gmail.com with ESMTPSA id
 z5-20020a1709027e8500b0016bdc31c772sm1493684pla.117.2022.07.21.05.08.49
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 21 Jul 2022 05:08:50 -0700 (PDT)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <837d48m332.fsf@HIDDEN>
References: <874jzdhh5m.fsf@localhost> <837d49ntwg.fsf@HIDDEN>
 <874jzc4e1x.fsf@localhost> <837d48m332.fsf@HIDDEN>
Date: Thu, 21 Jul 2022 20:09:55 +0800
Message-ID: <87zgh21xbg.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.3 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

Eli Zaretskii <eliz@HIDDEN> writes:

>> Is it always guaranteed by Emacs that font-lock-fontify-buffer correctly
>> fontifies that buffer even when font-lock-mode is disabled?
>
> IMO, if it doesn't, it's a bug that should be fixed.  If you have
> recipes where it happens, please submit a bug report.

Create a file called bug.el with the following text:

(with-current-buffer (get-buffer-create "Test")
  (emacs-lisp-mode)
  (insert "(message \"Foo\")")
  (font-lock-ensure)
  (message "%S" (buffer-string)))

Then, run
emacs-29-vcs -Q --script /tmp/bug.el

Observed output: #("(message \"Foo\")" 9 14 (face font-lock-string-face))
Expected: #("(message \"Foo\")" 0 9 (fontified t) 9 14 (face font-lock-string-face fontified t) 14 15 (fontified t))

The expected output appears in *Messages* when you run 
emacs-29-vcs -Q -l /tmp/bug.el

>> The need to compute fontification is not limited to the described Reddit
>> report. Org also needs fontification for export purposes - we copy the
>> Emacs code colours into exported documents. With current behaviour of
>> font-lock-mode, programmatic fontification may be problematic not only
>> when we use "hidden" buffers starting with space, but also in
>> non-interactive mode as in recent related bug report
>> https://orgmode.org/list/wxaUFiqi8BmIPv8pcYRVHAFa0hTzM35roQxpVVRkgddjRkesPGX1kVBL3G0fr42FonlRq5FNjapV8RiovXV-RGEDehXn-cmIebf4HWBhzIQ=@protonmail.com
>
> If you create buffer, process text in it, then write it out and kill
> the buffer, all in one go, there should be no reason to use a buffer
> whose name begins with a space, because interactive users will not
> have an opportunity to see such a buffer in the Emacs session.
>
> This problem is only real when a temporary buffer is left around
> because, for example, it is being collected/processed asynchronously,
> or in several stages with the user being able to interact with Emacs
> in-between.

Killing the buffer where we do fontification is too slow for Org.
If Org were to use temporary buffers, it would need to load major mode
for every text fragment to be fontified. Loading major modes (at least
some major modes) is taking significant amount of time and should
better be avoided if we can simply reuse a single buffer with major mode
that is already loaded.

>> As for not using buffers with names starting with a space, we do need
>> such buffers as means to fontify foreign major mode blocks inside Org.
>> How else do you suggest computing fontification of an arbitrary text in
>> arbitrary major-mode (not org-mode) without polluting the buffer list?
>
> Once again, if the buffer is killed before the user can see it,
> there's no problem to use a name which doesn't start with a space.
>
> But let me turn the table and ask you: how have you been doing this
> till now?

See the above.

Best,
Ihor

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 21 Jul 2022 12:11:01 +0000
Resent-Message-ID: <handler.56637.B56637.16584054521535 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.16584054521535
          (code B ref 56637); Thu, 21 Jul 2022 12:11:01 +0000
Received: (at 56637) by debbugs.gnu.org; 21 Jul 2022 12:10:52 +0000
Received: from localhost ([127.0.0.1]:36821 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oEV11-0000Oh-PO
	for submit <at> debbugs.gnu.org; Thu, 21 Jul 2022 08:10:51 -0400
Received: from mail-pj1-f53.google.com ([209.85.216.53]:38845)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1oEV10-0000OV-CS
 for 56637 <at> debbugs.gnu.org; Thu, 21 Jul 2022 08:10:50 -0400
Received: by mail-pj1-f53.google.com with SMTP id
 b7-20020a17090a12c700b001f20eb82a08so5047500pjg.3
 for <56637 <at> debbugs.gnu.org>; Thu, 21 Jul 2022 05:10:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=from:to:cc:subject:in-reply-to:references:date:message-id
 :mime-version; bh=q5PUXEY+hGzN5mDnhX6HRYCpSJBrAfQJciyCM6Gssjs=;
 b=fMiOAOVDv3nuU/U5q7QB2aCzu9Cw5BbOr4uNz1+JSpmgGqPVHlGxc+959k4AsdZEu9
 hgeld4ddLsE7M+tNNQaF2r3Pd0MBe6j15OBVtEloj+SXtFzdI35Ex4LuX02erH3yzhvO
 X8CCuQ6b66FUfJTzX4J36uk0vHo3CswIA9yY/24kWKfai8ACnglETSoYC8GLVOXEZGmD
 WWqlvqbB3YDRd7Nv8G5X7/FBqNHsCSYeLtdg/YwdgmfiyErXO51RLZhIxCQsO2ONdACL
 Zakr7MGbiD0F4JKjm5NJy+9kXg7TYG9AoCJPmB6hdc3/Boc6IL7+5VO62KmM9eXdGSJz
 9Jbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date
 :message-id:mime-version;
 bh=q5PUXEY+hGzN5mDnhX6HRYCpSJBrAfQJciyCM6Gssjs=;
 b=qnvwJ85HB8/9cL+LMNibGxK7EI9mghsmNFuwAcH5I47tuGsqEUq3nIYI5B8TYuWf/L
 cyfHjUucXk6RNR9FDyzpNAuLZk2Kw+znAoDygl2KH9sbmQ7iSekeiYkvnTQsR31f8FKv
 hJd9A8zThfFCYeRTKZR1Xz5QeyYpL2+u6KafhRKyoFP9Z2aNs2BEjSuzYneLM6CJenan
 9il/3vTfU0bd0xuVEdMPuDj5oDnUthCl/VM1AgtPTdCEIdUsabe6PXLlDz2JrlmKATe0
 gfGsp04Oqmvn0l/Vos8Wn2MYNCStXOE2Xj2xnysPm5mig4kwMJUeJFCNFO6epZBfJJkI
 9f2w==
X-Gm-Message-State: AJIora8LuQfe4C+Nl2OlqmRpEdOHP9n6Z6oyWHOe0nLcYJEF0i1qcKJx
 8WljjKhzQFacfUWpLwfSYKaCzTfPL5xzmQ==
X-Google-Smtp-Source: AGRyM1slrYHuBKqnyx/hKyPSWlvTb/weL24dUaHCbZ9G4uiw+A2oqqdGgqVAkuZM3PFQDeqH4c2VpA==
X-Received: by 2002:a17:903:44b:b0:16b:ec58:3727 with SMTP id
 iw11-20020a170903044b00b0016bec583727mr41597836plb.171.1658405444622; 
 Thu, 21 Jul 2022 05:10:44 -0700 (PDT)
Received: from localhost ([2409:8a70:2b7:3fb0:8ec6:81ff:fe70:339d])
 by smtp.gmail.com with ESMTPSA id
 s21-20020a17090ae69500b001f06cabc60asm1341035pjy.30.2022.07.21.05.10.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 21 Jul 2022 05:10:43 -0700 (PDT)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <jwvbktj6ddp.fsf-monnier+emacs@HIDDEN>
References: <874jzdhh5m.fsf@localhost>
 <jwvzgh5m6fq.fsf-monnier+emacs@HIDDEN> <871qug4dyk.fsf@localhost>
 <jwvbktj6ddp.fsf-monnier+emacs@HIDDEN>
Date: Thu, 21 Jul 2022 20:11:49 +0800
Message-ID: <87wnc61x8a.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.3 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

Stefan Monnier <monnier@HIDDEN> writes:

>> 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?

Apart from the reddit thread I mentioned, where the problem comes from
web-mode directly setting font-lock-face, I also provided an example
with noninteractive Emacs in my reply to Eli.

Best,
Ihor

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 21 Jul 2022 12:28:02 +0000
Resent-Message-ID: <handler.56637.B56637.16584064223275 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org, monnier@HIDDEN
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.16584064223275
          (code B ref 56637); Thu, 21 Jul 2022 12:28:02 +0000
Received: (at 56637) by debbugs.gnu.org; 21 Jul 2022 12:27:02 +0000
Received: from localhost ([127.0.0.1]:36843 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oEVGg-0000qb-3J
	for submit <at> debbugs.gnu.org; Thu, 21 Jul 2022 08:27:02 -0400
Received: from eggs.gnu.org ([209.51.188.92]:50486)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1oEVGd-0000qE-2I
 for 56637 <at> debbugs.gnu.org; Thu, 21 Jul 2022 08:27:00 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:51034)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1oEVGX-0004UX-RN; Thu, 21 Jul 2022 08:26:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=gY3nYdLka9C9oUtAZ4Jh3j5iqf6IxF3bDRd5hyBo17E=; b=AQXXkYLrsGPu
 zwYpoDEze0ZBZ21wwTYxOXHT7VzPG2x4hkFimf8e0TSDSGlCBtIUS5fqQgxugcITCl/JKkTUIpFoe
 kDfEQEegU1sqaSZT3zDZR821+714oLeZ3+t1dd7WxRKhCZWEHEEToZ61mL5+g31Hr6Vsl+KCDQyfw
 QoPiW+o5iKdw4ibguDjY564hZ4b6sI6bcBeYxDhhDU6DhJoCKioPks0fE2kAC75s3RkQi56fh1YYi
 WPJdYMZYM2YrqTAVO7WQiHHsDXYyRF9XUhhxSp9F0a7iq9t7AozRvPWpCmZ64uPTOPjz+/bjj1Alr
 X8HPRCh6cLXym64sqSIONg==;
Received: from [87.69.77.57] (port=2513 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1oEVGX-0002Pz-4J; Thu, 21 Jul 2022 08:26:53 -0400
Date: Thu, 21 Jul 2022 15:26:47 +0300
Message-Id: <831queodmg.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87zgh21xbg.fsf@localhost> (message from Ihor Radchenko on Thu,
 21 Jul 2022 20:09:55 +0800)
References: <874jzdhh5m.fsf@localhost> <837d49ntwg.fsf@HIDDEN>
 <874jzc4e1x.fsf@localhost> <837d48m332.fsf@HIDDEN> <87zgh21xbg.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: monnier@HIDDEN,  56637 <at> debbugs.gnu.org
> Date: Thu, 21 Jul 2022 20:09:55 +0800
> 
> >> Is it always guaranteed by Emacs that font-lock-fontify-buffer correctly
> >> fontifies that buffer even when font-lock-mode is disabled?
> >
> > IMO, if it doesn't, it's a bug that should be fixed.  If you have
> > recipes where it happens, please submit a bug report.
> 
> Create a file called bug.el with the following text:
> 
> (with-current-buffer (get-buffer-create "Test")
>   (emacs-lisp-mode)
>   (insert "(message \"Foo\")")
>   (font-lock-ensure)
>   (message "%S" (buffer-string)))
> 
> Then, run
> emacs-29-vcs -Q --script /tmp/bug.el
> 
> Observed output: #("(message \"Foo\")" 9 14 (face font-lock-string-face))
> Expected: #("(message \"Foo\")" 0 9 (fontified t) 9 14 (face font-lock-string-face fontified t) 14 15 (fontified t))
> 
> The expected output appears in *Messages* when you run 
> emacs-29-vcs -Q -l /tmp/bug.el

You said font-lock-fontify-buffer, not font-lock-ensure...

Anyway, I hope Stefan will look into this.

> > If you create buffer, process text in it, then write it out and kill
> > the buffer, all in one go, there should be no reason to use a buffer
> > whose name begins with a space, because interactive users will not
> > have an opportunity to see such a buffer in the Emacs session.
> >
> > This problem is only real when a temporary buffer is left around
> > because, for example, it is being collected/processed asynchronously,
> > or in several stages with the user being able to interact with Emacs
> > in-between.
> 
> Killing the buffer where we do fontification is too slow for Org.
> If Org were to use temporary buffers, it would need to load major mode
> for every text fragment to be fontified. Loading major modes (at least
> some major modes) is taking significant amount of time and should
> better be avoided if we can simply reuse a single buffer with major mode
> that is already loaded.

Sorry, I don't understand: once Emacs loads a major mode, it stays
loaded, unless you forcibly unload it.  Or what do you mean by "load
major mode"?

And why do you assume that erasing a buffer and then inserting some
text into it will be significantly faster than turning on a mode in
it?  It sounds like another fragile assumption.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 21 Jul 2022 12:44:01 +0000
Resent-Message-ID: <handler.56637.B56637.16584074065077 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org, monnier@HIDDEN
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.16584074065077
          (code B ref 56637); Thu, 21 Jul 2022 12:44:01 +0000
Received: (at 56637) by debbugs.gnu.org; 21 Jul 2022 12:43:26 +0000
Received: from localhost ([127.0.0.1]:36874 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oEVWX-0001Jp-SN
	for submit <at> debbugs.gnu.org; Thu, 21 Jul 2022 08:43:26 -0400
Received: from mail-pj1-f41.google.com ([209.85.216.41]:51170)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1oEVWW-0001Jb-5B
 for 56637 <at> debbugs.gnu.org; Thu, 21 Jul 2022 08:43:24 -0400
Received: by mail-pj1-f41.google.com with SMTP id go3so1540287pjb.0
 for <56637 <at> debbugs.gnu.org>; Thu, 21 Jul 2022 05:43:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=from:to:cc:subject:in-reply-to:references:date:message-id
 :mime-version; bh=Tc0re8lxjCe/HmEgFtJKvstoIICpvqtFV6hycQyRk0w=;
 b=E1jCEqETZqSXuJXh/t+qv55DmvfG4LTAnkshGXP9AbRZ3+B/TBej0BwtZ77tVybGQA
 Q9MAbWMh4ZnN85bNP/V/9Qc/CENmfjQof8R+UQ6pGFcuiWOxspcnUfNNOpttNZBSYgj5
 CvjSPJDjtX3pKJ/nuupOD+RBiOm/dX175XugLclPO5LvlIAhoAyvqoOuM6UaMq7EviZ+
 sUr7RSHeb3kAklwqtTKQknx1eBRpnAa+DzbS/atHC6YzROTrDElFq1II584/631SyIKi
 XUKmk9+ir9EGtNXrFNq502Ectr/r3MM3J1+WCdJJKFwXrzbOleHnAGkSdoaPZEC4mrXh
 nxFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date
 :message-id:mime-version;
 bh=Tc0re8lxjCe/HmEgFtJKvstoIICpvqtFV6hycQyRk0w=;
 b=y0efMX12XB/hSuL7dzYUg+6f8baldla7RbpX2PxU+KrWZVeFpSjCaGRy2TCYKbDAW6
 L8gR7w7YwbOj/UIMEAi6NPW1qJRuDqrBzPK+ci+4uX/xznZvHEg0FG3hol4aA+eyKzC3
 FyY9nS1iRfGN5OhmF1pbLMe8gCPZ3hVoh3eCWdOl7/UogQ6wORERcHNGZw1SGgZtyd2t
 KYq9ykDcgki5XCk/auNUV6Z/ksZa1Nb+/sn0nTkoDjNdj4C+3C6LFYgPQSHfFzCC0hPm
 FRQoNYvDXdC1v7JNAlIHjYtSjOUux5Rnw3DyMNmYJ13RxNHSPiiwcjhxNeKgHftxvxzY
 6n7A==
X-Gm-Message-State: AJIora8Re8roa2/mvNJKGM1QDmE6hRQ4N5xS+yFAx1qrcBx0K0quqTP3
 P8TYmqUcHcZ1VqAESPQRgVreylaB5tZkEg==
X-Google-Smtp-Source: AGRyM1u+goEB5nbjr87A1V22/+3WEMrSbldjxivNf7LF2W6q214K9Kjx28NbfANAeILlD2GIj9bMqw==
X-Received: by 2002:a17:902:d4c6:b0:16d:2f7f:9a71 with SMTP id
 o6-20020a170902d4c600b0016d2f7f9a71mr3911198plg.36.1658407398149; 
 Thu, 21 Jul 2022 05:43:18 -0700 (PDT)
Received: from localhost ([2409:8a70:2b7:3fb0:8ec6:81ff:fe70:339d])
 by smtp.gmail.com with ESMTPSA id
 a15-20020a170902eccf00b001641b2d61d4sm1635137plh.30.2022.07.21.05.43.17
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 21 Jul 2022 05:43:17 -0700 (PDT)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <831queodmg.fsf@HIDDEN>
References: <874jzdhh5m.fsf@localhost> <837d49ntwg.fsf@HIDDEN>
 <874jzc4e1x.fsf@localhost> <837d48m332.fsf@HIDDEN>
 <87zgh21xbg.fsf@localhost> <831queodmg.fsf@HIDDEN>
Date: Thu, 21 Jul 2022 20:44:23 +0800
Message-ID: <87r12e1vq0.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.3 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

Eli Zaretskii <eliz@HIDDEN> writes:

> You said font-lock-fontify-buffer, not font-lock-ensure...

Either way. They should both fontify the buffer with font-lock-ensure
not skipping any parts guaranteed.

In any case, changing font-lock-ensure to font-lock-fontify-buffer will
not change failure to fontify using the report steps.

>> Killing the buffer where we do fontification is too slow for Org.
>> If Org were to use temporary buffers, it would need to load major mode
>> for every text fragment to be fontified. Loading major modes (at least
>> some major modes) is taking significant amount of time and should
>> better be avoided if we can simply reuse a single buffer with major mode
>> that is already loaded.
>
> Sorry, I don't understand: once Emacs loads a major mode, it stays
> loaded, unless you forcibly unload it.  Or what do you mean by "load
> major mode"?

If fontification is done in temporary throwaway buffers that are closed
immediately after fontification, next portion of text that should be
fontified in the same major mode will need to create a new throwaway
buffer, turn on the relevant major mode, and perform fontification.
Hence, major mode will need to be loaded every single time we need to
fontify a text fragment.

> And why do you assume that erasing a buffer and then inserting some
> text into it will be significantly faster than turning on a mode in
> it?  It sounds like another fragile assumption.

It is usually true from my experience.

To illustrate, try to create a buffer and run the following:

(progn (emacs-lisp-mode) (benchmark-run 100 (erase-buffer) (insert "(+ 1 2)") (font-lock-ensure)))

(benchmark-run 100 (erase-buffer) (insert "(+ 1 2)") (emacs-lisp-mode) (font-lock-ensure) (fundamental-mode))

The results are:

(5.531764251 0 0.0)
(0.012424528 0 0.0)

Over 400x difference.

Best,
Ihor

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 21 Jul 2022 12:50:02 +0000
Resent-Message-ID: <handler.56637.B56637.16584077945880 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org, monnier@HIDDEN
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.16584077945880
          (code B ref 56637); Thu, 21 Jul 2022 12:50:02 +0000
Received: (at 56637) by debbugs.gnu.org; 21 Jul 2022 12:49:54 +0000
Received: from localhost ([127.0.0.1]:36879 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oEVcn-0001Wl-O0
	for submit <at> debbugs.gnu.org; Thu, 21 Jul 2022 08:49:54 -0400
Received: from eggs.gnu.org ([209.51.188.92]:55132)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1oEVcl-0001WX-Ll
 for 56637 <at> debbugs.gnu.org; Thu, 21 Jul 2022 08:49:52 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:51406)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1oEVcg-0000ZZ-7O; Thu, 21 Jul 2022 08:49:46 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=MyxCvrW4f3tqhMAeOOce6RkxPEIZuYo9GhcBp6OLH60=; b=sdsulBWiRYG/
 tOqZdIiG23sD+bjUIR4Yova/ZGsBdccbpE4IZpAbS4093Mkok4gXSc8RBJ3uYEjZok4xYFnKvPHf7
 Fs/0dz66aQO++25BAbWiXcI/KWruJvomagvkSsEsyioozdHpT/rPEa3dj18djMCCT08bpvHJIQvJv
 bJ3PULHizH8+odrxYpnj6BU7JRSO8rwPtzgOr8cyzam+x20o8lx7/YG91HAdInweznqJWaj/zTv+O
 hsSrovhhkZdBi0KJtuXKfla3q7zOC/C3O2MezhZortFJYSiH6RT93+JsV/yqlgSaBXo/ZexIqI1i3
 ag3cv+F/yeenqbcAJd24rg==;
Received: from [87.69.77.57] (port=3959 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1oEVcf-0002tL-EP; Thu, 21 Jul 2022 08:49:46 -0400
Date: Thu, 21 Jul 2022 15:49:38 +0300
Message-Id: <83tu7amxzx.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87r12e1vq0.fsf@localhost> (message from Ihor Radchenko on Thu,
 21 Jul 2022 20:44:23 +0800)
References: <874jzdhh5m.fsf@localhost> <837d49ntwg.fsf@HIDDEN>
 <874jzc4e1x.fsf@localhost> <837d48m332.fsf@HIDDEN>
 <87zgh21xbg.fsf@localhost> <831queodmg.fsf@HIDDEN> <87r12e1vq0.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: monnier@HIDDEN,  56637 <at> debbugs.gnu.org
> Date: Thu, 21 Jul 2022 20:44:23 +0800
> 
> > Sorry, I don't understand: once Emacs loads a major mode, it stays
> > loaded, unless you forcibly unload it.  Or what do you mean by "load
> > major mode"?
> 
> If fontification is done in temporary throwaway buffers that are closed
> immediately after fontification, next portion of text that should be
> fontified in the same major mode will need to create a new throwaway
> buffer, turn on the relevant major mode, and perform fontification.
> Hence, major mode will need to be loaded every single time we need to
> fontify a text fragment.

It is not "loaded", it is "activated".  "Loading" in Emacs means
loading the Lisp package that implements the mode, and that is done
only once.  We don't unload packages when buffers are killed.

> > And why do you assume that erasing a buffer and then inserting some
> > text into it will be significantly faster than turning on a mode in
> > it?  It sounds like another fragile assumption.
> 
> It is usually true from my experience.

Well, "usually" is not a guarantee it will always be so.

Anyway, if this is the issue, we could add another way of marking a
buffer as "invisible for user", one that is not based on the buffer's
name.

> (5.531764251 0 0.0)
> (0.012424528 0 0.0)
> 
> Over 400x difference.

Sorry, but this proves nothing, and I'm sure you know it.

To me, this is just one more fragile assumption on which Org code is
based that is bound to be broken some day.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 21 Jul 2022 13:18:02 +0000
Resent-Message-ID: <handler.56637.B56637.16584094578733 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org, monnier@HIDDEN
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.16584094578733
          (code B ref 56637); Thu, 21 Jul 2022 13:18:02 +0000
Received: (at 56637) by debbugs.gnu.org; 21 Jul 2022 13:17:37 +0000
Received: from localhost ([127.0.0.1]:36909 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oEW3d-0002Gn-D3
	for submit <at> debbugs.gnu.org; Thu, 21 Jul 2022 09:17:37 -0400
Received: from mail-pf1-f172.google.com ([209.85.210.172]:36693)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1oEW3a-0002GV-Mr
 for 56637 <at> debbugs.gnu.org; Thu, 21 Jul 2022 09:17:36 -0400
Received: by mail-pf1-f172.google.com with SMTP id g12so1744031pfb.3
 for <56637 <at> debbugs.gnu.org>; Thu, 21 Jul 2022 06:17:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=from:to:cc:subject:in-reply-to:references:date:message-id
 :mime-version; bh=qPP1g4N9D359p6Q53jIZMIL1v2FVZo7koUnIqKQu9fU=;
 b=kLyMHUM/YpAn4zbKOs8qw7teApoc20mFCNBV/qABWASFxxrzg95ZKCBkfxN3nNgy4g
 /p0/2MCAJJJQhcdu4KBugJUbQNMxE/nb5vyOry48n2kjXvgNfiYaxd3zPxVi5lLjeZ+W
 /XdH5SMY/nSXl4u7U0XCDfUnH12HYQCxebCqx8u6mPyYKTIRpt9kfzsfuWoM9NtDLLoQ
 fK86UaiyUgx0XfBJPr0wZcEXzoxc9k9Qas6HOX7wO/OWqHhguywq+ye/1AfRMD0JZ5Jl
 LU5Pw2Ji9ssD2pRpOCIohD62WVYbxO73FIKoIvpwm/kPBHUrljDRtzWMKhagcOxFbfaK
 CWXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date
 :message-id:mime-version;
 bh=qPP1g4N9D359p6Q53jIZMIL1v2FVZo7koUnIqKQu9fU=;
 b=g3O3u4Cbq7REsVApDrSbyfZNUh12i+f2UeUYYRbqPsrtKxyKUEBWTU8fbaQmQy7sUL
 Ce9/6/thr0KyQKviDWOg6sK+JnLaktI2MC1NcETfMR9jiiwfKe26uI2tCSkyfo3RHHXr
 SLxZ0bkkR/qKMYuGY5xWMZtNr4CJuTlvA7No/i4rfvg6NPU/SB82lNC74AOu20zH+Esa
 0h49J3+xifIrNP2OybnkYMI7S8T6mjt24MSHlf05GgipqacsJmkgupdGsCmOY3rr2/ky
 BmVNi88K+ol0+WuGkrQsgQstWxQwxZNdN0IwSTgt6GD2mThjNUWm13q7uwJVgf7E4dd+
 LV5w==
X-Gm-Message-State: AJIora876aeI95y4YYFbWeynlESVcOcGUuO58kxpQ5bjX2nCNJEvrQ/C
 xWf8Er9Ekfpn3Hwmuz7P3aQ=
X-Google-Smtp-Source: AGRyM1u9+qVnhyCUxLBs1TarJ/BHwi/1Rn5qznlplYOpQ8uGAE27Ai8udhuSxUS4iIcS6UXpIc4VKg==
X-Received: by 2002:a63:1213:0:b0:41a:8d6b:3e80 with SMTP id
 h19-20020a631213000000b0041a8d6b3e80mr1036714pgl.388.1658409448787; 
 Thu, 21 Jul 2022 06:17:28 -0700 (PDT)
Received: from localhost ([2409:8a70:2b7:3fb0:8ec6:81ff:fe70:339d])
 by smtp.gmail.com with ESMTPSA id
 ft7-20020a17090b0f8700b001efeb4c813csm1404981pjb.13.2022.07.21.06.17.27
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 21 Jul 2022 06:17:28 -0700 (PDT)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <83tu7amxzx.fsf@HIDDEN>
References: <874jzdhh5m.fsf@localhost> <837d49ntwg.fsf@HIDDEN>
 <874jzc4e1x.fsf@localhost> <837d48m332.fsf@HIDDEN>
 <87zgh21xbg.fsf@localhost> <831queodmg.fsf@HIDDEN>
 <87r12e1vq0.fsf@localhost> <83tu7amxzx.fsf@HIDDEN>
Date: Thu, 21 Jul 2022 21:18:34 +0800
Message-ID: <87o7xi1u51.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.2 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.8 (/)

Eli Zaretskii <eliz@HIDDEN> writes:

>> If fontification is done in temporary throwaway buffers that are closed
>> immediately after fontification, next portion of text that should be
>> fontified in the same major mode will need to create a new throwaway
>> buffer, turn on the relevant major mode, and perform fontification.
>> Hence, major mode will need to be loaded every single time we need to
>> fontify a text fragment.
>
> It is not "loaded", it is "activated".  "Loading" in Emacs means
> loading the Lisp package that implements the mode, and that is done
> only once.  We don't unload packages when buffers are killed.

Thanks for the clarification.

>> > And why do you assume that erasing a buffer and then inserting some
>> > text into it will be significantly faster than turning on a mode in
>> > it?  It sounds like another fragile assumption.
>> 
>> It is usually true from my experience.
>
> Well, "usually" is not a guarantee it will always be so.

We do not need such a guarantee. The choice between temporary throwaway
buffers and single major-mode buffer where we insert/remove text is
about speed. Even if reusing the buffer is faster in 90% of major modes
and not 100%, it is a big improvement.

> Anyway, if this is the issue, we could add another way of marking a
> buffer as "invisible for user", one that is not based on the buffer's
> name.
>
>> (5.531764251 0 0.0)
>> (0.012424528 0 0.0)
>> 
>> Over 400x difference.
>
> Sorry, but this proves nothing, and I'm sure you know it.

It was an _illustration_. The decision to reuse buffer was not
arbitrary. Org mode developers and users tested the throwaway buffer
approach, found it too slow and changed to reusing a single major-mode
buffer. The latter is faster in practice.

> To me, this is just one more fragile assumption on which Org code is
> based that is bound to be broken some day.

It is a heuristic. If it is broken, nothing terrible will happen.
Fontification will still work, albeit slower. If the slowdown will be
reported widely, we can always change to the alternative approach.

Also, I am not sure why you are making such a strong claim about "that
is bound to be broken some day". Throwaway buffer will require (1)
creating buffer; (2) activating major-mode; (3) fontification. Reusable
buffer will require (1) Handling major mode's
before/after-change-functions; (2) fontification.

Before/after-change-functions are fast. If not, the relevant major mode
is a terrible mode anyway and should not be used. There is no such
pressure to optimize the activation time, in comparison.

Best,
Ihor

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 21 Jul 2022 15:14:02 +0000
Resent-Message-ID: <handler.56637.B56637.165841640722441 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 56637 <at> debbugs.gnu.org
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.165841640722441
          (code B ref 56637); Thu, 21 Jul 2022 15:14:02 +0000
Received: (at 56637) by debbugs.gnu.org; 21 Jul 2022 15:13:27 +0000
Received: from localhost ([127.0.0.1]:38626 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oEXrj-0005pt-E2
	for submit <at> debbugs.gnu.org; Thu, 21 Jul 2022 11:13:27 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:31848)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1oEXri-0005pe-4H
 for 56637 <at> debbugs.gnu.org; Thu, 21 Jul 2022 11:13:26 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 860B880767;
 Thu, 21 Jul 2022 11:13:20 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 020C580012;
 Thu, 21 Jul 2022 11:13:19 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1658416399;
 bh=MB+WfzS/W36Yh/vYwIhcQdMEYCbjKgvARoQ/jgAObX4=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=kFEPEHBlOkVtP3+oRNte9LL3Bq359EYLdMovp43CKcjYDGL3AnW/y+TeZvfMcC8Bq
 qgo8DJhRNOWuKxJSPkDlcbM1l4iL5hnnIswFvbZGcGlWnMr6zFBLB3hhlhg7BIkxku
 szz1f0ulgGk2L/D43ywhQvMRxAEbrG2C3EDn2BxX3o/B7Jt5WAu6aL0GA7quDwPc4v
 NeG2G0nKw1cTqB/Ef5Z1wMU3ajrw5E4k8KP0iDTKX1mLr/LtonLDwc7jOY9c4IhdUS
 CSTKdPJk1wsgw7q7/uq6NVJ3pPj5tekqSU1f8fxU/L9rYQHUgGq1JI/o6IUhDPsg1S
 PgeEkbTubakJQ==
Received: from pastel (unknown [45.72.195.111])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id CF5E012026E;
 Thu, 21 Jul 2022 11:13:18 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <87zgh21xbg.fsf@localhost> (Ihor Radchenko's message of "Thu, 21
 Jul 2022 20:09:55 +0800")
Message-ID: <jwv4jzaijro.fsf-monnier+emacs@HIDDEN>
References: <874jzdhh5m.fsf@localhost> <837d49ntwg.fsf@HIDDEN>
 <874jzc4e1x.fsf@localhost> <837d48m332.fsf@HIDDEN>
 <87zgh21xbg.fsf@localhost>
Date: Thu, 21 Jul 2022 11:13:17 -0400
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.059 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Observed output: #("(message \"Foo\")" 9 14 (face font-lock-string-face))
> Expected: #("(message \"Foo\")" 0 9 (fontified t) 9 14 (face
> font-lock-string-face fontified t) 14 15 (fontified t))

`fontified` is not a text-property that belongs to font-lock but to
jit-lock, so its presence or absence depends on how font-lock is being
used (it can also be absent if you set `font-lock-support-mode to nil,
for example, and it can also be present even if you don't use font-lock
at all), so I would count this as "an incorrect expectation" rather
than as a bug.

Why do you care about those `fontified` properties?


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 21 Jul 2022 18:40:02 +0000
Resent-Message-ID: <handler.56637.B56637.165842880121509 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.165842880121509
          (code B ref 56637); Thu, 21 Jul 2022 18:40:02 +0000
Received: (at 56637) by debbugs.gnu.org; 21 Jul 2022 18:40:01 +0000
Received: from localhost ([127.0.0.1]:39078 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oEb5c-0005al-Us
	for submit <at> debbugs.gnu.org; Thu, 21 Jul 2022 14:40:01 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:38708)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1oEb5b-0005aZ-3q
 for 56637 <at> debbugs.gnu.org; Thu, 21 Jul 2022 14:39:59 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 2CDB480012;
 Thu, 21 Jul 2022 14:39:53 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D60338025B;
 Thu, 21 Jul 2022 14:39:50 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1658428790;
 bh=xNc+6oDuNYJkG1Qeg2CHV5et75MjcLZJTGF6+ZPPlbQ=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=Mru5X3jmAeo2Pm6515dn7GJhJgfQuCcpi6khGFm+DoZzoL284RCS2qT401U2YKwnK
 OzmW5/gq0jJiRww5CLbQ6eCEYla1pDPZKZEih/Kpbh6Ix51QEchSNlrn/+K2z0ZY96
 1yy92DVJgT1ODR4u20N2Q/D+VkrSNlVFvwUfnAT8tPVK5fswsSLBwSoRavmcNsRF9z
 OJvGB3lvHBqc+nxFZ+6bicQ+Y1/JOOLIMoUU4UsfVQGg9KB+kGpM6wvjRxm8U++1o2
 16TP6Lwnh7QyppdNNOYRg0+ki83Rbuhz3j9d04Q4hSmq9U+8lbj1wy5HVuZhEaSh0h
 /DmziO+V/OxyQ==
Received: from pastel (unknown [45.72.195.111])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id ACA0E12022C;
 Thu, 21 Jul 2022 14:39:50 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <87wnc61x8a.fsf@localhost> (Ihor Radchenko's message of "Thu, 21
 Jul 2022 20:11:49 +0800")
Message-ID: <jwvilnqfh02.fsf-monnier+emacs@HIDDEN>
References: <874jzdhh5m.fsf@localhost> <jwvzgh5m6fq.fsf-monnier+emacs@HIDDEN>
 <871qug4dyk.fsf@localhost> <jwvbktj6ddp.fsf-monnier+emacs@HIDDEN>
 <87wnc61x8a.fsf@localhost>
Date: Thu, 21 Jul 2022 14:39:47 -0400
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.060 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Apart from the reddit thread I mentioned, where the problem comes from
> web-mode directly setting font-lock-face,

I didn't see a clear recipe there, tho.  Setting the `font-lock-face`
directly is normal, so it's not clear that it's a problem on the side of
`web-mode`, really.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 23 Jul 2022 07:55:02 +0000
Resent-Message-ID: <handler.56637.B56637.16585628507589 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org, Ihor Radchenko <yantar92@HIDDEN>
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.16585628507589
          (code B ref 56637); Sat, 23 Jul 2022 07:55:02 +0000
Received: (at 56637) by debbugs.gnu.org; 23 Jul 2022 07:54:10 +0000
Received: from localhost ([127.0.0.1]:43195 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oF9xh-0001yL-NJ
	for submit <at> debbugs.gnu.org; Sat, 23 Jul 2022 03:54:09 -0400
Received: from quimby.gnus.org ([95.216.78.240]:48110)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1oF9xg-0001y5-75
 for 56637 <at> debbugs.gnu.org; Sat, 23 Jul 2022 03:54:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References:
 In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=EPoAWX4ymxgTrNtxIGJ2LZBqOsLNSSQxvLyCynW1JDs=; b=XrPa0QEJoQK5+AMK90ZwGS1l3j
 Gs3oyaSVTPJwDDsKYLnId7hIMO8MkECJy9N540qJRNgu/Iok/9cRnxZzLmLUtfCyHAfe9VmCmTs87
 ZMNcb0Fdeqlk9/oNeC9wgZ6czU+4d6n4j1S0slVdKnKRGXoyAC4NjVCeQToEWudcTgoI=;
Received: from [84.212.220.105] (helo=joga)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1oF9xV-0008SK-UJ; Sat, 23 Jul 2022 09:54:00 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
In-Reply-To: <jwvbktj6ddp.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
 of "Wed, 20 Jul 2022 10:58:58 -0400")
References: <874jzdhh5m.fsf@localhost> <jwvzgh5m6fq.fsf-monnier+emacs@HIDDEN>
 <871qug4dyk.fsf@localhost> <jwvbktj6ddp.fsf-monnier+emacs@HIDDEN>
X-Now-Playing: The Residents's _Subterranean Modern_: "Dumbo, The Clown (Who
 Loved Christmas)"
Date: Sat, 23 Jul 2022 09:53:55 +0200
Message-ID: <878rok2rjg.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview:  Stefan Monnier <monnier@HIDDEN> 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 wit [...] 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Stefan Monnier <monnier@HIDDEN> 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?

I saw that other proposed patch (with `font-lock-mode-unconditionally'),
but I'm not sure that would be as obvious a solution.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 23 Jul 2022 08:56:01 +0000
Resent-Message-ID: <handler.56637.B56637.16585665287804 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org, monnier@HIDDEN, yantar92@HIDDEN
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.16585665287804
          (code B ref 56637); Sat, 23 Jul 2022 08:56:01 +0000
Received: (at 56637) by debbugs.gnu.org; 23 Jul 2022 08:55:28 +0000
Received: from localhost ([127.0.0.1]:43412 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oFAv1-00021n-Nr
	for submit <at> debbugs.gnu.org; Sat, 23 Jul 2022 04:55:28 -0400
Received: from eggs.gnu.org ([209.51.188.92]:33298)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1oFAun-00021D-Bm
 for 56637 <at> debbugs.gnu.org; Sat, 23 Jul 2022 04:55:26 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:36012)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1oFAui-0001ET-2q; Sat, 23 Jul 2022 04:55:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=BfPpQLPQPvd/4xeXgZGOjyk8hS05esENKwbGsEWWRH4=; b=IybuHxSiJ0YP
 tRnlNLCUQTtUj1CDc2FmJqQvQYTmnqPq85QH0WYivHueyLrTSdwrcp3tjP/aspZPLhxtmQtr/V9fz
 TWEsnc5RwspjhW16CEKfTqTHxTZ+fsHTsxSjfz31qXb3r3APOc/ZImzx/Il1VyLhWW02HgNUKbq3L
 wxEFTRc/Apf/BrxTC9c6q82qvZYWec7S70wQuFIHtxeQSm+E0MSrH2a5OugUfb7zDfpQm0f47ZnFM
 z5KlQ+fawvDeWHjT5z/JlyCIEobWRay3JQdTkubWeTP/tESlPHpVOxxrv1RFn/mulOBQGmK59XkXL
 Y5itsrkBsPN27o8DdMLcSA==;
Received: from [87.69.77.57] (port=4207 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1oFAuh-0002Yc-IU; Sat, 23 Jul 2022 04:55:07 -0400
Date: Sat, 23 Jul 2022 11:55:05 +0300
Message-Id: <83mtd0i4ye.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <878rok2rjg.fsf@HIDDEN> (message from Lars Ingebrigtsen on Sat, 
 23 Jul 2022 09:53:55 +0200)
References: <874jzdhh5m.fsf@localhost> <jwvzgh5m6fq.fsf-monnier+emacs@HIDDEN>
 <871qug4dyk.fsf@localhost> <jwvbktj6ddp.fsf-monnier+emacs@HIDDEN>
 <878rok2rjg.fsf@HIDDEN>
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: 56637 <at> debbugs.gnu.org, Ihor Radchenko <yantar92@HIDDEN>
> From: Lars Ingebrigtsen <larsi@HIDDEN>
> Date: Sat, 23 Jul 2022 09:53:55 +0200
> 
> Stefan Monnier <monnier@HIDDEN> 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 23 Jul 2022 13:47:02 +0000
Resent-Message-ID: <handler.56637.B56637.16585840017397 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 56637
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: 56637 <at> debbugs.gnu.org, Ihor Radchenko <yantar92@HIDDEN>
Received: via spool by 56637-submit <at> debbugs.gnu.org id=B56637.16585840017397
          (code B ref 56637); Sat, 23 Jul 2022 13:47:02 +0000
Received: (at 56637) by debbugs.gnu.org; 23 Jul 2022 13:46:41 +0000
Received: from localhost ([127.0.0.1]:43817 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oFFSr-0001vF-AC
	for submit <at> debbugs.gnu.org; Sat, 23 Jul 2022 09:46:41 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:53911)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1oFFSm-0001ur-Qk
 for 56637 <at> debbugs.gnu.org; Sat, 23 Jul 2022 09:46:39 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C77B410027D;
 Sat, 23 Jul 2022 09:46:30 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BB011100120;
 Sat, 23 Jul 2022 09:46:24 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1658583984;
 bh=gD9S7TEmjfG1hZMqJ/cXs5cz0ZDUSgL2JsfWErrGDFE=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=WGH9kocgHq2RcxiWSiAP+U0IyaOHSZHNE4kGobMInU30z+yOH4wdSAm3gJkMkZSVv
 2000n4EISaP+Rg7+NS9ZlOM3BZckUqbyOjfvBqiKI63vFz8kp6bITX9owtVM9cs9iu
 E08MS5PUHMBU2AHzCIWjtaDSrs8dz4PQzQkhcI51wOmMggLgnv+gUb66DXhaoBCyyj
 5O9zunB9gW9v0IbqqTADm6/J07wtuKyoXBVGUh5SAwa5ecbnKc9sd4uNnizEV3bkWI
 HhieoXqvngXTHCKwb5Vgl5128G8k3uvuCVCbIGI4MVmGE+RF6+cDCiOkekfwjT+IkT
 GBfLC8S/u+Sqw==
Received: from pastel (unknown [45.72.195.111])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 75BF31201F4;
 Sat, 23 Jul 2022 09:46:24 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <878rok2rjg.fsf@HIDDEN> (Lars Ingebrigtsen's message of "Sat,
 23 Jul 2022 09:53:55 +0200")
Message-ID: <jwvczdw7xkn.fsf-monnier+emacs@HIDDEN>
References: <874jzdhh5m.fsf@localhost> <jwvzgh5m6fq.fsf-monnier+emacs@HIDDEN>
 <871qug4dyk.fsf@localhost> <jwvbktj6ddp.fsf-monnier+emacs@HIDDEN>
 <878rok2rjg.fsf@HIDDEN>
Date: Sat, 23 Jul 2022 09:46:21 -0400
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.051 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> 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?

I haven't seen a bug report yet, so I don't know what there is to fix,
so I really can't judge.  But my request for a bug report is indeed
because I hope the problem can be fixed on the side of
`font-lock-ensure`.


        Stefan

Last modified: Sat, 23 Jul 2022 14:00:02 UTC

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