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: Thu, 21 Jul 2022 15:26:47 +0300 Message-ID: <831queodmg.fsf@gnu.org> References: <874jzdhh5m.fsf@localhost> <837d49ntwg.fsf@gnu.org> <874jzc4e1x.fsf@localhost> <837d48m332.fsf@gnu.org> <87zgh21xbg.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="870"; 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 Thu Jul 21 14:28:20 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 1oEVHv-00004y-ET for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 21 Jul 2022 14:28:19 +0200 Original-Received: from localhost ([::1]:59740 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oEVHu-0001Mr-2C for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 21 Jul 2022 08:28:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35338) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEVHe-0001KI-JE for bug-gnu-emacs@gnu.org; Thu, 21 Jul 2022 08:28:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47094) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oEVHe-0004eo-AE for bug-gnu-emacs@gnu.org; Thu, 21 Jul 2022 08:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oEVHe-0000sE-3z for bug-gnu-emacs@gnu.org; Thu, 21 Jul 2022 08:28: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: Thu, 21 Jul 2022 12:28: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.16584064223275 (code B ref 56637); Thu, 21 Jul 2022 12:28:02 +0000 Original-Received: (at 56637) by debbugs.gnu.org; 21 Jul 2022 12:27:02 +0000 Original-Received: from localhost ([127.0.0.1]:36843 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oEVGg-0000qb-3J for submit@debbugs.gnu.org; Thu, 21 Jul 2022 08:27:02 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:50486) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oEVGd-0000qE-2I for 56637@debbugs.gnu.org; Thu, 21 Jul 2022 08:27:00 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51034) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEVGX-0004UX-RN; Thu, 21 Jul 2022 08:26:53 -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=gY3nYdLka9C9oUtAZ4Jh3j5iqf6IxF3bDRd5hyBo17E=; b=AQXXkYLrsGPu zwYpoDEze0ZBZ21wwTYxOXHT7VzPG2x4hkFimf8e0TSDSGlCBtIUS5fqQgxugcITCl/JKkTUIpFoe kDfEQEegU1sqaSZT3zDZR821+714oLeZ3+t1dd7WxRKhCZWEHEEToZ61mL5+g31Hr6Vsl+KCDQyfw QoPiW+o5iKdw4ibguDjY564hZ4b6sI6bcBeYxDhhDU6DhJoCKioPks0fE2kAC75s3RkQi56fh1YYi WPJdYMZYM2YrqTAVO7WQiHHsDXYyRF9XUhhxSp9F0a7iq9t7AozRvPWpCmZ64uPTOPjz+/bjj1Alr X8HPRCh6cLXym64sqSIONg==; Original-Received: from [87.69.77.57] (port=2513 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 1oEVGX-0002Pz-4J; Thu, 21 Jul 2022 08:26:53 -0400 In-Reply-To: <87zgh21xbg.fsf@localhost> (message from Ihor Radchenko on Thu, 21 Jul 2022 20:09:55 +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:237548 Archived-At: > From: Ihor Radchenko > Cc: monnier@iro.umontreal.ca, 56637@debbugs.gnu.org > Date: Thu, 21 Jul 2022 20:09:55 +0800 > > >> 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. > > Create a file called bug.el with the following text: > > (with-current-buffer (get-buffer-create "Test") > (emacs-lisp-mode) > (insert "(message \"Foo\")") > (font-lock-ensure) > (message "%S" (buffer-string))) > > Then, run > emacs-29-vcs -Q --script /tmp/bug.el > > Observed output: #("(message \"Foo\")" 9 14 (face font-lock-string-face)) > Expected: #("(message \"Foo\")" 0 9 (fontified t) 9 14 (face font-lock-string-face fontified t) 14 15 (fontified t)) > > The expected output appears in *Messages* when you run > emacs-29-vcs -Q -l /tmp/bug.el You said font-lock-fontify-buffer, not font-lock-ensure... Anyway, I hope Stefan will look into this. > > 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. > > Killing the buffer where we do fontification is too slow for Org. > If Org were to use temporary buffers, it would need to load major mode > for every text fragment to be fontified. Loading major modes (at least > some major modes) is taking significant amount of time and should > better be avoided if we can simply reuse a single buffer with major mode > that is already loaded. Sorry, I don't understand: once Emacs loads a major mode, it stays loaded, unless you forcibly unload it. Or what do you mean by "load major mode"? And why do you assume that erasing a buffer and then inserting some text into it will be significantly faster than turning on a mode in it? It sounds like another fragile assumption.