From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Always-true predicate? Date: Fri, 19 Feb 2021 11:10:37 +0200 Message-ID: <83zh002zjm.fsf@gnu.org> References: <875z2qoqc6.fsf@gnus.org> <87eehcsal4.fsf@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34775"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, rms@gnu.org, emacs-devel@gnu.org To: Robert Pluim Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 19 10:11:13 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 1lD1of-0008yO-9h for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Feb 2021 10:11:13 +0100 Original-Received: from localhost ([::1]:60680 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lD1oe-0005Ys-9R for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Feb 2021 04:11:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36244) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lD1o0-00053M-Jw for emacs-devel@gnu.org; Fri, 19 Feb 2021 04:10:32 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59064) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lD1nz-0000gN-V0; Fri, 19 Feb 2021 04:10:31 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1545 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lD1ns-0004JH-04; Fri, 19 Feb 2021 04:10:24 -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:265217 Archived-At: > From: Robert Pluim > Date: Fri, 19 Feb 2021 09:52:55 +0100 > Cc: Lars Ingebrigtsen , emacs-devel@gnu.org > > Richard> Is there real use for it? Is it useful often enough that > Richard> (lambda (&rest ignore) t) won't suffice? > > Sometimes you just want to return t, and writing out the lambda is > verbose and tedious. Why would you need to express t as a function, though? why not just the value t? I must diverge somewhat here, and express my uneasiness, to say the least, with the recent-ish fashion of making too many user options have function values. It makes "M-x set-variable" much less convenient than it should be, and it makes customizing such options harder for users who aren't proficient in Lisp. We should limit such option values to the absolute minimum, IMO. I'd very much prefer to have simple atomic values (symbols, numbers, or strings) that are then interpreted by the relevant commands to run the necessary code or call out to necessary subroutines to do the job. I feel that some of us think that putting functions with the necessary code directly in the option's value is somehow "cleaner" or "more elegant". I disagree. I think that the urge to have the always-true predicate comes from this tendency. Lars wrote it soon after introducing an option whose values _had_ to be functions, so he needed a function that would always return t. I say such design of user options is itself a problem, and if avoided, the need for an always-true function will not arise, at least not frequently enough to have a canonical solution. Originally, 'ignore' was used only internally, and for semi-kludgey solutions that would otherwise require much more coding. They recently spread out too much, IMO, which is also a sign of some trouble. Let's not let this genie too much space, and minimize the reasons for asking for such "functions".