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 21:18:34 +0800 Message-ID: <87o7xi1u51.fsf@localhost> References: <874jzdhh5m.fsf@localhost> <837d49ntwg.fsf@gnu.org> <874jzc4e1x.fsf@localhost> <837d48m332.fsf@gnu.org> <87zgh21xbg.fsf@localhost> <831queodmg.fsf@gnu.org> <87r12e1vq0.fsf@localhost> <83tu7amxzx.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="27807"; 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 15:18: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 1oEW4Y-0006yh-Ps for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 21 Jul 2022 15:18:34 +0200 Original-Received: from localhost ([::1]:46714 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oEW4X-00033W-No for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 21 Jul 2022 09:18:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46486) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEW42-00031y-VG for bug-gnu-emacs@gnu.org; Thu, 21 Jul 2022 09:18:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47160) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oEW42-0005Ze-Ly for bug-gnu-emacs@gnu.org; Thu, 21 Jul 2022 09:18:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oEW42-0002HV-9S for bug-gnu-emacs@gnu.org; Thu, 21 Jul 2022 09:18: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 13:18: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.16584094578733 (code B ref 56637); Thu, 21 Jul 2022 13:18:02 +0000 Original-Received: (at 56637) by debbugs.gnu.org; 21 Jul 2022 13:17:37 +0000 Original-Received: from localhost ([127.0.0.1]:36909 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oEW3d-0002Gn-D3 for submit@debbugs.gnu.org; Thu, 21 Jul 2022 09:17:37 -0400 Original-Received: from mail-pf1-f172.google.com ([209.85.210.172]:36693) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oEW3a-0002GV-Mr for 56637@debbugs.gnu.org; Thu, 21 Jul 2022 09:17:36 -0400 Original-Received: by mail-pf1-f172.google.com with SMTP id g12so1744031pfb.3 for <56637@debbugs.gnu.org>; Thu, 21 Jul 2022 06:17:34 -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=qPP1g4N9D359p6Q53jIZMIL1v2FVZo7koUnIqKQu9fU=; b=kLyMHUM/YpAn4zbKOs8qw7teApoc20mFCNBV/qABWASFxxrzg95ZKCBkfxN3nNgy4g /p0/2MCAJJJQhcdu4KBugJUbQNMxE/nb5vyOry48n2kjXvgNfiYaxd3zPxVi5lLjeZ+W /XdH5SMY/nSXl4u7U0XCDfUnH12HYQCxebCqx8u6mPyYKTIRpt9kfzsfuWoM9NtDLLoQ fK86UaiyUgx0XfBJPr0wZcEXzoxc9k9Qas6HOX7wO/OWqHhguywq+ye/1AfRMD0JZ5Jl LU5Pw2Ji9ssD2pRpOCIohD62WVYbxO73FIKoIvpwm/kPBHUrljDRtzWMKhagcOxFbfaK CWXQ== 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=qPP1g4N9D359p6Q53jIZMIL1v2FVZo7koUnIqKQu9fU=; b=g3O3u4Cbq7REsVApDrSbyfZNUh12i+f2UeUYYRbqPsrtKxyKUEBWTU8fbaQmQy7sUL Ce9/6/thr0KyQKviDWOg6sK+JnLaktI2MC1NcETfMR9jiiwfKe26uI2tCSkyfo3RHHXr SLxZ0bkkR/qKMYuGY5xWMZtNr4CJuTlvA7No/i4rfvg6NPU/SB82lNC74AOu20zH+Esa 0h49J3+xifIrNP2OybnkYMI7S8T6mjt24MSHlf05GgipqacsJmkgupdGsCmOY3rr2/ky BmVNi88K+ol0+WuGkrQsgQstWxQwxZNdN0IwSTgt6GD2mThjNUWm13q7uwJVgf7E4dd+ LV5w== X-Gm-Message-State: AJIora876aeI95y4YYFbWeynlESVcOcGUuO58kxpQ5bjX2nCNJEvrQ/C xWf8Er9Ekfpn3Hwmuz7P3aQ= X-Google-Smtp-Source: AGRyM1u9+qVnhyCUxLBs1TarJ/BHwi/1Rn5qznlplYOpQ8uGAE27Ai8udhuSxUS4iIcS6UXpIc4VKg== X-Received: by 2002:a63:1213:0:b0:41a:8d6b:3e80 with SMTP id h19-20020a631213000000b0041a8d6b3e80mr1036714pgl.388.1658409448787; Thu, 21 Jul 2022 06:17:28 -0700 (PDT) Original-Received: from localhost ([2409:8a70:2b7:3fb0:8ec6:81ff:fe70:339d]) by smtp.gmail.com with ESMTPSA id ft7-20020a17090b0f8700b001efeb4c813csm1404981pjb.13.2022.07.21.06.17.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Jul 2022 06:17:28 -0700 (PDT) In-Reply-To: <83tu7amxzx.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:237554 Archived-At: Eli Zaretskii writes: >> If fontification is done in temporary throwaway buffers that are closed >> immediately after fontification, next portion of text that should be >> fontified in the same major mode will need to create a new throwaway >> buffer, turn on the relevant major mode, and perform fontification. >> Hence, major mode will need to be loaded every single time we need to >> fontify a text fragment. > > It is not "loaded", it is "activated". "Loading" in Emacs means > loading the Lisp package that implements the mode, and that is done > only once. We don't unload packages when buffers are killed. Thanks for the clarification. >> > 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. >> >> It is usually true from my experience. > > Well, "usually" is not a guarantee it will always be so. We do not need such a guarantee. The choice between temporary throwaway buffers and single major-mode buffer where we insert/remove text is about speed. Even if reusing the buffer is faster in 90% of major modes and not 100%, it is a big improvement. > Anyway, if this is the issue, we could add another way of marking a > buffer as "invisible for user", one that is not based on the buffer's > name. > >> (5.531764251 0 0.0) >> (0.012424528 0 0.0) >> >> Over 400x difference. > > Sorry, but this proves nothing, and I'm sure you know it. It was an _illustration_. The decision to reuse buffer was not arbitrary. Org mode developers and users tested the throwaway buffer approach, found it too slow and changed to reusing a single major-mode buffer. The latter is faster in practice. > To me, this is just one more fragile assumption on which Org code is > based that is bound to be broken some day. It is a heuristic. If it is broken, nothing terrible will happen. Fontification will still work, albeit slower. If the slowdown will be reported widely, we can always change to the alternative approach. Also, I am not sure why you are making such a strong claim about "that is bound to be broken some day". Throwaway buffer will require (1) creating buffer; (2) activating major-mode; (3) fontification. Reusable buffer will require (1) Handling major mode's before/after-change-functions; (2) fontification. Before/after-change-functions are fast. If not, the relevant major mode is a terrible mode anyway and should not be used. There is no such pressure to optimize the activation time, in comparison. Best, Ihor