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: Thu, 13 Aug 2020 16:30:16 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40044"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eliz@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 13 23:31:23 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 1k6Kok-000AKG-ES for ged-emacs-devel@m.gmane-mx.org; Thu, 13 Aug 2020 23:31:22 +0200 Original-Received: from localhost ([::1]:46364 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k6Koj-0006fG-FL for ged-emacs-devel@m.gmane-mx.org; Thu, 13 Aug 2020 17:31:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52608) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k6Knn-0005kv-Mh for emacs-devel@gnu.org; Thu, 13 Aug 2020 17:30:23 -0400 Original-Received: from mta.tntech.edu ([149.149.2.87]:59816) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k6Knl-0004we-IT for emacs-devel@gnu.org; Thu, 13 Aug 2020 17:30:23 -0400 Original-Received: from math.tntech.edu (unknown [149.149.102.6]) by mta.tntech.edu (Postfix) with ESMTPS id 099A53000483; Thu, 13 Aug 2020 16:30:19 -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 1k6Kng-0004Aw-Jo; Thu, 13 Aug 2020 16:30:16 -0500 Original-Received: by norden.math.tntech.edu (Postfix, from userid 742) id 899712572B73; Thu, 13 Aug 2020 16:30:16 -0500 (CDT) In-Reply-To: (message from Stefan Kangas on Thu, 13 Aug 2020 07:51:40 -0700) 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/13 17:30:19 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:253750 Archived-At: > Eli Zaretskii writes: > >> Sorry for not being more clear. I meant deleting >> font-lock-support-mode: it must be declared obsolete first (which >> would require adding the command proposed by Stefan), then, after some >> obsolescence time, we could delete font-lock-support-mode, and then we >> can delete fast-lock and fuzzy-lock. > > Ah, okay. So if I understand correctly we should not pull the trigger > on deleting the libraries fast-lock and fuzzy-lock until we have first > obsoleted and, at a later date, deleted font-lock-support-mode. > > Best regards, > Stefan Kangas I feel like I may be responsible for creating this little mess. I'm not sure if I can help clean it up, but I'll try. Stefan K's original patch was to just delete the old fast-lock and lazy-lock libraries. This didn't delete the font-lock-support-mode variable, but it would have implicitly changed its role. Instead of choosing a "support" mode, the only valid values would have been 'jit-lock-mode or 'nil, the latter for debugging. For all practical purposes, this has actually been the case ever since the old libraries where obsoleted. Currently, setting f-l-s-m to anything other than 'jit-lock or 'nil will only work if you explicitly load one of the old libraries from the obsolete/ directory. When I saw the patch, I decided to butt in, and suggested that this would make the already confusing name "font-lock-support-mode" even more so. (In hindsight, perhaps f-l-acceleration-mode would have been a better, albeit even longer, choice.) I stuck my nose in here because I've recently been figuring out the details of how font-lock works, and this was one of the stumbling blocks. So, I tried to suggest a new variable name, with font-lock-support-mode as an obsolete-variable-alias. Stefan M suggested, I think, replacing f-l-s-m with a minor mode for debugging font-lock. Anything that makes it easier for someone new to figure out how to debug their font-lock code when it fails to work properly would be good. In any case, it is obviously important that setting font-lock-support-mode to 'nil should continue to be supported as a (perhaps obsolete) way of disabling jit-lock without turning off font-lock. Thanks, and sorry if I've been the cause of some confusion. Regards, -Jeff BTW: Does anyone know the origin and/or meaning of the use of '-lock' in font-lock, etc?