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:44:23 +0800 Message-ID: <87r12e1vq0.fsf@localhost> References: <874jzdhh5m.fsf@localhost> <837d49ntwg.fsf@gnu.org> <874jzc4e1x.fsf@localhost> <837d48m332.fsf@gnu.org> <87zgh21xbg.fsf@localhost> <831queodmg.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="5936"; 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:52:21 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 1oEVfA-0001Fd-OJ for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 21 Jul 2022 14:52:20 +0200 Original-Received: from localhost ([::1]:42442 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oEVf9-0005IM-QM for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 21 Jul 2022 08:52:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38580) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEVX8-0003Ps-5s for bug-gnu-emacs@gnu.org; Thu, 21 Jul 2022 08:44:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47125) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oEVX7-0007TS-TZ for bug-gnu-emacs@gnu.org; Thu, 21 Jul 2022 08:44:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oEVX7-0001Ks-PI for bug-gnu-emacs@gnu.org; Thu, 21 Jul 2022 08:44:01 -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:44:01 +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.16584074065077 (code B ref 56637); Thu, 21 Jul 2022 12:44:01 +0000 Original-Received: (at 56637) by debbugs.gnu.org; 21 Jul 2022 12:43:26 +0000 Original-Received: from localhost ([127.0.0.1]:36874 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oEVWX-0001Jp-SN for submit@debbugs.gnu.org; Thu, 21 Jul 2022 08:43:26 -0400 Original-Received: from mail-pj1-f41.google.com ([209.85.216.41]:51170) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oEVWW-0001Jb-5B for 56637@debbugs.gnu.org; Thu, 21 Jul 2022 08:43:24 -0400 Original-Received: by mail-pj1-f41.google.com with SMTP id go3so1540287pjb.0 for <56637@debbugs.gnu.org>; Thu, 21 Jul 2022 05:43:24 -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=Tc0re8lxjCe/HmEgFtJKvstoIICpvqtFV6hycQyRk0w=; b=E1jCEqETZqSXuJXh/t+qv55DmvfG4LTAnkshGXP9AbRZ3+B/TBej0BwtZ77tVybGQA Q9MAbWMh4ZnN85bNP/V/9Qc/CENmfjQof8R+UQ6pGFcuiWOxspcnUfNNOpttNZBSYgj5 CvjSPJDjtX3pKJ/nuupOD+RBiOm/dX175XugLclPO5LvlIAhoAyvqoOuM6UaMq7EviZ+ sUr7RSHeb3kAklwqtTKQknx1eBRpnAa+DzbS/atHC6YzROTrDElFq1II584/631SyIKi XUKmk9+ir9EGtNXrFNq502Ectr/r3MM3J1+WCdJJKFwXrzbOleHnAGkSdoaPZEC4mrXh nxFg== 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=Tc0re8lxjCe/HmEgFtJKvstoIICpvqtFV6hycQyRk0w=; b=y0efMX12XB/hSuL7dzYUg+6f8baldla7RbpX2PxU+KrWZVeFpSjCaGRy2TCYKbDAW6 L8gR7w7YwbOj/UIMEAi6NPW1qJRuDqrBzPK+ci+4uX/xznZvHEg0FG3hol4aA+eyKzC3 FyY9nS1iRfGN5OhmF1pbLMe8gCPZ3hVoh3eCWdOl7/UogQ6wORERcHNGZw1SGgZtyd2t KYq9ykDcgki5XCk/auNUV6Z/ksZa1Nb+/sn0nTkoDjNdj4C+3C6LFYgPQSHfFzCC0hPm FRQoNYvDXdC1v7JNAlIHjYtSjOUux5Rnw3DyMNmYJ13RxNHSPiiwcjhxNeKgHftxvxzY 6n7A== X-Gm-Message-State: AJIora8Re8roa2/mvNJKGM1QDmE6hRQ4N5xS+yFAx1qrcBx0K0quqTP3 P8TYmqUcHcZ1VqAESPQRgVreylaB5tZkEg== X-Google-Smtp-Source: AGRyM1u+goEB5nbjr87A1V22/+3WEMrSbldjxivNf7LF2W6q214K9Kjx28NbfANAeILlD2GIj9bMqw== X-Received: by 2002:a17:902:d4c6:b0:16d:2f7f:9a71 with SMTP id o6-20020a170902d4c600b0016d2f7f9a71mr3911198plg.36.1658407398149; Thu, 21 Jul 2022 05:43:18 -0700 (PDT) Original-Received: from localhost ([2409:8a70:2b7:3fb0:8ec6:81ff:fe70:339d]) by smtp.gmail.com with ESMTPSA id a15-20020a170902eccf00b001641b2d61d4sm1635137plh.30.2022.07.21.05.43.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Jul 2022 05:43:17 -0700 (PDT) In-Reply-To: <831queodmg.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:237552 Archived-At: Eli Zaretskii writes: > You said font-lock-fontify-buffer, not font-lock-ensure... Either way. They should both fontify the buffer with font-lock-ensure not skipping any parts guaranteed. In any case, changing font-lock-ensure to font-lock-fontify-buffer will not change failure to fontify using the report steps. >> 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"? 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. > 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. To illustrate, try to create a buffer and run the following: (progn (emacs-lisp-mode) (benchmark-run 100 (erase-buffer) (insert "(+ 1 2)") (font-lock-ensure))) (benchmark-run 100 (erase-buffer) (insert "(+ 1 2)") (emacs-lisp-mode) (font-lock-ensure) (fundamental-mode)) The results are: (5.531764251 0 0.0) (0.012424528 0 0.0) Over 400x difference. Best, Ihor