From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#56637: 28.1.90; [FR] Allow a way around font-lock-mode being unconditionally disabled in " *hidden*" buffers Date: Wed, 20 Jul 2022 14:32:49 +0300 Message-ID: <837d48m332.fsf@gnu.org> References: <874jzdhh5m.fsf@localhost> <837d49ntwg.fsf@gnu.org> <874jzc4e1x.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30306"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56637@debbugs.gnu.org, monnier@iro.umontreal.ca To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jul 20 13:57:31 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oE8KX-0007iL-Qp for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 20 Jul 2022 13:57:30 +0200 Original-Received: from localhost ([::1]:47326 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oE8KW-0001Ss-Ot for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 20 Jul 2022 07:57:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34192) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oE7xq-00057r-Qs for bug-gnu-emacs@gnu.org; Wed, 20 Jul 2022 07:34:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58265) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oE7xp-0002xe-Ud for bug-gnu-emacs@gnu.org; Wed, 20 Jul 2022 07:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oE7xp-0006EQ-R1 for bug-gnu-emacs@gnu.org; Wed, 20 Jul 2022 07:34:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 20 Jul 2022 11:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56637 X-GNU-PR-Package: emacs Original-Received: via spool by 56637-submit@debbugs.gnu.org id=B56637.165831679823896 (code B ref 56637); Wed, 20 Jul 2022 11:34:01 +0000 Original-Received: (at 56637) by debbugs.gnu.org; 20 Jul 2022 11:33:18 +0000 Original-Received: from localhost ([127.0.0.1]:56022 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oE7x6-0006DK-VZ for submit@debbugs.gnu.org; Wed, 20 Jul 2022 07:33:18 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:49372) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oE7wv-0006Cg-Rs for 56637@debbugs.gnu.org; Wed, 20 Jul 2022 07:33:15 -0400 Original-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 ) 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==; Original-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 ) id 1oE7wp-00043F-0y; Wed, 20 Jul 2022 07:32:59 -0400 In-Reply-To: <874jzc4e1x.fsf@localhost> (message from Ihor Radchenko on Wed, 20 Jul 2022 12:13:14 +0800) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:237493 Archived-At: > From: Ihor Radchenko > Cc: Stefan Monnier , 56637@debbugs.gnu.org > Date: Wed, 20 Jul 2022 12:13:14 +0800 > > Eli Zaretskii 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?