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 17:25:09 +0000 Message-ID: <20200810172509.GB4294@ACM> References: <20200810110458.GA4294@ACM> 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="23705"; 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 20:22:58 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 1k5CRm-00063F-Fq for ged-emacs-devel@m.gmane-mx.org; Mon, 10 Aug 2020 20:22:58 +0200 Original-Received: from localhost ([::1]:38302 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k5CRl-00044G-IZ for ged-emacs-devel@m.gmane-mx.org; Mon, 10 Aug 2020 14:22:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49532) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k5BXw-0003MS-IQ for emacs-devel@gnu.org; Mon, 10 Aug 2020 13:25:16 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:47880 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1k5BXu-0004j1-5D for emacs-devel@gnu.org; Mon, 10 Aug 2020 13:25:16 -0400 Original-Received: (qmail 67922 invoked by uid 3782); 10 Aug 2020 17:25:10 -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 19:25:09 +0200 Original-Received: (qmail 21656 invoked by uid 1000); 10 Aug 2020 17:25:09 -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 13:25:10 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:253601 Archived-At: Hello, Stefan. On Mon, Aug 10, 2020 at 08:07:31 -0400, Stefan Monnier wrote: > >> 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. > That's why I propose to replace it with `font-lock-debug-mode`, which > would both help discoverability and make it easier to use as well. What you have done here is to take my words out of context, twist them, and pretend to be agreeing with me. Why do you do things like this? Why can you not have an open honest discussion with me on things we disagree about? The necessary context you snipped, from my previous post, is this: > > 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? So the question remains: why do you want to make these more advanced forms of debugging more difficult? Your "... help both discoverability and make it easier to use ..." could be summed up as dumming down. Surely it would be possible to leave font-lock-support-mode with its current power, while adding on these other things, too? > Stefan -- Alan Mackenzie (Nuremberg, Germany).