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: Wed, 20 Jul 2022 11:15:20 -0400 Message-ID: References: <874jzdhh5m.fsf@localhost> <83mtd5m54h.fsf@gnu.org> <83ilntlydv.fsf@gnu.org> <83cze0nbk2.fsf@gnu.org> <83a694m40y.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="22612"; 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 Wed Jul 20 17:16:28 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 1oEBR5-0005ct-Ta for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 20 Jul 2022 17:16:28 +0200 Original-Received: from localhost ([::1]:53728 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oEBR4-00061H-L5 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 20 Jul 2022 11:16:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34516) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEBQg-000613-LB for bug-gnu-emacs@gnu.org; Wed, 20 Jul 2022 11:16:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60850) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oEBQg-0003iy-2R for bug-gnu-emacs@gnu.org; Wed, 20 Jul 2022 11:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oEBQf-0004Xk-T1 for bug-gnu-emacs@gnu.org; Wed, 20 Jul 2022 11:16: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: Wed, 20 Jul 2022 15:16: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.165833014117430 (code B ref 56637); Wed, 20 Jul 2022 15:16:01 +0000 Original-Received: (at 56637) by debbugs.gnu.org; 20 Jul 2022 15:15:41 +0000 Original-Received: from localhost ([127.0.0.1]:58609 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oEBQK-0004X3-NA for submit@debbugs.gnu.org; Wed, 20 Jul 2022 11:15:41 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:8130) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oEBQG-0004Wn-Rb for 56637@debbugs.gnu.org; Wed, 20 Jul 2022 11:15:39 -0400 Original-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) Original-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== Original-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) In-Reply-To: <83a694m40y.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 20 Jul 2022 14:12:29 +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:237510 Archived-At: >> (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