Eliminating "changed in Emacs outside of Customize"

Eliminating "changed in Emacs outside of Customize"

[Richard Stallman]

Could you tell us the reason why you designed Custom to recognize a
state of "changed in Emacs outside of Customize"?  It would be cleaner
if we could just eliminate that, and make Custom treat values assigned
outside Custom just the same as values assigned within Custom.  Is
there some reason why this would be hard to do or would cause trouble?


Also, I second this request for more internal documentation of how
Custom works.  Can you write some explanations of this?


It would help to have an overview explanation of what the possible customize
states are, and what actions/events cause which state changes - IOW a state
transition machine description.

For instance, it would help to have a table of the correspondances (and
state changes) between the various :custom-state values (hidden, customized,
changed, modified, set, rogue, uknown, invalid, standard, nil) and the
various symbol properties `customize-value', `customized-face',
`saved-variable', `saved-value', `saved-face', `standard-value',
`customized-variable', `customized-variable-comment', `backup-value', etc.

And a little more explanation in `custom-magic-alist' would help - it's not
clear, for instance, just which :custom-state's correspond to "changed
outside Customize", or what the differences are between `set' ("set but not
saved"), `changed' ("changed temporarily"), `modified' ("modified, and has a
valid form"), and `invalid' ("modified, but has a valid form").

Re: Eliminating "changed in Emacs outside of Customize"

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

> Could you tell us the reason why you designed Custom to recognize a
> state of "changed in Emacs outside of Customize"? 

If you .emacs, or some third party code you activate from ".emacs",
contains "(setq foo 42)" and you change and save "foo" from customize,
you changes to the variable through customize will be overwritten next
time you start Emacs.

Which will likely be a big surprise to the user.

In order for customize to work non-surprisingly, it has to be the only
interface for changing the variable.  [ This is why you should never
defcustom a variable that is changed through Lisp code.  Instead,
split the variable in two, one for the Lisp code and one for the user
alone (through customize). ]

> Also, I second this request for more internal documentation of how
> Custom works.  Can you write some explanations of this?

I don't have the time this requires.  Maybe someone can take my
comments here and write them up.

> For instance, it would help to have a table of the correspondances (and
> state changes) between the various :custom-state values (hidden, customized,
> changed, modified, set, rogue, uknown, invalid, standard, nil) and the
> various symbol properties `customize-value', `customized-face',
> `saved-variable', `saved-value', `saved-face', `standard-value',
> `customized-variable', `customized-variable-comment', `backup-value', etc.

The identity of a customize option is represented by a Lisp symbol.
There is the following values associated with an option.  

0. The current value.

   This is the value of the option as seen by "the rest of Emacs".

   Usually extracted by 'default-value', but can be extracted with
   different means if the option symbol has the 'custom-get'
   property.  Similarly, set-default (or the 'custom-set' property)
   can set it.

1. The widget value.

   This is the value shown in the widget in a customize buffer.  

2. The customized value.

   This is the last value given to the option through customize.

   It is stored in the 'customized-value' property of the option, in a
   cons-cell whose car evaluate to the customized value.   

3. The saved value.

   This is last value saved from customize.

   It is stored in the 'saved-value' property of the option, in a
   cons-cell whose car evaluate to the saved value.   

4. The standard value.

   This is the value given in the 'defcustom' declaration.

   It is stored in the 'standard-value' property of the option, in a
   cons-cell whose car evaluate to the standard value.   

5. The "think" value.
   
   This is what customize think the current value should be.
   
   This is the customize value, if any such value exists, otherwise
   the saved value, if that exists, and as a last resort the standard
   value. 

The reason for storing values unevaluated: This is so you can have
values that depend on the environment.  For example, you can have a
valiable that has one value when Emacs is running under a window
system, and another value on a tty.  Since the evaluation is only done
when the variable is firsty initialized, this is only relevant for the
saved (and standard) values, but affect others values for
compatibility.

You can see (and modify and save) this unevaluated value by selecting
"Show initial Lisp expression" from the Lisp interface.  This will
give you the unevaluated saved value, if any, otherwise the
unevaluated standard value.

The possible states for a customize widget are:

0. unknown

   The state has not been determined yet.

1. modified

   The widget value is different from the current value.

2. changed
   
   The current value is different from the "think" value.   

3. set

   The "think" value is the customized value.

4. saved

   The "think" value is the saved value.

5. standard

   The "think" value is the standard value.

6. rogue

   There are no standard value.

7. hidden

   There is no widget value.

8. mismatch

   The widget value is not valid member of the :type specified for the
   option. 

Re: Eliminating "changed in Emacs outside of Customize"

[Richard Stallman]

    > Could you tell us the reason why you designed Custom to recognize a
    > state of "changed in Emacs outside of Customize"? 

    If you .emacs, or some third party code you activate from ".emacs",
    contains "(setq foo 42)" and you change and save "foo" from customize,
    you changes to the variable through customize will be overwritten next
    time you start Emacs.

Are you saying your concern was specifically for the case
where foo is set outside Custom *from the init file*?

What about the case where the user just evals M-: (setq foo 42) RET
while running Emacs?  Do you see a reason why this needs to be
described as "changed outside Customize"?  If instead it were
described as "Set but not saved", exactly as if the user had used
Customize to set it to 42, do you see any problem that would happen?

    In order for customize to work non-surprisingly, it has to be the only
    interface for changing the variable.

Why do you think so?  In particular, if changes outside Custom
were treated as if they had happened within Custom, what problem
do you envision?

One way to implement this is to identify the "customized value" of a
variable with its Lisp value.  Another way is to copy the Lisp value
to the "customized value" on various occasions, such as at the
beginning of doing certain operations on the widget.


Thanks for the explanation text.  I will put it into cus-edit.el.

Re: Eliminating "changed in Emacs outside of Customize"

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

>     > Could you tell us the reason why you designed Custom to recognize a
>     > state of "changed in Emacs outside of Customize"? 
>
>     If you .emacs, or some third party code you activate from ".emacs",
>     contains "(setq foo 42)" and you change and save "foo" from customize,
>     you changes to the variable through customize will be overwritten next
>     time you start Emacs.
>
> Are you saying your concern was specifically for the case
> where foo is set outside Custom *from the init file*?

Yes, directly and indirectly.

> What about the case where the user just evals M-: (setq foo 42) RET
> while running Emacs?  

I suspect that is much rarer.

> If instead it were
> described as "Set but not saved", exactly as if the user had used
> Customize to set it to 42, do you see any problem that would happen?

Any command that set the variable interactively is ok.  I believe part
of the manu bar code use "setq" or "custrom-set-variable" depending on
whether it is called interactively or not.

>     In order for customize to work non-surprisingly, it has to be the only
>     interface for changing the variable.
>
> Why do you think so?  In particular, if changes outside Custom
> were treated as if they had happened within Custom, what problem
> do you envision?

Was this unclear: 

  If you .emacs, or some third party code you
  activate from ".emacs", contains "(setq foo 42)" and you change and
  save "foo" from customize, you changes to the variable through
  customize will be overwritten next time you start Emacs.

?

RE: Eliminating "changed in Emacs outside of Customize"

[Drew Adams]

I didn't think that we wanted to get into such discussions at this time. I
was intending to bring up this question only after the release.

But as long as people are discussing it, maybe we can decide to look into
the _question_ a little, to understand the current design better, without
going any further now.

I know that I don't understand the rationale behind this separation
inside/outside customize, and if I did I might be able to stop thinking
about trying to "improve" on it ;-). IOW, I really don't understand it, and
I really want to.

Why? Because if such a distinction were not really needed, then I think it
would be clearer for users to just have any change (regardless of where/how)
be treated as "setting" the user option.

    Was this unclear:

      If you .emacs, or some third party code you
      activate from ".emacs", contains "(setq foo 42)" and you change and
      save "foo" from customize, you changes to the variable through
      customize will be overwritten next time you start Emacs.

Yes, it's unclear to me. Or, rather, it seems clear to me, but I think I
must be misunderstanding it, because I don't see the problem.

Does this action sequence correspond to what you mean?

1. Put (setq baud-rate 28400) in an otherwise empty .emacs.
2. Start emacs and customize baud-rate. The value shows as 28400 "changed
outside". Change it to 56000 and save it.

The setq appears before the custom-set-variable in your .emacs, so nothing
is overwritten (that I can see). If you restart emacs and customize
baud-rate, the value is 56000 "set and saved". Is there a pb I'm missing
here?

Perhaps you meant executing a setq _after_ the custom-set-variable (e.g. in
a library you load after the .emacs is loaded). If so:

1. Move the setq after the custom-set-variable in your .emacs.
2. Restart emacs and customize baud-rate. The value shows as 28400 "changed
outside".
3. Click "reset to saved". The value is 56000 "set and saved".

Something has changed the value after you loaded the saved value, but I
still don't see any problem. The customize state reflects that perfectly.

Of course, that is with the current system. You are saying that there
_would_ be a problem _if_ we treated "changed outside customize" as simply
"set". I don't understand how that would make any difference in this
scenario (action sequence above), besides indicating "set" to the user
instead of "changed outside customize" (which I think would be preferable).

So I'm guessing that I have misunderstood you. If the action sequence above
is not what you meant, what is?

Thanks,

  Drew

Re: Eliminating "changed in Emacs outside of Customize"

[Stefan Monnier]

>     Was this unclear:

>       If you .emacs, or some third party code you
>       activate from ".emacs", contains "(setq foo 42)" and you change and
>       save "foo" from customize, you changes to the variable through
>       customize will be overwritten next time you start Emacs.

It's crystal clear to me, but let me try to rephrase it, to see if it helps
other people:

   - Let's imagine user Helen has had a (setq-default fill-column 42) in her
     .emacs (or maybe it's in some package that she doesn't even remember
     she's loading from a .emacs).
   - Now let's imagine that Helen notices that her fill-column is too small
     and she wants to set it to something else, like 70.
   - She does M-x customize-variable RET fill-column RET, then changes the
     value, then saves.
   - When she restarts, fill-column is 42 again.
   - Since she's not arrogant, she figures she must have made a mistake so
     she goes through the customize-variable thingy again.
   - When she restarts, fill-column is still stuck at 42.
   - Then comes M-x report-emacs-bug.

Of course the above problem will only happen if the (setq-default
fill-column 42) happens to be executed after Helen's custom-set-variables
(e.g. in a mode-hook or in one of the many poorly written major modes that
happily mess up global variables).


        Stefan

RE: Eliminating "changed in Emacs outside of Customize"

[Drew Adams]

    >     Was this unclear:
    >       If you .emacs, or some third party code you
    >       activate from ".emacs", contains "(setq foo 42)" and
    you change and
    >       save "foo" from customize, you changes to the variable through
    >       customize will be overwritten next time you start Emacs.

    It's crystal clear to me, but let me try to rephrase it, to see
    if it helps other people:

       - Let's imagine user Helen has had a (setq-default
         fill-column 42) in her
         .emacs (or maybe it's in some package that she doesn't
         even remember
         she's loading from a .emacs).
       - Now let's imagine that Helen notices that her fill-column
         is too small
         and she wants to set it to something else, like 70.
       - She does M-x customize-variable RET fill-column RET, then
         changes the
         value, then saves.
       - When she restarts, fill-column is 42 again.
       - Since she's not arrogant, she figures she must have made a
         mistake so
         she goes through the customize-variable thingy again.
       - When she restarts, fill-column is still stuck at 42.
       - Then comes M-x report-emacs-bug.

    Of course the above problem will only happen if the (setq-default
    fill-column 42) happens to be executed after Helen's
    custom-set-variables
    (e.g. in a mode-hook or in one of the many poorly written major
    modes that
    happily mess up global variables).

Right. I believe that's exactly the behavior I described, as well.

What is not at all clear (to me) is what this has to do with the supposed
need to distinguish, for the user, a value that is changed using a customize
buffer from a value that is changed otherwise. The original question was
that: "What would be wrong with treating, in the Customize UI, outside
changes the same as inside changes?"

IOW, nothing in the above description (Stefan's or Per's) makes any mention
of replacing "changed outside" by "set" in the Customize UI. The above
description holds perfectly in today's vanilla Emacs, does it not?

If so, are we in fact getting such bug reports from Helen? If so, then maybe
something could be done to make the behavior clearer to her.

Beyond that, what does this have to do with the question: "What would be
wrong with treating outside changes the same as inside changes - in the
Customize UI?"

 - Drew

Re: Eliminating "changed in Emacs outside of Customize"

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Of course the above problem will only happen if the (setq-default
> fill-column 42) happens to be executed after Helen's
> custom-set-variables (e.g. in a mode-hook or in one of the many
> poorly written major modes that happily mess up global variables).

Wrong.  Customize does not touch variables that have been set outside
of it.  Whether the set-default is executed before or after customize
initializes its variables does not matter.  The only difference is
that if it is customized before, custom-set-variables will call the
:set function (after the fact), something which does not happen
otherwise.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: Eliminating "changed in Emacs outside of Customize"

[Drew Adams]

    > Of course the above problem will only happen if the (setq-default
    > fill-column 42) happens to be executed after Helen's
    > custom-set-variables (e.g. in a mode-hook or in one of the many
    > poorly written major modes that happily mess up global variables).

    Wrong.  Customize does not touch variables that have been set outside
    of it.  Whether the set-default is executed before or after customize
    initializes its variables does not matter.  The only difference is
    that if it is customized before, custom-set-variables will call the
    :set function (after the fact), something which does not happen
    otherwise.

Huh? What's the deal - do I have a different Emacs from everyone else? I'm
using vanilla Emacs from CVS of last July, so I probably do, but I wouldn't
expect this to be different. Did you actually prove the pudding by ta/esting
it?

I see exactly the behavior described by Per, Stefan, and myself - and I see
no pb with it (unlike Stefan and Per).

Following Stefan's directions, an initially empty .emacs ends up being this:

 (setq-default fill-column 42)
 (custom-set-variables
  '(fill-column 75))
 (custom-set-faces)

Upon restarting, fill-column is 75 and flagged "set and saved" in Customize.

If, as Stefan suggested, I place the (setq-default fill-column 42) after the
custom-set* stuff:

 (custom-set-variables
  '(fill-column 75))
 (custom-set-faces)
 (setq-default fill-column 42)

Then, upon restarting, fill-column is 42 and flagged "changed outside
Customize". So, I don't see why you say "Wrong...before or after...does not
matter."

And, if we erased the distinction between "set" and "changed outside", the
only difference (that I can see) would be that, in this last scenario,
fill-column is 42 and flagged "set".

 - Drew

Re: Eliminating "changed in Emacs outside of Customize"

[Robert J. Chassell]

Today's GNU Emacs CVS snapshot, Tue, 2005 Feb  1  13:09 UTC
GNU Emacs 21.3.50.49 (i686-pc-linux-gnu, GTK+ Version 2.4.14) 
started with

    emacs -Q

I see the same behavior in today's CVS snapshot as Drew Adams, who
used an instance of CVS Emacs from last July.

First, I evaluated the following in my *scratch* buffer:

    (setq-default fill-column 42)
    (custom-set-variables
     '(fill-column 75))
    (custom-set-faces)

Drew Adams wrote:

   Upon restarting, fill-column is 75 and flagged "set and saved" in
   Customize.

Yes. Same here.  Except I am not sure what Drew meant by the word
`restarting'; to me that means starting a new instance of Emacs.
Perhaps that is what he did.

In any event, I ran `M-x customize-variable RET fill-column RET' and
saw the message.

Then I evaluated `(setq-default fill-column 42)' after the custom-set*,
like this:

    (custom-set-variables
     '(fill-column 75))
    (custom-set-faces)
    (setq-default fill-column 42)

Drew Adams wrote:

   Then, upon restarting, fill-column is 42 and flagged "changed outside
   Customize". 

Yes, also, when running `M-x customize-variable RET fill-column RET'.

If I remember and understand correctly, this means that at least

    let,
    set, 
    setq, 
    setq-default, 
    defvar, 
    defconst,
    defcustom, 
    set-variable, and 
    custom-set-variables 

are different functions to set the value cell of a symbol, and the
value is the last set in the environment.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Eliminating "changed in Emacs outside of Customize"

[Lennart Borgman]

----- Original Message ----- 
From: "David Kastrup" <dak@gnu.org>

> Wrong.  Customize does not touch variables that have been set outside
> of it.  Whether the set-default is executed before or after customize
> initializes its variables does not matter.  The only difference is
> that if it is customized before, custom-set-variables will call the
> :set function (after the fact), something which does not happen
> otherwise.

Can you please give an example of this? I just tried to test with (setq
debug-on-error t) and then M-x customize-option, debug-on-error. The
customize GUI worked and I could change and save debug-on-error.

There seem to be something I do not understand. Maybe you are referring to
what custom-set-variables does when custom-file is loaded?

Re: Eliminating "changed in Emacs outside of Customize"

[David Kastrup]

"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:

> ----- Original Message ----- 
> From: "David Kastrup" <dak@gnu.org>
>
>> Wrong.  Customize does not touch variables that have been set
>> outside of it.  Whether the set-default is executed before or after
>> customize initializes its variables does not matter.  The only
>> difference is that if it is customized before, custom-set-variables
>> will call the :set function (after the fact), something which does
>> not happen otherwise.
>
> Can you please give an example of this? I just tried to test with
> (setq debug-on-error t) and then M-x customize-option,
> debug-on-error. The customize GUI worked and I could change and save
> debug-on-error.
>
> There seem to be something I do not understand. Maybe you are
> referring to what custom-set-variables does when custom-file is
> loaded?

It appears that I am babbling and confusing this with something else.

Probably with custom-declare-variable calling the setter function if
the value of the variable has been set before custom-declare-variable
is executed.

Sorry for the confusion.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Eliminating "changed in Emacs outside of Customize"

[Luc Teirlinck]

David Kastrup wrote:

   It appears that I am babbling and confusing this with something else.

   Probably with custom-declare-variable calling the setter function if
   the value of the variable has been set before custom-declare-variable
   is executed.

I believe that you were confusing with the defcustom form, which does
not override an already set value (_unless_ the :set function does so)
and its default :initialize function `custom-initialize-reset', which
nevertheless executes the :set function _even_ if the value is already
set.

`custom-initialize-reset' is a dangerous default by the way, as it
could override the user and unpredictably change behavior due to, say,
browsing custom groups and hence inadvertently loading a file and
executing a defcustom.  Indeed, even if the :set function does not
change the value, it can change other stuff.  We decided before that
it was too late to change this default, but I believe that anybody who
writes a defcustom with a :set function should carefully check whether
the default :initialize function is really appropriate for it, taking
into account that not all Emacs users will customize the variable
through Custom.  `custom-initialize-reset' has led to several bugs,
but all _known_ bugs caused by it have been corrected.

Sincerely,

Luc.

Re: Eliminating "changed in Emacs outside of Customize"

[Lennart Borgman]

----- Original Message ----- 
From: "Luc Teirlinck" <teirllm@dms.auburn.edu>

> I believe that you were confusing with the defcustom form, which does
> not override an already set value (_unless_ the :set function does so)
> and its default :initialize function `custom-initialize-reset', which
> nevertheless executes the :set function _even_ if the value is already
> set.

Could you please take this a little bit more precise? I vaugely remember the
discussion, but not the details. It looks to me that there is a mixing of
things. Why should :initialize execute :set if it only is for the purpose of
initializing something, but not actually setting the symbol value? Should
not that code then be in :initialize?

Re: Eliminating "changed in Emacs outside of Customize"

[Luc Teirlinck]

Lennart Borgman wrote:

   Could you please take this a little bit more precise? I vaugely remember the
   discussion, but not the details. It looks to me that there is a mixing of
   things. Why should :initialize execute :set if it only is for the purpose of
   initializing something, but not actually setting the symbol value? Should
   not that code then be in :initialize?

If I remember correctly, it is for the sake of autoloaded defcustoms.
For those, loaddefs.el sets the value, but does not execute the :set
function, because it does not know the :set function.  When the file
is later loaded, `custom-initialize-reset' assures that the :set
function gets executed.  This usually leads to the correct behavior
for people who customized the value using Custom, but can easily lead
to very wrong results for people who set it outside Custom.

So how do you get around the above problem if you can not use the
default :initialize function, because you do not want to force people
to use Custom to set your variable?

The problem that `custom-initialize-reset' tries to address only
occurs when the _"standard"_ (or "Stock" or ...) value requires a :set
function to be properly initialized.  I personally try to avoid such a
situation in the defcustoms I write.

The problem also does not occur if you do not autoload the defcustom.
That will become more difficult.  Indeed, `custom-set-variables' used
to (actually still does, I believe) keep track of :require's using
stuff like:

'(global-font-lock-mode t nil (font-core))

where (font-core) says to load the file "font-core".

If I understood correctly, this feature is scheduled for elimination,
because it creates incompatibility between different Emacs versions.
Instead, it is planned to autoload the defcustoms in question to
record the :require's that way.  The person implementing this will
have to very carefully grep for :initialize in addition to :require
keywords to make sure that this does not break anything.  Of course,
one could eliminate the :initialize problem completely by making
loaddefs _execute_ the :require (maybe it already does), but, unless I
misunderstand something, in that case one could just as well preload
the file and then there is no need for an autoload and there is no
problem whatsoever.

Sincerely,

Luc.

RE: Eliminating "changed in Emacs outside of Customize"

[Drew Adams]

    If I remember correctly, ...autoloaded defcustoms...

Whew! What a lot of information. I hope this is documented somewhere, so
that others can be privy to it too. Thank you.

    this feature is scheduled for elimination,
    because it creates incompatibility between different Emacs versions.

That's the first time I've seen reference to such a backward-compatibility
concern - and I'm glad to see it. I don't say the concern has never been
there, but this is the first time _I've_ seen a hint of it. (At least as far
as Lisp is concerned - I admit that I've seen concern about legacy user
interaction.) Whenever I voice such concern I usually get replies like "just
update to the latest".

Unless of course you didn't mean different versions in the sense of 19, 20,
21, but in some other sense (Windows vs GNU/Linux; Chinese vs Arabic;
graphic vs text-only; color vs B&W; metric vs English; ...).

Re: Eliminating "changed in Emacs outside of Customize"

[Luc Teirlinck]

Drew Adams wrote:

   Whew! What a lot of information. I hope this is documented somewhere, so
   that others can be privy to it too. Thank you.

I described the _current_ behavior.  I may document the 21.4 behavior
whenever it becomes clear what the 21.4 behavior will exactly be.  As
I pointed out, significant changes in behavior are planned and it is
not clear how they will be implemented, nor if they will, in fact, be
implemented.

Sincerely,

Luc.

Re: Eliminating "changed in Emacs outside of Customize"

[Luc Teirlinck]

Drew Adams wrote:

   That's the first time I've seen reference to such a backward-compatibility
   concern - and I'm glad to see it.

Unfortunately in this case, it seems that one is going to pay a price
in backward incompatibility anyway.  I must say that I myself do not
fully understand how the proposed changes are supposed to work.  The
autoloads are not going to be executed in old Emacs versions, so the
old (obsolete)

'(global-font-lock-mode t nil (font-lock))

is apparently going to have to "re-replace" the current

 '(global-font-lock-mode t nil (font-core))

if somebody is to be able to use the same .emacs for 21.4 and earlier
versions.

There seems to be no way to make two incompatible Emacs versions
before 21.4 compatible.   defcustoms in third party packages may no
longer work with 21.4.

Sincerely,

Luc.

Re: Eliminating "changed in Emacs outside of Customize"

[Richard Stallman]

    The problem also does not occur if you do not autoload the defcustom.
    That will become more difficult.  Indeed, `custom-set-variables' used
    to (actually still does, I believe) keep track of :require's using
    stuff like:

    '(global-font-lock-mode t nil (font-core))

    where (font-core) says to load the file "font-core".

This feature is used only for defcustoms that specify :require.
Very few defcustoms that are explicitly present in the source
use :require.  Mostly the defcustoms that use :require are
generated by macroexpansion of define-minor-mode.

So what I want to do is change the way define-minor-mode works.
That would not require finding and checking the explicit defcustoms.

Re: Eliminating "changed in Emacs outside of Customize"

[David Kastrup]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> David Kastrup wrote:
>
>    It appears that I am babbling and confusing this with something else.
>
>    Probably with custom-declare-variable calling the setter function if
>    the value of the variable has been set before custom-declare-variable
>    is executed.
>
> I believe that you were confusing with the defcustom form,

[...]

Well, yes.  Once I am babbling, it seems that I remain so.  To my
defense I have to add that I tripped over my network cable, ruining my
network connection and smashing my laptop.  After putting its pieces
together again, network had stopped working, and I suspected the
cable.  A different cable had no better luck, so I pried apart my
PCMCIA Network/Modem card and (after several other futile attempts)
resoldered the network connector with a far too large soldering iron
tip.  But some keys are still not working perfectly.

You get the drift.  It's not really my day today.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: Eliminating "changed in Emacs outside of Customize"

[Drew Adams]

    I believe that you were confusing with the defcustom form, which does
    not override an already set value (_unless_ the :set function does so)
    and its default :initialize function `custom-initialize-reset', which
    nevertheless executes the :set function _even_ if the value is already
    set. ...

Interesting. I wasn't aware of these keyword args to defcustom.

Something I discovered recently that is perhaps related (perhaps not), and
I'm not sure is documented: subsequent defcustom's redefine the `standard'
value of the variable (that is, the value that you can reset to with Reset
to Standard). The current value is not changed; only the `standard' value is
changed.

Of course, it's not recommended for multiple libraries to use defcustom's
for the same variable, but if they do, the last one executed wins, in this
respect.

Re: Eliminating "changed in Emacs outside of Customize"

[Richard Stallman]

    Something I discovered recently that is perhaps related (perhaps not), and
    I'm not sure is documented: subsequent defcustom's redefine the `standard'
    value of the variable (that is, the value that you can reset to with Reset
    to Standard). The current value is not changed; only the `standard' value is
    changed.

That seems correct to me.  In particular, it means you can edit the
defcustom and eval the edited one, and the edit takes effect.

Re: Eliminating "changed in Emacs outside of Customize"

[Lennart Borgman]

----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>

> That seems correct to me.  In particular, it means you can edit the
> defcustom and eval the edited one, and the edit takes effect.

Does not defface works differently in this respect?

Re: Eliminating "changed in Emacs outside of Customize"

[Richard Stallman]

    > That seems correct to me.  In particular, it means you can edit the
    > defcustom and eval the edited one, and the edit takes effect.

    Does not defface works differently in this respect?

I don't know--does it?

RE: Eliminating "changed in Emacs outside of Customize"

[Drew Adams]

        I'm not sure is documented: subsequent defcustom's redefine
        the `standard'
        value of the variable (that is, the value that you can
        reset to with Reset
        to Standard). The current value is not changed; only the
        `standard' value is
        changed.

    That seems correct to me.  In particular, it means you can edit the
    defcustom and eval the edited one, and the edit takes effect.

I didn't mean to suggest that this was not the right behavior. I was a bit
surprised, but only because of the leave-alone-if-defined behavior of
defcustom and defvar wrt _current value_. My point is that we should make
sure it is doc'd somewhere (perhaps it is).  - Drew

RE: Eliminating "changed in Emacs outside of Customize"

[Drew Adams]

    It appears that I am babbling and confusing this with something else.
    Probably with custom-declare-variable calling the setter function if
    the value of the variable has been set before custom-declare-variable
    is executed. Sorry for the confusion.
    ...
    Well, yes.  Once I am babbling, it seems that I remain so.  To my
    defense I have to add that I tripped over my network cable, ruining my
    network connection and smashing my laptop.  After putting its pieces
    together again, network had stopped working, and I suspected the
    cable.  A different cable had no better luck, so I pried apart my
    PCMCIA Network/Modem card and (after several other futile attempts)
    resoldered the network connector with a far too large soldering iron
    tip.  But some keys are still not working perfectly.

    You get the drift.  It's not really my day today.

Ouch!

Anyway, no need to feel sorry. Customize is confusing to lots of us, I
suspect.

I feel silly saying that I don't understand what Stefan and Per are trying
to help us understand, but I don't know another way to learn than a
dialectical back-and-forth. Until I see the error of my ways I'll try to
convince you of (what I think is) the error of your ways :-). I may feel
silly, but I don't feel sorry for trying, unless it turns out that I waste
_everyone's_ time and I belong on a different mailing list.

Re: Eliminating "changed in Emacs outside of Customize"

[Lennart Borgman]

----- Original Message ----- 
From: "Stefan Monnier" <monnier@iro.umontreal.ca>

> (e.g. in a mode-hook or in one of the many poorly written major modes that
> happily mess up global variables).

Following Per A's suggestion to distinguish between defcustom variables
(that should not be changed by code) and defvar (that may be changed by
code) it is perhaps not to difficult to look for code that changes
defcustoms?

Re: Eliminating "changed in Emacs outside of Customize"

[Richard Stallman]

It is normal and not unusual for Lisp code to set buffer-local values
for defcustom variables, and to bind them with `let'.
Consider case-fold-search, for instance, and paragraph-separate.

It is not clean for Lisp code to set case-fold-search globally, since
it is cleaner to make a let binding instead.  But I would not endorse
the idea of making a "rule" against this.

Re: Eliminating "changed in Emacs outside of Customize"

[Per Abrahamsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Of course the above problem will only happen if the (setq-default
> fill-column 42) happens to be executed after Helen's custom-set-variables
> (e.g. in a mode-hook or in one of the many poorly written major modes that
> happily mess up global variables).

You got it exactly right.

The "Changed outside customize" has been a great help for me to catch
those hooks, setq's and poorly written major modes, and I think Emacs
has improved because of it, by fixing the modes and rethinking the
hooks.

I can see there is a lot of followup mails.  I don't have time for
either discussion or design, so I'll skip them unread.  

If someone have specific questions, mail them to me directly.

RE: Eliminating "changed in Emacs outside of Customize"

[Drew Adams]

    The "Changed outside customize" has been a great help for me to catch
    those hooks, setq's and poorly written major modes, and I think Emacs
    has improved because of it, by fixing the modes and rethinking the
    hooks.

    I can see there is a lot of followup mails.  I don't have time for
    either discussion or design, so I'll skip them unread.

    If someone have specific questions, mail them to me directly.

I still have the specific question of _what the problem is_ with the
scenario that you and Stefan (and I) described: a setq (in .emacs or a
library) executed after custom-set-variables. Yes, a setq changes the
current value so that it is no longer the `saved-value' - but so what?

And, more importantly, what that pb has to do with a proposal to eliminate
the distinction between "changed outside" and "set" in favor of only "set".
The behavior in the scenario seems to me to be the _same_, regardless of
whether such a proposal were adopted. IOW, the scenario doesn't seem to show
the reason to maintain the distinction.

I know you're busy, but I think that only you can help with this specific
question. Help us understand what the pb is.

Here's what I wrote before on this (which you perhaps missed):

          Was this unclear:
              If you .emacs, or some third party code you...

    What is not at all clear (to me) is what this has to do with
    the supposed need to distinguish, for the user, a value that is
    changed using a customize buffer from a value that is changed
    otherwise. The original question was that: "What would be wrong
    with treating, in the Customize UI, outside changes the same as
    inside changes?"

    IOW, nothing in the above description (Stefan's or Per's) makes
    any mention of replacing "changed outside" by "set" in the
    Customize UI. The above description holds perfectly in today's
    vanilla Emacs, does it not? ...

    Beyond that, what does this have to do with the question: "What
    would be wrong with treating outside changes the same as inside
    changes - in the Customize UI?"

WRT the value of such a distinction in helping us identify "hooks, setq's
and poorly written major modes" that don't play by the rules: I've found (by
experiment) that removing the distinction changed-outside/set actually makes
such faulty library codings _more visible_, not less. If every change is
considered to "set" the option, then querying with customize-customize picks
up all such faulty changes (along with any user changes made inside
customize).

Yes, the same info is available today via customize-rogue. My point is that
erasing the distinction (in the UI, for users) doesn't hamper our ability to
find such rogue library coding. And in fact it can make it more visible to
more users. That visibility could help us by inviting more bug reports on
faulty coding in libraries that we might not check otherwise.

So, the main thing that it would be a great help to clear up is 1) just what
is the pb with the scenario that you outlined, and 2) what does that
scenario (and pb) have to do with possibly erasing the distinction between
changed-outside and set.

Thanks,

   Drew

Re: Eliminating "changed in Emacs outside of Customize"

[Lennart Borgman]

----- Original Message ----- 
From: "Drew Adams" <drew.adams@oracle.com>

> I still have the specific question of _what the problem is_ with the
> scenario that you and Stefan (and I) described: a setq (in .emacs or a
> library) executed after custom-set-variables. Yes, a setq changes the
> current value so that it is no longer the `saved-value' - but so what?

The novice user changes a value in customize, saves and restarts Emacs. Then
he find that the value is still the same. His conclusion is that there is
something wrong with Emacs. He does not dare to use it any more.

>     The original question was that: "What would be wrong
>     with treating, in the Customize UI, outside changes the same as
>     inside changes?"

I think the distinction is good. It was however very confusing the first
time I saw it. When I now see the distinction between user variables (should
only be changed by the user) and others it is much more clear. Should not
this distinction should be pointed out very clearly in Info under Easy
Customization?

I would prefer a marriage between set-variable and customize however.

One problem I see (see above) is the order of execution at startup of Emacs.
This was to some extent discussed when we wrote about custom-file. I still
believe it would be good to have custom-file executed after .emacs by
default. In that case customize could warn for "rouge" custom variable
states.

RE: Eliminating "changed in Emacs outside of Customize"

[Drew Adams]

    > I still have the specific question of _what the problem is_ with the
    > scenario that you and Stefan (and I) described: a setq (in .emacs or a
    > library) executed after custom-set-variables. Yes, a setq changes the
    > current value so that it is no longer the `saved-value' - but so what?

    The novice user changes a value in customize, saves and
    restarts Emacs. Then
    he find that the value is still the same. His conclusion is
    that there is
    something wrong with Emacs. He does not dare to use it any more.

Yes (here we go 'round again) - that is exactly the behavior that we have
_today_, in spite of our blessed distinction between "changed outside
customize" and "set within customize".

What is the specific problem that Per and Stefan think would result from
treating "changed outside" as "set"?  IOW, what does this "pb" have to do
with a proposal to subsume "changed outside" under "set"?

We were told that this pb would result in users making bug reports _if_ we
treated "changed outside" as "set", but there has been no explanation of the
connection between this pb and that proposed enhancement.

The pb as described exists today, yet we don't seem swamped with such bug
reports. And even if we were, that pb has nothing to do with the question at
hand - at least nothing that has been pointed out yet.

So, I don't get it - what's the real pb here in connection with "changed
outside" vs "set"?

    >     The original question was that: "What would be wrong
    >     with treating, in the Customize UI, outside changes the same as
    >     inside changes?"

    I think the distinction is good.

Why? Will someone please tell me _why_ it is good? That was the original
question. To which question we got the scenario we're all familiar with by
now. But I don't see how that scenario shows why this distinction is good.
The "pb" pointed to by that scenario is independent of whether we keep this
distinction or get rid of it (for the UI).

Or, if it is not independent, please show the connection.

    It was however very confusing the first
    time I saw it. When I now see the distinction between user
    variables (should
    only be changed by the user) and others it is much more clear.
    Should not
    this distinction should be pointed out very clearly in Info under Easy
    Customization?

Which distinction? The distinction between "changed outside" and "set" for
user options or the distinction between user variables and non-user
variables? Why bring up the latter in the context of this discussion?

 - Drew

Re: Eliminating "changed in Emacs outside of Customize"

[Stefan Monnier]

> The pb as described exists today, yet we don't seem swamped with such bug
> reports. And even if we were, that pb has nothing to do with the question at
> hand - at least nothing that has been pointed out yet.

People maybe suffer from the problem but they don't report it as a bug for
one very good reason: when they look at the variable that they've
customized, Custom tells them "changed outside of a customize buffer", so
they immediately figure that it must be a problem unrelated to Custom.


        Stefan

Re: Eliminating "changed in Emacs outside of Customize"

[Luc Teirlinck]

Lennart Borgman wrote:

   When I now see the distinction between user variables (should
   only be changed by the user) and others it is much more clear. Should not
   this distinction should be pointed out very clearly in Info under Easy
   Customization?

There is no such generally agreed upon clear cut distinction,
especially not for hooks, which are the main problem.  From `(elisp)Hooks':

  A "hook" is a variable where you can store a function or functions to
  be called on a particular occasion by an existing program.  Emacs
  provides hooks for the sake of customization.  Most often, hooks are set
  up in the init file (*note Init File::), but Lisp programs can set them
  also.  *Note Standard Hooks::, for a list of standard hook variables.

Say `crazy-global-minor-mode' adds `crazy-fun' to before-save-hook.
`crazy-fun' only makes sense with `crazy-global-minor-mode' enabled
and leads to disaster otherwise.  Disabling `crazy-global-minor-mode'
removes the function from the hook again.  You customize
before-save-hook by adding something to it, while
`crazy-global-minor-mode' is enabled and save it to your .emacs.  Now
you also have permanently added `crazy-fun' to before-save-hook.
_Something_ should warn you about that.  That is what "Customized
outside Custom" does.

I do not believe that there would be widespread support for splitting
every single *-hook into program-*-hook and user-*-hook, which would
be the easiest way to solve the problem.

   I would prefer a marriage between set-variable and customize however.

We decided to implement changes to set-variable _after_ Emacs 21.4 is
released.  Such a change requires rewriting tons of individual :set
functions to work buffer locally.  Deciding what the best way to do
that is may be highly non-trivial and controversial for plenty of :set
functions.

   In that case customize could warn for "rouge" custom variable states.

It would warn all the time about the options you see if you do `emacs -Q'
and then `M-x customize-rogue'.  Every single variable you see there
represents a bug, but a minor one and not necessarily trivial to
correct.  Maybe we could do something about those bugs _after_ emacs
"21.4" is released.

It would _not_ warn about crazy-fun, which would be the more serious problem.

Drew Adams wrote:

    What is the specific problem that Per and Stefan think would result from
    treating "changed outside" as "set"?

Adding crazy-fun to before-save-hook in the scenario above *without warning*.
"Changed outside Custom" is a *warning*.  If you know why it as changed
outside Custom and you know it is harmless, you can ignore the warning.

Sincerely,

Luc.

Re: Eliminating "changed in Emacs outside of Customize"

[Lennart Borgman]

----- Original Message ----- 
From: "Luc Teirlinck" <teirllm@dms.auburn.edu>

>    I would prefer a marriage between set-variable and customize however.
>
> We decided to implement changes to set-variable _after_ Emacs 21.4 is
> released.

Maybe this is just a misunderstanding? I meant (set-variable ...), not
set-default.

Per A answered in another message that (custom-set-variables ...) was meant
to replace set-variable. I believe (set-variable ...) is seldom used in
code. It is just a bit confusing that it does not record things the same way
as (custom-set-variables ...) - or at least as I believe the last one does
it.

Re: Eliminating "changed in Emacs outside of Customize"

[Luc Teirlinck]

Lennart Borgman wrote:

   Maybe this is just a misunderstanding? I meant (set-variable ...), not
   set-default.

I meant set-variable too.

   Per A answered in another message that (custom-set-variables ...)
   was meant to replace set-variable.

But that is not what actually _happened_.

   I believe (set-variable ...) is seldom used in code.

Of course, it is meant for interactive use.  We decided to implement
changes to the interactive use of `set-variable' (like making it call
the :set function) after 21.4 is released.

Sincerely,

Luc.

Re: Eliminating "changed in Emacs outside of Customize"

[Lennart Borgman]

----- Original Message ----- 
From: "Luc Teirlinck" <teirllm@dms.auburn.edu>

> I do not believe that there would be widespread support for splitting
> every single *-hook into program-*-hook and user-*-hook, which would
> be the easiest way to solve the problem.

Thanks for the explanation. But in this case would it not be only the
defcustom hooks we consider?

Re: Eliminating "changed in Emacs outside of Customize"

[Lennart Borgman]

----- Original Message ----- 
From: "Lennart Borgman" <lennart.borgman.073@student.lu.se>

> Thanks for the explanation. But in this case would it not be only the
> defcustom hooks we consider?

Sorry, I should have counted them. There are over 400 in the Emacs dist.

Re: Eliminating "changed in Emacs outside of Customize"

[Richard Stallman]

    > I still have the specific question of _what the problem is_ with the
    > scenario that you and Stefan (and I) described: a setq (in .emacs or a
    > library) executed after custom-set-variables. Yes, a setq changes the
    > current value so that it is no longer the `saved-value' - but so what?

    The novice user changes a value in customize, saves and restarts Emacs. Then
    he find that the value is still the same.

If he sees that Customize starts out saying the value has been set in
the current session, won't that be enough to guide him?  After all, he
knows he has not set the variable yet IN Customize.  Won't that be
enough, usually, for the user to deduce it was set outside Customize?

     His conclusion is that there is
    something wrong with Emacs.

If he realizes it was set outside Customize, I think he won't reach
this conclusion.

    I still
    believe it would be good to have custom-file executed after .emacs by
    default. In that case customize could warn for "rouge" custom variable
    states.

I don't understand what it means to "have custom-file executed after
.emacs".

Re: Eliminating "changed in Emacs outside of Customize"

[Lennart Borgman]

----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>

> If he sees that Customize starts out saying the value has been set in
> the current session, won't that be enough to guide him?  After all, he
> knows he has not set the variable yet IN Customize.  Won't that be
> enough, usually, for the user to deduce it was set outside Customize?

Probably if it is pointed out clearly.

>     I still
>     believe it would be good to have custom-file executed after .emacs by
>     default. In that case customize could warn for "rouge" custom variable
>     states.
>
> I don't understand what it means to "have custom-file executed after
> .emacs".

Stefan had a suggestion that custom-file should be loaded after .emacs if it
had not been loaded at that point. However I regret I mentioned that again
now. The problems we unfortunately see with Customize are too complex at the
moment. Too many details will perhaps make it harder to find any solution
and move to that now. (Which I think will be desireable even if it may be a
suboptimization.)

Re: Eliminating "changed in Emacs outside of Customize"

[Richard Stallman]

    The "Changed outside customize" has been a great help for me to catch
    those hooks, setq's and poorly written major modes, and I think Emacs
    has improved because of it, by fixing the modes and rethinking the
    hooks.

We could provide an option to continue making the distinction,
for the sake of testing.

Re: Eliminating "changed in Emacs outside of Customize"

[Stefan Monnier]

>     The "Changed outside customize" has been a great help for me to catch
>     those hooks, setq's and poorly written major modes, and I think Emacs
>     has improved because of it, by fixing the modes and rethinking the
>     hooks.

I think it'd be useful to add a warning/prompt when saving, along the lines
of "set outside customize: saving may not work".  With such a warning, we
could drop the "changed outside customize" state (well: keep it internally,
of course, but not show it to the user) and still know that users won't be
surprised when things don't work.


        Stefan

Re: Eliminating "changed in Emacs outside of Customize"

[Lennart Borgman]

----- Original Message ----- 
From: "Stefan Monnier" <monnier@iro.umontreal.ca>

> I think it'd be useful to add a warning/prompt when saving, along the
lines
> of "set outside customize: saving may not work".  With such a warning, we
> could drop the "changed outside customize" state (well: keep it
internally,
> of course, but not show it to the user) and still know that users won't be
> surprised when things don't work.

Would not this mean that you would get less overview and that you would
often not get any warning until you tried to save or set that particular
option?

Re: Eliminating "changed in Emacs outside of Customize"

[Stefan Monnier]

>> I think it'd be useful to add a warning/prompt when saving, along the
>> lines of "set outside customize: saving may not work".  With such
>> a warning, we could drop the "changed outside customize" state (well:
>> keep it internally, of course, but not show it to the user) and still
>> know that users won't be surprised when things don't work.

> Would not this mean that you would get less overview and that you would
> often not get any warning until you tried to save or set that particular
> option?

Yes, but it's still better than to drop the whole thing altogether.


        Stefan

Re: Eliminating "changed in Emacs outside of Customize"

[Richard Stallman]

    I think it'd be useful to add a warning/prompt when saving, along the lines
    of "set outside customize: saving may not work".  With such a warning, we
    could drop the "changed outside customize" state (well: keep it internally,
    of course, but not show it to the user) and still know that users won't be
    surprised when things don't work.

In effect, this would be equivalent to maintaining the two states
but treating them more or less the same aside from their names.

RE: Eliminating "changed in Emacs outside of Customize"

[Drew Adams]

        The "Changed outside customize" has been a great help for
        me to catch
        those hooks, setq's and poorly written major modes, and I
        think Emacs
        has improved because of it, by fixing the modes and rethinking the
        hooks.

As I mentioned previously, these can still be caught if "changed-outside" is
conflated with "set", and in fact it is more likely that they will be
caught, because users will find them and report them:

       WRT the value of such a distinction in helping us identify
       "hooks, setq's and poorly written major modes" that don't
       play by the rules: I've found (by experiment) that removing
       the distinction changed-outside/set actually makes
       such faulty library codings _more visible_, not less.
       If every change is considered to "set" the option, then
       querying with customize-customize picks up all such faulty
       changes (along with any user changes made inside customize).

       Yes, the same info is available today via customize-rogue. My
       point is that erasing the distinction (in the UI, for users)
       doesn't hamper our ability to find such rogue library coding.
       And in fact it can make it more visible to more users. That
       visibility could help us by inviting more bug reports on
       faulty coding in libraries that we might not check otherwise.

    We could provide an option to continue making the distinction,
    for the sake of testing.

Yes, if there is any value in maintaining such a distinction _internally_,
that could still be done - for testing or in general.

The question is about the _UI_ only. Does it help users or get in their way
to have such a distinction in the UI? I argue that it is clearer for users
without such a distinction.

Re: Eliminating "changed in Emacs outside of Customize"

[Luc Teirlinck]

Drew Adams wrote:

   The question is about the _UI_ only. Does it help users or get in their way
   to have such a distinction in the UI?

Very definitely.  I like to get accurate information, not false and
misleading information.

"Set for the current session" means that the option is only set for
the current session.  It will not be set anymore if you start another
session.  If I see it were I do not expect it, I know that I
inadvertently released my mouse at the wrong place or entered the
wrong number if I used the keyboard.  (I actually have had that happen
several times.)  That problem needs to be corrected and it is trivial
to do so.

"Changed outside Custom" means something very different.  It means
that it was changed outside Custom.  Maybe it was just set for the
current session and will not be there anymore if I start another
session, maybe it will be set every session.  There is no way for
Custom to figure it out.  The conclusion to be drawn out of that is
that trying to save a value through Custom may not work properly.

   I argue that it is clearer for users without such a distinction.

Not for this user, that is for sure.  I rely heavily on the distinction.
I can not see what is "clear" about identifying to things that have
not the slightest thing to do with each other.

This is not broken.  Let us not break it.

Sincerely,

Luc.

Re: Eliminating "changed in Emacs outside of Customize"

[Luc Teirlinck]

Drew Adams wrote:

   The question is about the _UI_ only. Does it help users or get in their way
   to have such a distinction in the UI?

>From my previous reply:

    Very definitely. 

It was probably clear from the rest of my reply that I meant that it
very definitely _helps_ them.  How it could possibly get in their way
is a complete mystery to me.

Sincerely,

Luc.

Re: Eliminating "changed in Emacs outside of Customize"

[Luc Teirlinck]

Drew Adams wrote:

   The question is about the _UI_ only. Does it help users or get in their way
   to have such a distinction in the UI?

Actually the following might help users even more:

      State: this option has been changed outside the customize buffer.
    Customizing this through Custom can have unpredictable results.

That last line is definitely _not_ an overstatement.

After Emacs 21.4 is out we could try to make sure that those lines
basically never will appear, by trying to eliminate the (unfortunately
numerous) situations that give rise to it.

Sincerely,

Luc.

Re: Eliminating "changed in Emacs outside of Customize"

[Luc Teirlinck]

>From my previous reply:

   After Emacs 21.4 is out we could try to make sure that those lines
   basically never will appear, by trying to eliminate the (unfortunately
   numerous) situations that give rise to it.

That would not eliminate .emacs as a source of the stuff, but that is
the user's responsibility.  If he does not want to get warned about
inconsistent customizations, he can put the custom-set-{variables,
faces} forms at the end of .emacs.  If he does want to be warned about
them he can put those forms at the beginning of his .emacs.

Sincerely,

Luc.

Re: Eliminating "changed in Emacs outside of Customize"

[Luc Teirlinck]

>From my previous message:

>From my previous message:

   After Emacs 21.4 is out we could try to make sure that those lines
   basically never will appear, by trying to eliminate the (unfortunately
   numerous) situations that give rise to it.

Actually, unlike what I said in a previous message, this would not
eliminate the warnings due to user customizations in .emacs.  But I
emphasized the wrong thing in the quote above.  The important thing is
not to eliminate "Set outside of Custom" statements _as a goal in its
own right_.  The important thing (for after emacs 21.4) is to make sure
that people can safely customize options like `find-file-hook',
`completion-ignored-extensions' and many others, through Custom,
which they can currently not do.

Sincerely,

Luc.

Re: Eliminating "changed in Emacs outside of Customize"

[Robert J. Chassell]

        The "Changed outside customize" has been a great help for me ...

    We could provide an option ...

As far as I can see, the only reasonable way to avoid a message of
that sort is to make sure that customize reports the *actual* value.

And then, it would be useful for customize to tell a user whether the
actual value was set by custom-set-faces or custom-set-variables or by
some other function.

Please remember:  we do not want to discourage people, especially
non-hackers, from learning Emacs Lisp.  We want people to write code,
even simple code, in their .emacs file.  Otherwise, Emacs becomes
mysterious.  

The interface that uses the custom-set-* functions should always be a
stepping stone.  We should expect novices to edit expressions that
appear automatically generated in their .emacs file.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Eliminating "changed in Emacs outside of Customize"

[Richard Stallman]

       - Let's imagine user Helen has had a (setq-default fill-column 42) in her
	 .emacs (or maybe it's in some package that she doesn't even remember
	 she's loading from a .emacs).
       - Now let's imagine that Helen notices that her fill-column is too small
	 and she wants to set it to something else, like 70.
       - She does M-x customize-variable RET fill-column RET, then changes the
	 value, then saves.
       - When she restarts, fill-column is 42 again.

Why so?  If .emacs ends with custom-set-variables, it will install
the value of 70.

I think that Drew Adams' reasoning is correct.  In this latter case,

       - Since she's not arrogant, she figures she must have made a mistake so
	 she goes through the customize-variable thingy again.
 
she would see in Customize that the variable is considered "set in
this session".  So she would know she has to look for something
else that sets the variable.

Re: Eliminating "changed in Emacs outside of Customize"

[Richard Stallman]

    > Why do you think so?  In particular, if changes outside Custom
    > were treated as if they had happened within Custom, what problem
    > do you envision?

    Was this unclear: 

      If you .emacs, or some third party code you
      activate from ".emacs", contains "(setq foo 42)" and you change and
      save "foo" from customize, you changes to the variable through
      customize will be overwritten next time you start Emacs.

It does not seem to justify the statement above.  The statement is not
limited to init files.  It seems to say that *any* setting of the
variable from outside Custom would cause trouble.  But this only
explains why setting the variable *in .emacs* would cause trouble.

If we arranged to record a list of all defcustomed variables that are
explicitly set in other ways from within .emacs, would that make it
possible to solve this problem?

Re: Eliminating "changed in Emacs outside of Customize"

[Stefan Monnier]

> It does not seem to justify the statement above.  The statement is not
> limited to init files.  It seems to say that *any* setting of the
> variable from outside Custom would cause trouble.  But this only
> explains why setting the variable *in .emacs* would cause trouble.

> If we arranged to record a list of all defcustomed variables that are
> explicitly set in other ways from within .emacs, would that make it
> possible to solve this problem?

If we arranged to record such a list, the only source of problem left would
be wrong external packages, which might be a more acceptable risk.
I have no idea how to arrange to record such a list, tho.


        Stefan

Re: Eliminating "changed in Emacs outside of Customize"

[Luc Teirlinck]

Stefan Monnier wrote:

   If we arranged to record such a list, the only source of problem left would
   be wrong external packages, which might be a more acceptable risk.

.emacs is the _lesser_ of the involved problems.

What about code adding functions to defcustomed hooks?  I explained in
detail in an earlier posting how this could lead to problems.  We are
_not_ just talking about rogue external packages.  There _definitely_
is code included with the Emacs distribution that adds code to
defcustomed hooks.  In my earlier posting, I quoted a passage from the
Elisp manual explicitly saying that it was OK for Elisp code to do
that.

Hooks are not the only problem by the way.  Defcustoms for lists or
alists, to which elements can be added _both_ by the user and by Lisp
code, present similar problems.

All that "Changed outside Custom" does is provide a warning.  What is
wrong with that?  As a Custom user I rely on that warning.

Sincerely,

Luc.

Re: Eliminating "changed in Emacs outside of Customize"

[Luc Teirlinck]

>From my earlier message:

   There _definitely_ is code included with the Emacs distribution
   that adds code to defcustomed hooks.

To be more explicit: that adds functions _globally_ to defcustomed
hooks.  Adding functions buffer locally is of course no problem.

Sincerely,

Luc.

Re: Eliminating "changed in Emacs outside of Customize"

[Lennart Borgman]

----- Original Message ----- 
From: "Per Abrahamsen" <abraham@dina.kvl.dk>

> In order for customize to work non-surprisingly, it has to be the only
> interface for changing the variable.  [ This is why you should never
> defcustom a variable that is changed through Lisp code.  Instead,
> split the variable in two, one for the Lisp code and one for the user
> alone (through customize). ]

This is IMO a very good point and if I understand Drew A correctly this is
one thing he has been pointing out. (Though he says a lot more than this.)

It would perhaps be good if set-variable was under the customize umbrella
too?

Re: Eliminating "changed in Emacs outside of Customize"

[Per Abrahamsen]

"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:

> It would perhaps be good if set-variable was under the customize umbrella
> too?

Originally customize-set-variable was intended as a replacement for
set-variable.  But maybe it does too much for that.