Re: Always-true predicate?

[Eli Zaretskii <eliz@gnu.org>]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Fri, 19 Feb 2021 09:52:55 +0100
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 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".