`changed' theme.

`changed' theme.

[Luc Teirlinck]

I know we discussed this before, but now things just seem too obvious.

This `changed' theme makes no sense and it makes Custom unnecessarily
complex.  Even after Chong's latest change it still causes bugs, which
I will report shortly.  But the bugs are just one illustration of why
it makes no sense.

The basic problem is the following.  Somebody sets an option outside
Custom, or uses add-hook, in .emacs or during a session.  Then he
loads a theme.  Or some Emacs feature, say a minor mode, sets an
option or adds a function to a hook because it _needs_ to do so for
correct functioning and then the user loads a theme that wants to set
the option or hook.  What should happen?

If the user deliberately sat an option _through Custom_ and then loads
a Theme containing tons of options, then the Theme does not override
the explicit user customization.  An explicit user setq or other
non_Custom customization should not be overridden for exactly the same
reasons.  If an Emacs feature sat the value because it needed that
value, the Theme should not override it and make the explicitly user
enabled feature malfunction.

The problem would be especially bad when users or Emacs features add
functions to hooks or elements to listvars, which is perfectly
legitimate for them to do.  When the user then loads a theme, that
theme could completely replace the value of the hook or listvar,
thereby making Emacs features, or maybe even all of Emacs,
malfunction, for instance by removing essential functions from hooks.

Actually, themes should, in the current situation, _never_ try to set
hooks, or listvars that have to be customized with add-to-list rather
than setq.  But they might easily try it anyway.  I see no mention in
the documentation that they should not do it.  Preventing themes from
overriding any user or program customizations (whether or not done
through Custom) could at least prevent most of the worst problems
(even though not all problems).

_If_ Themes are going to override user/program "rogue" customizations,
then at least they should not try to restore the old rogue value when
the Theme gets unloaded.  This can not be implemented in any remotely
reliable way, because too much could have happened in the meantime.
They should restore the "old" value as determined by Custom.  The
current implementation has bugs, that I will report separately.

Sincerely,

Luc.

Re: `changed' theme.

[Chong Yidong]

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

> If the user deliberately sat an option _through Custom_ and then loads
> a Theme containing tons of options, then the Theme does not override
> the explicit user customization.  An explicit user setq or other
> non_Custom customization should not be overridden for exactly the same
> reasons.  If an Emacs feature sat the value because it needed that
> value, the Theme should not override it and make the explicitly user
> enabled feature malfunction.

Loading a custom-file overrides options set by the user outside
customize; loading a custom theme file does the same thing.

> The current implementation has bugs, that I will report separately.

Please do.

Re: `changed' theme.

[Luc Teirlinck]

Chong Yidong wrote:

   Loading a custom-file overrides options set by the user outside
   customize; loading a custom theme file does the same thing.

Again, do you use Custom at all?  The user's custom-file contains
customizations made _by the user_.  It is loaded at startup.  If it
overrides options set by the user in his .emacs, the user's .emacs has
a bug, because he made conflicting customizations.  Only the user
knows what he really wants and it is up to the user to resolve the
conflict.  No reason for Emacs to worry about anything.

A custom theme file is often not written by the user and contains
suggested customizations which should _not_ override customizations
made explicitly by the user, whether through Custom (which it
_already_ does not override right now) or outside Custom.  It should
also not override values that are essential for certain Emacs
features to function correctly.  But I am repeating things I already
wrote in my previous message and to which you did not respond at all.

Sincerely,

Luc.

Re: `changed' theme.

[Eli Zaretskii]

> Date: Sat, 13 May 2006 23:58:18 -0500 (CDT)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> Cc: emacs-devel@gnu.org
> 
> Chong Yidong wrote:
> 
>    Loading a custom-file overrides options set by the user outside
>    customize; loading a custom theme file does the same thing.
> 
> Again, do you use Custom at all?

Luc, would you please lose the attitude?  It's not a crime not to know
too much about Custom, especially for a veteran Emacs hacker.  Please
try to explain the issues without making it sound as if the other
party needs his brain to be checked out.