From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" 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: Tue, 19 Jul 2022 17:12:44 -0400 Message-ID: References: <874jzdhh5m.fsf@localhost> <83mtd5m54h.fsf@gnu.org> <83ilntlydv.fsf@gnu.org> <83cze0nbk2.fsf@gnu.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23450"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: 56637@debbugs.gnu.org, yantar92@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jul 19 23:13:11 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 1oDuWk-0005vx-Bp for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 19 Jul 2022 23:13:10 +0200 Original-Received: from localhost ([::1]:43632 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oDuWi-0005bB-US for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 19 Jul 2022 17:13:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55444) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oDuWb-0005ao-VH for bug-gnu-emacs@gnu.org; Tue, 19 Jul 2022 17:13:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57553) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oDuWb-0007Kv-MX for bug-gnu-emacs@gnu.org; Tue, 19 Jul 2022 17:13:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oDuWb-0004Ws-H0 for bug-gnu-emacs@gnu.org; Tue, 19 Jul 2022 17:13:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 19 Jul 2022 21:13: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.165826517817400 (code B ref 56637); Tue, 19 Jul 2022 21:13:01 +0000 Original-Received: (at 56637) by debbugs.gnu.org; 19 Jul 2022 21:12:58 +0000 Original-Received: from localhost ([127.0.0.1]:55312 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oDuWX-0004Wa-IL for submit@debbugs.gnu.org; Tue, 19 Jul 2022 17:12:57 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:10612) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oDuWS-0004WK-EH for 56637@debbugs.gnu.org; Tue, 19 Jul 2022 17:12:55 -0400 Original-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) Original-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== Original-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) In-Reply-To: <83cze0nbk2.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 19 Jul 2022 22:32:13 +0300") 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:237468 Archived-At: >> >> 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