emacs-devel
[Top][All Lists]
Advanced

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

Re: doc elisp intro cross reference fixes


From: Stefan Monnier
Subject: Re: doc elisp intro cross reference fixes
Date: 26 Nov 2003 19:51:47 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

>> It is an entirely different interface.
>> (defalias 'set-variable 'customize-set-variable)
>> or 
>> (defalias 'set-variable 'customize-set-value)
>> would make sense though.  The difference is that the first uses the
>> :set function, the later doesn't.
>    Indeed.
> Indeed which one?

Either: they both "would make sense".

> Indeed:  (defalias 'set-variable 'customize-set-variable)
> Note that if you mean this literally, this is a non-trivial change in
> as far as prefix arguments are concerned.

That doesn't mean it doesn't make sense.  It just means it has to be souped
up a little.  But that's a minor issue of coding: nothing compared to the
amount of work necessary to convince people on this list to accept the change
in behavior w.r.t whether or not there's a * in the docstring.

>    Indeed.  We'd just need to make (defvar a b "*c") equivalent
>    to (defcustom a b "c").

> You make this sound a lot simpler than it would be.  This will have to
> be handled individually and very carefully for each *-defvar, a huge
> amount of work.

Doesn't have to be done that way, does it ?

> If an author decided to use a *-defvar instead of a
> defcustom, there probably is a good reason why he decided not to use a
> defcustom.

In few very rare cases.

> For instance, default-enable-multibyte-characters has a
> *-defvar.  You do not want to turn this into a defcustom, because it
> would duplicate the defcustom for enable-multibyte-characters, which
> also sets the default value.

It's just another case of multiple name for the same var, as is the
case for all the default-* vars, right?
We can probably take care of this specially, if needed, although I must say
I don't see the harm is adding a "redundant" custom-var, as long as the
variable does not appear in any normal group and is thus only accessed via
M-x customize-variable or M-x set-variable or somesuch.

> That would be extremely confusing to the Custom user.

I'd expect most custom users would never even be confronted with
the potential for confusion.  And we can of course try and fix those things
as time goes: the important thing is that there is no real hurry.

> Not only would blindly turning a *-defvar into a
> defcustom be dangerous, it is impossible.

BZZT!  Thanks for playing, it works exactly as I showed: (defcustom a b "c")


        Stefan




reply via email to

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