Question about set-variable in .emacs

Question about set-variable in .emacs

[Drew Adams]

I just had a user who put (setq foo t) in his .emacs. Option foo is defined
with a defcustom that limits its possible values to a :choice that does not
include t.

I wonder what we recommend people to put in their .emacs in such
situations - that is, people who choose not to use Customize (at least for
that option).

setq obviously won't respect the variable-interactive or defcustom typing.
Should we recommend that people code (custom-set-variables ...) by hand? (I
would expect not.)

Should we recommend that they use (set-variable ...)? My guess is that it
might generally be better for people to use (set-variable ...) in .emacs
than (setq ...).

Is there already a recommendation for this? If not, WDOT?

Re: Question about set-variable in .emacs

[Luc Teirlinck]

Drew Adams wrote:

   I just had a user who put (setq foo t) in his .emacs. Option foo is defined
   with a defcustom that limits its possible values to a :choice that does not
   include t.

   I wonder what we recommend people to put in their .emacs in such
   situations - that is, people who choose not to use Customize (at least for
   that option).

If t is an illegal value for foo, then the obvious recommendation
would be that the user would not set foo to an illegal value.  The
fact that the user does not get warned would not seem that much of a
problem, since people who do not use Custom presumably do not _want_
this type of hand holding.

If t is a legal value and the problem is that Custom claims it is not,
then there is a bug in the defcustom.

Sincerely,

Luc.

RE: Question about set-variable in .emacs

[Drew Adams]

       I just had a user who put (setq foo t) in his .emacs. Option
       foo is defined with a defcustom that limits its possible values to a
       :choice that does not include t.

       I wonder what we recommend people to put in their .emacs in such
       situations - that is, people who choose not to use Customize
       (at least for that option).

    If t is an illegal value for foo,

I stated that it was: ":choice that does not include t".

    then the obvious recommendation would be that the user would not
    set foo to an illegal value. The fact that the user does not get
    warned would not seem that much of a problem, since people who do
    not use Custom presumably do not _want_ this type of hand holding.

1) I wouldn't call what I was asking for hand-holding.

2) I don't agree that people who choose an incorrect value (as defined by
Custom) via (setq foo bad-value) in their .emacs are necessarily resisting
hand-holding.

Proof: In the case in question, the person simply made a mistake. Many
people still use .emacs for everything, bypassing Custom. They don't all do
this always out of conscious preference; some do it sometimes out of habit
or ignorance. In this case, the user had the habit of not using Custom and
made a mistake wrt the option value. This happens sometimes.

Of course we can recommend that people use Custom to avoid this kind of
problem (and for other reasons). That is how I responded to this user, for
instance.

My point is that perhaps we could also recommend that _if_ you choose not to
use Custom _then_ it is generally better to use set-variable than setq in
.emacs, because it can sometimes catch type errors.

Is there a reason not to make such a general recommendation? My guess is
that 90% of the people who set options in .emacs do so with setq, and 90% of
those settings would be better made with set-variable.

Custom and .emacs are both (still) recommended ways of customizing Emacs, if
I'm not mistaken. There is probably some doc (guidelines) on writing a
.emacs file. Unless there is some reason not to, I suggest that we mention
set-variable (vs setq) in that doc section.

    If t is a legal value and the problem is that Custom claims it is not,
    then there is a bug in the defcustom.

I was clear that t was not valid in this example.

Re: Question about set-variable in .emacs

[Richard M. Stallman]

    If t is an illegal value for foo, then the obvious recommendation
    would be that the user would not set foo to an illegal value.  The
    fact that the user does not get warned would not seem that much of a
    problem, since people who do not use Custom presumably do not _want_
    this type of hand holding.

I agree with your point, but please call these values "invalid", not
"illegal".  They are not forbidden by law.  See the GNU Coding
Standards.