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: Tue, 11 Aug 2020 02:00:26 -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="28001"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, eliz@gnu.org, emacs-devel@gnu.org, monnier@iro.umontreal.ca, stefankangas@gmail.com To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 11 09:01:34 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 1k5OHu-00076f-8z for ged-emacs-devel@m.gmane-mx.org; Tue, 11 Aug 2020 09:01:34 +0200 Original-Received: from localhost ([::1]:59718 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k5OHt-00020Y-9E for ged-emacs-devel@m.gmane-mx.org; Tue, 11 Aug 2020 03:01:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50930) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k5OGv-0001Xw-Dm for emacs-devel@gnu.org; Tue, 11 Aug 2020 03:00:33 -0400 Original-Received: from mta.tntech.edu ([149.149.2.87]:10507) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k5OGt-00089K-7p for emacs-devel@gnu.org; Tue, 11 Aug 2020 03:00:32 -0400 Original-Received: from math.tntech.edu (unknown [149.149.102.6]) by mta.tntech.edu (Postfix) with ESMTPS id 10CBC3000D9D; Tue, 11 Aug 2020 02:00:29 -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 1k5OGo-0006t8-GO; Tue, 11 Aug 2020 02:00:26 -0500 Original-Received: by norden.math.tntech.edu (Postfix, from userid 742) id 6F1152572B73; Tue, 11 Aug 2020 02:00:26 -0500 (CDT) In-Reply-To: (message from Richard Stallman on Mon, 10 Aug 2020 23:26:36 -0400) 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/11 03:00:29 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:253620 Archived-At: > > > 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. > > That puts a harsh face on a statement which has other interpretations. > For instance, one can interpret it as contending that supporting > setting of that variable by users would require a lot of work and the > benefit would not justify all that work. I agree. From my point of view, it seems like the intent of the proposal was mis-interpreted. I saw the intent as making it *easier* to do exactly what was interpreted as being 'deliberately restricted', by providing a better method which would be simpler, less confusing, and perhaps more effective. Another statement that was recently made by Eli in regards to this was: > OK, but why does that mean we should demote it from being a defcustom? > People who need to debug font-lock are also users, and being unable to > change the value through "M-x set-variable" is an annoyance, at least > for me. While I think it would actually wind up not being an annoyance, the statement that 'People who need to debug font-lock are also users' is something that I wholeheartedly agree with! In fact, I've personally decided to avoid, as much as possible, the use of the term 'user' as a pronoun. People have usernames (and user-passwords) for logging in. The term user-interface is helpful, since interface can refer to many things. But the person at the keyboard and in front of the screen is just that - a person. Of course, there is nothing inherently wrong with the term 'user'. But, in many circles (present company excepted) it seems that 'user' is used to implicitly refer to a subset, often a narrow subset, of the people who might use software (or anything else). I think that using 'person' and 'people' instead of 'user' and 'users' does a better job of indicating the diversity of folks who might use something. This diversity should be given at least some consideration (sometimes a lot), rather than being shoved under the rug. Emacs, in particular, does a better job serving a diverse audience than any other software that I know of. Just my 2c, for whatever it might be worth. Regards, -Jeff