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:12:29 +0300 Message-ID: <83a694m40y.fsf@gnu.org> References: <874jzdhh5m.fsf@localhost> <83mtd5m54h.fsf@gnu.org> <83ilntlydv.fsf@gnu.org> <83cze0nbk2.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7564"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56637@debbugs.gnu.org, yantar92@gmail.com To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jul 20 13: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 1oE7df-0001iu-1z for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 20 Jul 2022 13:13:11 +0200 Original-Received: from localhost ([::1]:50758 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oE7dd-0001WJ-KL for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 20 Jul 2022 07:13:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57376) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oE7dX-0001WB-3G for bug-gnu-emacs@gnu.org; Wed, 20 Jul 2022 07:13:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58214) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oE7dW-0007Zq-Qk for bug-gnu-emacs@gnu.org; Wed, 20 Jul 2022 07:13:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oE7dW-0001N5-Jw for bug-gnu-emacs@gnu.org; Wed, 20 Jul 2022 07:13:02 -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:13:02 +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.16583155675248 (code B ref 56637); Wed, 20 Jul 2022 11:13:02 +0000 Original-Received: (at 56637) by debbugs.gnu.org; 20 Jul 2022 11:12:47 +0000 Original-Received: from localhost ([127.0.0.1]:55973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oE7dG-0001Ma-SY for submit@debbugs.gnu.org; Wed, 20 Jul 2022 07:12:47 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:44408) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oE7dF-0001MM-CV for 56637@debbugs.gnu.org; Wed, 20 Jul 2022 07:12:46 -0400 Original-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 ) 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==; Original-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 ) id 1oE7d9-00071L-Fq; Wed, 20 Jul 2022 07:12:39 -0400 In-Reply-To: (message from Stefan Monnier on Tue, 19 Jul 2022 17:12:44 -0400) 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:237488 Archived-At: > From: Stefan Monnier > Cc: yantar92@gmail.com, 56637@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.