[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Customize Rogue

From: Per Abrahamsen
Subject: Re: Customize Rogue
Date: Mon, 10 Mar 2003 15:43:23 +0100
User-agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.1 (sparc-sun-solaris2.8)

Juanma Barranquero <address@hidden> writes:

> The custom-setq I'm talking about would have the *exact* semantics
> of doing M-x customize-variable MY-VAR, setting the value to VALUE
> and then chosing "Save for Future Sessions"...

That would be an a very bad idea, the *only* example where that would
is when you want to bypass code that *deliberately* make it hard to
use setq, and I'd be very surprised if that is the case for any other
variable than 'inhibit-startup-echo-area-message'.  That variable is
difficult to modify non-interactively for political reasons, RMS want
every user to see the message at least once, so he made it hard for a
system administrator to deactivate it for all users.

Luc's set-activate should cover all the variables that are
*accidentally* made hard (or non-intuitive) to set from outside

> Really, the fact that I've chosen inhibit-startup-echo-area-message for
> the example is irrelevant.

Not if it is the only variable in Emacs for which your example makes

> The first one that crossed my mind. But what about those variables whose
> docstring says "Setting this variable directly will have no effect, you
> have to use customize"...? I want to have the option of setting the
> variable directly and getting the customization effect.

There is always, modulo bugs, a specific function you need to call
instead.  However, set-activate will relieve you of the problem of
finding it (fixing the doc-string to mention the function would also
be a good idea).  It will also make it much easier to transition
*from* customize to Lisp, in fact you will be able to automate it

reply via email to

[Prev in Thread] Current Thread [Next in Thread]