From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko 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 20:09:55 +0800 Message-ID: <87zgh21xbg.fsf@localhost> References: <874jzdhh5m.fsf@localhost> <837d49ntwg.fsf@gnu.org> <874jzc4e1x.fsf@localhost> <837d48m332.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25532"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56637@debbugs.gnu.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jul 21 14:17:24 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 1oEV7J-0006J7-Q1 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 21 Jul 2022 14:17:21 +0200 Original-Received: from localhost ([::1]:45872 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oEV7G-0007hE-1g for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 21 Jul 2022 08:17:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59704) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEUzG-00048k-Oi for bug-gnu-emacs@gnu.org; Thu, 21 Jul 2022 08:09:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47060) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oEUzG-00019z-Dm for bug-gnu-emacs@gnu.org; Thu, 21 Jul 2022 08:09:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oEUzG-0000L3-2w for bug-gnu-emacs@gnu.org; Thu, 21 Jul 2022 08:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 21 Jul 2022 12:09: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.16584053401294 (code B ref 56637); Thu, 21 Jul 2022 12:09:02 +0000 Original-Received: (at 56637) by debbugs.gnu.org; 21 Jul 2022 12:09:00 +0000 Original-Received: from localhost ([127.0.0.1]:36809 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oEUzE-0000Ko-8D for submit@debbugs.gnu.org; Thu, 21 Jul 2022 08:09:00 -0400 Original-Received: from mail-pl1-f181.google.com ([209.85.214.181]:37464) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oEUzA-0000KZ-Ku for 56637@debbugs.gnu.org; Thu, 21 Jul 2022 08:08:59 -0400 Original-Received: by mail-pl1-f181.google.com with SMTP id f11so1616588plr.4 for <56637@debbugs.gnu.org>; Thu, 21 Jul 2022 05:08:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=dcn3YiliHf7cH4Dghebb0KUyPfQTS0G2tmB7BP8R7Vo=; b=Kww8Z5QaNWXYAFP6JpGQUalPBkKGY/PYivSzc2mp59UL2kNF9Prq5RDxsqYqB/3HiW qvWVu4CPSXy0jjtVEv3RvvBoeTGiRB8hA9od5jCdjFQMd+SdbcCwKqPw6AMETTpEGVGK +CJKmqYp1clvdUdIGRsGPTx6+THJ5gdy0dBuBT8MvgAb6imVTgh0W793K5eEcuhZpjC/ SjInfc2LIIcwL2IwLDG87Paf7D94Pt0YGG3Ag7xcDBztOCo4D50cMk5Lgw8Y4znDfXsV cdpytKzoiqsuVuztNkwa8uei5q0eF5XiAWvcLDzqB1xW+H9QffSF3AcvS/b+sPc/VuC5 29bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=dcn3YiliHf7cH4Dghebb0KUyPfQTS0G2tmB7BP8R7Vo=; b=Lz6KhjVoznJwlM9NINQD1cWb2yE7vXpDk1q3cFreSSbDbw78W0qidZqPOvPqPcbu5Y GoDcqvuHK9hN4eqWcJizXLh7q7THzRj4o7s8J7u/x1gTizyPZDFtOC3awiRgrykq9kVV mPAAerwGPjofzN3OAgpMt1hEqibTkUr/T8Povf88r+mnIJsTvmNyCreacgSNR7TGqge2 v++QNEovsMe+YuzWfJDEOtt4Okj3NfJ+F7kvwlL24vx/NS2r22E/B0pnsuCPZuHTDwtN IEbbSS5TT8p2DJeQN7fS+9bj4nX+1IGDNdhs2g7pm4Hy6E0beGkzJN4yuczz8cXWTzo6 0JeA== X-Gm-Message-State: AJIora9VLaNnUvFiNw0MSsd/gBxfQjI9FfEoXAI63lNzZEMttvgjfhL+ CABAyWMRdVMBiqIJUu9gkuQ= X-Google-Smtp-Source: AGRyM1v5JcP20SCUxglRe6AZiDhPOeh/pFr4cMPAvz6UUcZj3tSd0V80o4L5fk5mOacydjAQf77ujw== X-Received: by 2002:a17:90b:4b82:b0:1f0:196d:4204 with SMTP id lr2-20020a17090b4b8200b001f0196d4204mr11063091pjb.194.1658405330645; Thu, 21 Jul 2022 05:08:50 -0700 (PDT) Original-Received: from localhost ([2409:8a70:2b7:3fb0:8ec6:81ff:fe70:339d]) by smtp.gmail.com with ESMTPSA id z5-20020a1709027e8500b0016bdc31c772sm1493684pla.117.2022.07.21.05.08.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Jul 2022 05:08:50 -0700 (PDT) In-Reply-To: <837d48m332.fsf@gnu.org> 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:237545 Archived-At: Eli Zaretskii writes: >> 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 >> The need to compute fontification is not limited to the described Reddit >> report. Org also needs fontification for export purposes - we copy the >> Emacs code colours into exported documents. With current behaviour of >> font-lock-mode, programmatic fontification may be problematic not only >> when we use "hidden" buffers starting with space, but also in >> non-interactive mode as in recent related bug report >> https://orgmode.org/list/wxaUFiqi8BmIPv8pcYRVHAFa0hTzM35roQxpVVRkgddjRkesPGX1kVBL3G0fr42FonlRq5FNjapV8RiovXV-RGEDehXn-cmIebf4HWBhzIQ=@protonmail.com > > 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. >> As for not using buffers with names starting with a space, we do need >> such buffers as means to fontify foreign major mode blocks inside Org. >> How else do you suggest computing fontification of an arbitrary text in >> arbitrary major-mode (not org-mode) without polluting the buffer list? > > Once again, if the buffer is killed before the user can see it, > there's no problem to use a name which doesn't start with a space. > > But let me turn the table and ask you: how have you been doing this > till now? See the above. Best, Ihor