unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
Subject: RE: Question about set-variable in .emacs
Date: Sat, 18 Feb 2006 08:16:59 -0800	[thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICIENADCAA.drew.adams@oracle.com> (raw)
In-Reply-To: <200602181547.k1IFlYi02453@raven.dms.auburn.edu>

       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.

  reply	other threads:[~2006-02-18 16:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-17 17:14 Question about set-variable in .emacs Drew Adams
2006-02-18 15:47 ` Luc Teirlinck
2006-02-18 16:16   ` Drew Adams [this message]
2006-02-19 22:46   ` Richard M. Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DNEMKBNJBGPAOPIJOOICIENADCAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).