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: Tue, 19 Jul 2022 22:32:13 +0300 Message-ID: <83cze0nbk2.fsf@gnu.org> References: <874jzdhh5m.fsf@localhost> <83mtd5m54h.fsf@gnu.org> <83ilntlydv.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32242"; 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 Tue Jul 19 21:35:35 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 1oDt0I-00089b-RI for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 19 Jul 2022 21:35:34 +0200 Original-Received: from localhost ([::1]:44970 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oDt0H-0002Iy-Oq for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 19 Jul 2022 15:35:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34466) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oDsxq-0007dD-Oz for bug-gnu-emacs@gnu.org; Tue, 19 Jul 2022 15:33:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57443) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oDsxq-0007cm-GB for bug-gnu-emacs@gnu.org; Tue, 19 Jul 2022 15:33:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oDsxq-0008DR-C7 for bug-gnu-emacs@gnu.org; Tue, 19 Jul 2022 15:33: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: Tue, 19 Jul 2022 19:33: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.165825915731538 (code B ref 56637); Tue, 19 Jul 2022 19:33:02 +0000 Original-Received: (at 56637) by debbugs.gnu.org; 19 Jul 2022 19:32:37 +0000 Original-Received: from localhost ([127.0.0.1]:55201 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oDsxR-0008Cb-1D for submit@debbugs.gnu.org; Tue, 19 Jul 2022 15:32:37 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:49662) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oDsxP-0008CQ-U1 for 56637@debbugs.gnu.org; Tue, 19 Jul 2022 15:32:36 -0400 Original-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 ) 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==; Original-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 ) id 1oDsxH-0003Tn-RS; Tue, 19 Jul 2022 15:32:29 -0400 In-Reply-To: (message from Stefan Monnier on Tue, 19 Jul 2022 15:21:22 -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:237465 Archived-At: > From: Stefan Monnier > Cc: yantar92@gmail.com, 56637@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!