From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Remove obsolete fast-lock and lazy-lock libraries Date: Mon, 10 Aug 2020 11:04:58 +0000 Message-ID: <20200810110458.GA4294@ACM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21516"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , stefankangas@gmail.com, Jeff Norden , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 10 13:06:00 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 1k55cu-0005Sl-1h for ged-emacs-devel@m.gmane-mx.org; Mon, 10 Aug 2020 13:06:00 +0200 Original-Received: from localhost ([::1]:37804 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k55ct-0008Ry-2u for ged-emacs-devel@m.gmane-mx.org; Mon, 10 Aug 2020 07:05:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37582) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k55c0-0007Os-QL for emacs-devel@gnu.org; Mon, 10 Aug 2020 07:05:04 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:31180 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1k55by-0006dX-H3 for emacs-devel@gnu.org; Mon, 10 Aug 2020 07:05:04 -0400 Original-Received: (qmail 54421 invoked by uid 3782); 10 Aug 2020 11:04:59 -0000 Original-Received: from acm.muc.de (p4fe15cfe.dip0.t-ipconnect.de [79.225.92.254]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Mon, 10 Aug 2020 13:04:58 +0200 Original-Received: (qmail 4308 invoked by uid 1000); 10 Aug 2020 11:04:58 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/10 07:05:00 X-ACL-Warn: Detected OS = FreeBSD 9.x or 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:253580 Archived-At: Hello, Stefan. On Sun, Aug 09, 2020 at 15:53:21 -0400, Stefan Monnier wrote: > > I was thinking that a more descriptive name would make it easier for > > people to figure out what the variable is for. > IMNSHO, that variable [font-lock-support-mode] should not be a > defcustom any more and we shouldn't encourage users to touch it. IOW > we should mark it obsolete. In other words, deliberately restrict what users can do with Emacs. This is surely not a great idea. At the moment, sensible normal values are nil and jit-lock-mode. Also sensible would be, for example, jit-lock-debug-mode, when a user wants to compare standard jit with her own enhanced version. It is not inconceivable that somebody might write something entirely new to supersede jit-lock. Why do you want to make these things more difficult to do? > 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). font-lock-support-mode is _NOT_ obsolete. It is useful for debugging. Maybe it needn't be a defcustom any more. But all the suggestions for altering it that I've read seem aimed at making Emacs less capable. Lets leave font-lock-support-mode alone. > Stefan -- Alan Mackenzie (Nuremberg, Germany).