Re: Changed outside --> set, in Customize UI

["Lennart Borgman" <lennart.borgman.073@student.lu.se>]

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

> A user option must be under user control. However, as a general rule,
> user control _includes_ the ability to use functions and libraries,
> and that includes using them to set options.

Yes. I believe a lot of users like customizing with other tools than the
Easy Customization GUI. But I do believe that changing defcustom vars should
be done with custom-set-variables (or the like) in those tools. Is that a
problem?


This discussion has also made me wonder if we need some clear explicit rules
for this. It could look something like this:

1) defcustom vars should have a user part and a tools part (ie two variables
as suggested before). Only the user part is handled in Easy Customization
and saved etc. (Maybe the tools part should be shown too however.)

2) Packages that are not meant to do a saveable customization for the user
changes the tools part of this double variable.

3) Those packages that want to do a saveable customization change the user
part. This should be told in the description of the interactive functions
that can cause such changes.

4) The user part takes precedence over the tools part. (This means that
there must be a way to say "don't care about me" for the user part.)

The above rules are just meant for thought now of course.


> What about the use of the "changed outside" flag for those outside
> changes that do represent real problems? ...
> We can try to distinguish between 1) outside changes that can be seen
> to represent bugs and lead to problematic behavior and 2) other
> outside changes. We can then try to fix the problems.
>
> Until fixes are implemented, we could, as Luc suggested, display a
> proper warning for the cases we can identify as problematic.

I agree that it would be good, but should we not go the other way round?
Until we have understood that it is not problematic should we not assume
that it is?

Maybe some of these problems will disappear with the suggestions Richard had
for handling list defcustoms (splitting them in in a "user" and a
"tool/code" part before editing them in Easy Custom).