From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jeff Norden Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Remove obsolete fast-lock and lazy-lock libraries Date: Sun, 09 Aug 2020 14:21:55 -0500 Message-ID: References: <83mu336i18.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="30896"; mail-complaints-to="usenet@ciao.gmane.io" Cc: stefankangas@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 09 21:22:45 2020 Return-path: Envelope-to: ged-emacs-devel@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 1k4qu3-0007s5-UE for ged-emacs-devel@m.gmane-mx.org; Sun, 09 Aug 2020 21:22:43 +0200 Original-Received: from localhost ([::1]:37694 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k4qu3-00025O-0m for ged-emacs-devel@m.gmane-mx.org; Sun, 09 Aug 2020 15:22:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37376) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k4qtP-0001fw-JM for emacs-devel@gnu.org; Sun, 09 Aug 2020 15:22:03 -0400 Original-Received: from mta.tntech.edu ([149.149.2.87]:14133) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k4qtM-0000mV-7F for emacs-devel@gnu.org; Sun, 09 Aug 2020 15:22:03 -0400 Original-Received: from math.tntech.edu (unknown [149.149.102.6]) by mta.tntech.edu (Postfix) with ESMTPS id D72A23000061; Sun, 9 Aug 2020 14:21:57 -0500 (CDT) Original-Received: from norden.tntech.edu ([149.149.102.4] helo=norden.math.tntech.edu) by math.tntech.edu with esmtp (Exim 4.92) (envelope-from ) id 1k4qtH-0003dk-KM; Sun, 09 Aug 2020 14:21:55 -0500 Original-Received: by norden.math.tntech.edu (Postfix, from userid 742) id 8E4C92572B73; Sun, 9 Aug 2020 14:21:55 -0500 (CDT) In-Reply-To: <83mu336i18.fsf@gnu.org> (message from Eli Zaretskii on Sun, 09 Aug 2020 16:54:59 +0300) X-SA-Spam-Score: 0.0 X-SA-Spam-Report: Spam detection software, running on the system "math.tntech.edu", has NOT identified this incoming email as spam. If you have any questions, contact @@CONTACT_ADDRESS@@ pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 T_SPF_HELO_TEMPERROR SPF: test of HELO record failed (temperror) Received-SPF: pass client-ip=149.149.2.87; envelope-from=jnorden@tntech.edu; helo=mta.tntech.edu X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/09 15:21:58 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:253559 Archived-At: > I see no particular reason to rename the variable, just because it > currently has only one user (inside the core). It's not like adding > other users is unimaginable, and renaming is always a certain shock, > however small. > >> It might make sense to also drop the defcustom status of the support-mode >> variable (or its replacement), since jit-lock is the only non-nil option. > > Likewise here: we have many options that have just 2 values, and they > are still defcustom's. I was thinking that a more descriptive name would make it easier for people to figure out what the variable is for. But, your point that changing the name might be disruptive certainly valid. Maybe re-writing the docstring would be a better solution. How about something like: ---------- (defcustom font-lock-support-mode 't "If non-nil, use `jit-lock-mode' to support fast fontification by being choosy about when fontification occurs. If nil, Jit Lock is never used. This may be helpful for debugging. To avoid long delays, only buffers smaller than `font-lock-maximum-size' will be fontified. If a list, each element should be of the form (MAJOR-MODE . VALUE), where MAJOR-MODE is a symbol or t (meaning the default). For example: ((c-mode . nil) (t . t)) means that Jit Lock is used by default, but C mode buffers will be fontified without support. The value of this variable is used when Font Lock mode is turned on. Historically, this variable was used to choose between several possible methods of accelerated fontification. As of nn.n, Jit Lock is the only method that is supported." ---------- I do think a default value of t is a better choice than 'jit-lock-mode, since it doesn't give the impression that there are other possible values. Whether it should still be defcustom is something that you are in a better position to judge than I am. My thought was that it would now be mainly for debugging. Turning it off will cause large buffers to be un-fontified and/or might result in long delays. Also, I think there was a typo in Stefan's patch where it says + ((c-mode . nil) (t . jit-lock-mode)) +means that no font locking is used for buffers in C If I'm understanding correctly, c-mode will still have font locking, but without jit lock. Thanks, -Jeff