Re: Always-true predicate?

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 19 Feb 2021 06:52:57 -0600
> Cc: larsi@gnus.org, rms@gnu.org, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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.
> 
> Could you elaborate on how it makes it harder to customize?

Isn't it clear that typing a function at set-variable's prompt is much
less convenient than typing an atom, like a symbol, a string, or a
number?  For starters, it is much more typing.  And then it's easy to
make a mistake, which will require you to start over again.

> Doesn't `customize-option' hide that away?

I was talking about set-variable, not about customize-option.

But even with customize-option things are much less convenient when
using function values.  You say "hide", and mean the values that are
already in the :choice list.  But what about values that aren't?
Customization is about _changing_ the defaults, not about leaving them
unchanged.  Typing a function's name, let alone a lambda-expression,
in the Custom form is no fun.  So having a user option whose value
_must_ be a function is a PITA.

And then we have this annoyance from "C-h v" as well:

  read-extended-command-predicate is a variable defined in ‘simple.el’.
  Its value is
  #f(compiled-function
  (s b)
  #<bytecode 0x5a5068802147c83>)

That's not very useful display for a user option.

> BTW, should perhaps `set-variable' support completing on the forms in
> :type somehow?

It already does, sort-of.  Try typing a value that doesn't fit :type,
and you'll see that in action.