RE: `set-variable' should use :set

[Drew Adams]

>  > However, I disagree that [set-variable] is not that much more
>  > convenient than setq.  For one thing, it respects the defcustom
>  > :type spec.  For another, it uses a proper interactive spec.  The
>  > type-checking in particular is a win, IMO.
> 
> I don't find either of those noticable.

1. Type-checking is noticeable in that you cannot enter a value whose type
conflicts with the defcustom type.  With `setq' you can.  (The type mismatch
error message should be more helpful, however, instead of just saying "Value
`VAL' does not match type choice of OPTION".)

But I'm not trying to convince anyone to use `set-variable'.
It's fine if you don't find it useful.


2. The interactive reading of a value by `set-variable' depends on the variable
having a `variable-interactive' property.  I use that property in my own code,
but vanilla Emacs does not anymore.  (There are exactly 3 variables left in all
of the vanilla Lisp sources that have this property: `tags-file-name',
`sgml-transformation-function', and `skeleton-transformation-function'.)  So I'm
not surprised that you don't find it noticeable. ;-)

Try, for instance, `M-x set-variable tags-file-name' and compare the behavior
with that of `M-x set-variable custom-file'.  The former gives you file-name
completion.  The latter gives you nada.  That's a noticeable difference.

So yes, I would also BTW suggest that we use property `variable-interactive'
more.  Or better yet make Customize automatically DTRT, at least in the simple
cases (e.g. automatically set that property, or provide the behavior in some
other way), so that `set-variable' is helpful with the values of most user
options (not just 3!).

Even many defcustom `choice' types could be made accessible using completion.
Obviously `const' choices could, and even a type like `function' could, allowing
completion against known function names.  (The completion would be non-strict,
letting you enter a lambda form etc.)  `set-variable' could at least be made to
offer the degree of interactive help (e.g. completion) that is provided for
value-editing in Customize.

I never understood why this feature was abandoned.  The doc (`(elisp) Defining
Variables') says:

"If a user option variable has a `variable-interactive' property, the
`set-variable' command uses that value to control reading the new value
for the variable.  The property's value is used as if it were specified
in `interactive' (*note Using Interactive::).  However, this feature is
largely obsoleted by `defcustom' (*note Customization::)."

That last part is a bit presumptuous, IMHO.  Perhaps it means to say only that
`set-variable' is largely obsolete (although I don't see why it would be - it is
quick; Customize is not).  ("Obsolete" is not a verb BTW (e.g. "obsoleted"),
although it is true that you can verb any noun.)

But it seems to also be suggesting that Customize replaces `set-variable's
reading of a value according to an `interactive' spec, which it does not.

Customize sometimes lets you use completion when editing an option value,
granted.  But if you have to enter the jungle of Customize and survive to come
out the other side in order to get the benefit of an `interactive' spec (editing
the value) then I'd say that some of that benefit has been lost.  Just an
opinion.  One person's loss is another person's obsolete. ;-)

(Tomorrow morning some earnest soul will no doubt remove those 3 vestigial
`variable-interactive' properties in a cleanup sweep to purge the code once and
for all...)

>  > (FWIW, I use it often.)
> 
> I'm curious, what are your use cases?

As I said before, more or less the same use cases as using Customize to set a
value (without saving it):

 `M-x customize-option'
 Edit value or choose value using menu.
 Click `Set for this session'.
 `q'

When might one use Customize instead of setq?  I do it when I want to test
things that involve various option menu values, or when the option value is
somewhat complex.  Sometimes I'll keep a particular Customize buffer open in a
separate frame and make various value changes while testing things.

And setting a value using Customize instead of setq can help when I don't recall
the exact structure of the value (the custom :type).

`set-variable' is quicker for this than Customize.  It offers some of what
Customize offers but is as quick as setq.  However, it helps with the value
reading only if propery `variable-interactive' is set.  And again, it would help
more with the type if the mismatch error were more informative.

Let me be clear: by "often" I don't mean that I use `set-variable' every 3
minutes.  But I do use it fairly often instead of entering Customize or using
setq.

I also use other, non-vanilla commands to increment a numerical option, toggle
any binary option (not just custom-type `boolean'), and so on.

I use this kind of thing more than some people perhaps because I use Emacs to
develop and test Emacs-Lisp code more than I use Emacs for other things.  (The
only thing Emacs is good for is Emacs...but that's a lot.)

Also, I don't necessarily treat user options as things to be set once in a blue
moon and persist.  I don't mind commands that change option values, even
incrementally/dynamically.  Even if an option were never persisted its typing
would still be a useful feature.  I take advantage of both the typing and the
persistence of Emacs options without always treating them as statically as
others do.

I even proposed that Emacs allow for (i.e., optionally) typing non-option vars.
That suggestion was summarily dismissed by you - the sole responder, with the
single word "YAGNI".
http://lists.gnu.org/archive/html/emacs-devel/2009-10/msg00668.html

We have different views of Emacs and its features.  That's OK.  YAGNI.  But IUI.