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 16:34:43 -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="7728"; 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 23:35:26 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 1k4syU-0001oM-1H for ged-emacs-devel@m.gmane-mx.org; Sun, 09 Aug 2020 23:35:26 +0200 Original-Received: from localhost ([::1]:44030 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k4syS-0000Re-Uk for ged-emacs-devel@m.gmane-mx.org; Sun, 09 Aug 2020 17:35:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55060) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k4sxy-0008OD-Kd for emacs-devel@gnu.org; Sun, 09 Aug 2020 17:34:54 -0400 Original-Received: from mta.tntech.edu ([149.149.2.87]:51311) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k4sxw-0005nk-Ew for emacs-devel@gnu.org; Sun, 09 Aug 2020 17:34:54 -0400 Original-Received: from math.tntech.edu (unknown [149.149.102.6]) by mta.tntech.edu (Postfix) with ESMTPS id 441DF3000063; Sun, 9 Aug 2020 16:34:50 -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 1k4sxn-0003op-Jm; Sun, 09 Aug 2020 16:34:48 -0500 Original-Received: by norden.math.tntech.edu (Postfix, from userid 742) id 8A4852572B73; Sun, 9 Aug 2020 16:34:43 -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 17:34:50 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=ham 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:253566 Archived-At: Alan Mackenzie writes: > This doesn't make sense, I think. font-lock-support-mode is a function, > and if a user has this set to a non-existent function, the correct > response is surely to tell her with an error message, rather than > executing a different function. > > The only reason anybody nowadays would set f-l-s-m to 'fast-lock-mode > would be for debugging. Let's not make that debugging any more > difficult than it already is. Stefan Monnier writes: > IMNSHO, that variable should not be a defcustom any more and we > shouldn't encourage users to touch it. IOW we should mark it obsolete. > > We could OTOH add a new command to enter a form of > `font-lock-debug-mode` which could disable the use of jit-lock (but not > necessarily in exactly the same way as setting `font-lock-support-mode` > would, tho it would probably be the most obvious immediate choice in the > short term). I guess my suggestion was to change f-l-s-m to a boolean flag in order to make debugging *easier*. My own experience, as someone previously unfamiliar with the font-lock code, was that it took me a while to discover that setting f-l-s-m to nil is the way to use font-lock directly, without jit-lock "support". Neither setting the jit-lock-mode variable nor calling (jit-lock-mode nil) does this. The latter will turn off jit-lock, but doesn't tell font-lock to install its default change functions. I was also thinking that treating any non-nil value by using jit-Lock would provide better backward compatibility. I later realized that this is actually a moot point. The only way that setting f-l-s-m to 'fast-lock-mode will currently work is to also (require 'fast-lock), and that is going to crash-and-burn once fast-lock-mode.el is gone. Personally, I like Stefan M's suggestion of creating a new function or variable and marking f-l-s-m as obsolete, but Eli's point that this could be disruptive to people who are currently using f-l-s-m for debugging is also well taken. Anything that makes it clear how to disable Jit Lock while still using Font Lock seem like an improvement to me. Thanks, -Jeff