[Top][All Lists]

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

Re: doc elisp intro cross reference fixes

From: Kai Grossjohann
Subject: Re: doc elisp intro cross reference fixes
Date: Sun, 30 Nov 2003 20:31:20 +0000
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.2 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>> Maybe one needs to think more radical thoughts: Where is the sense in
>> allowing me to do (setq global-font-lock-mode t) even though it has no
>> effect?
> Do you really mean `setq' (i.e. something outside custom or even
> outside set-variable) ?


>> But maybe it is possible to change Custom such that it doesn't need
>> those variables?
> Huh?  Those variables are needed for other reasons, not for custom.
> There simply needs to be a place where we store the current state
> of those minor modes.  For some minor modes, we can use things
> like (member foo bar-hook) or somesuch, but in general we just
> need a minor-mode variable.

D'oh.  I just /knew/ something had to be wrong, but I didn't know
what.  Hm.  Okay.

> Furthermore, AFAIK, custom already does not need the variable: if you
> provide a setter and a getter that don't use the variable, it won't
> use the variable.  There might be a few places in custom where
> this is not quite true but it should be easy to fix.

Well, IIUC, M-x customize-variable RET global-font-lock-mode RET is
how people frob that setting, isn't it?  And if the variable went
away, people couldn't type that anymore.  That's what I meant with

>> Then we could remove all the variables that have no
>> effect when set via setq,
> You also want to "remove" non-existent variable like stefan-test-1 ?

Well, err.  Hm.  How to explain...

There are some options that can be tweaked via custom by customizing a
variable.  But what actually tweaks the option is the setter function
associated with that variable.

Now one thing that could be done is to change Emacs such that the
setter function is called more often (eg, the setter function could be
called by set-variable).  Then, tweaking the option via custom and
tweaking the option another way works similarly -- by changing the

But another thing that could be done is to change Emacs such that the
variable isn't used as the custom interface anymore.  Instead of
"setting a variable" via custom, people would "turn on a hook" via
custom.  Custom could write (foo-minor-mode 1) or (foo-minor-mode -1)
into the .emacs file, depending on the setting.  This would cause the
foo-minor-mode variable to become an internal variable, not to be
changed by the user.

An effect of this would be that the foo-minor-mode variable could be
documented as storing the current state of that minor mode, and the
"Takes no effect if set via setq" warning doesn't need to be there,
anymore, since also "You can customize this variable" is gone.

Hm.  For example, M-x foo-minor-mode RET could ask the user whether to
make that setting permanent.  If the user says yes, then custom would
write its thing to custom-file.  I realize that this is most probably
not how it is going to be done, but I'm using it just as an example of
how an interface that does not use customize-variable at all is

In some sense, this is a strange idea.  After all, the current
mechanism works well.

But we already need Custom to be able to do other things than just
setting variables (and, en passant, invoking setter functions): it
would be nice if Custom could do some semantic equivalent of add-hook
or remove-hook, and it would be nice if Custom could do some semantic
equivalent of define-key.  So once we do this, we can also have Custom
do the semantic equivalent of invoking foo-minor-mode...

All of the above is just an idea.  Maybe it turns out it is better to
continue using the existing setter-functions mechanism.  Maybe you
already thought about all of this, and discovered that what I'm
suggesting doesn't work.  In this case, I apologize.


reply via email to

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