From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Always-true predicate? Date: Sun, 21 Feb 2021 01:12:04 -0500 Message-ID: References: <875z2qoqc6.fsf@gnus.org> <87eehcsal4.fsf@gmail.com> Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3054"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, emacs-devel@gnu.org To: Robert Pluim Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Feb 21 07:13:31 2021 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 1lDhzn-0000hu-9X for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Feb 2021 07:13:31 +0100 Original-Received: from localhost ([::1]:57382 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lDhzm-0001xz-Au for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Feb 2021 01:13:30 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43404) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lDhyQ-0001L1-Mq for emacs-devel@gnu.org; Sun, 21 Feb 2021 01:12:06 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58039) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lDhyQ-0001OX-EX; Sun, 21 Feb 2021 01:12:06 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1lDhyO-0004ER-4C; Sun, 21 Feb 2021 01:12:04 -0500 In-Reply-To: <87eehcsal4.fsf@gmail.com> (message from Robert Pluim on Fri, 19 Feb 2021 09:52:55 +0100) 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:265365 Archived-At: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] You asked what's wrong with > #'pretend-to-pay-attention? That is the wrong question, the wrong way to think about a proposed feature. It presupposes a policy of adding every possible feature, unless there is "something wrong with it". That leads to more and more bloat. Every feature, even a trivial one, implies more complexity -- not just in code, which is the least burdensome, but in documentation, and in what users need to know. The size of the Emacs Lisp Reference Manual is a problem we can measure. To keep bloat in check, we must insist that any new feature be justified by benefit. I am sure there will be occasions to use this proposed function. Will they be frequent enough to make it worth while? My judgment says they won't be. It is possible to make an estimate based on more knowledge. The files lisp/c*.el add up to around 20,000 lines. Since they are unrelated in purpose and history, they would make a good sample. How about looking through those files for places where using always-return-t would make the code cleaner? If you find quite a few in that sample, that would start to support adding this feature. However, there would also be the question of _how much_ cleaner the code would be in each place. In regard to user options whose values are functions, I think it is good to allow nil and t as values. That would be cleaner than setting the option to `ignore' or always-return-t. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)