custom-declare-variable

custom-declare-variable

[Luc Teirlinck]

As I already pointed out in another message, there is some strangeness
in the custom-declare-variable docstring and the following comment,
As it was at the end of my message, it may have been overlooked.

  DEFAULT is stored as SYMBOL's value in the standard theme.  See
  `custom-known-themes' for a list of known themes.  For backwards
  compatibility, DEFAULT is also stored in SYMBOL's property
  `standard-value'.  At the same time, SYMBOL's property `force-value' is
  set to nil, as the value is no longer rogue."
    ;; Remember the standard setting.  The value should be in the standard
    ;; theme, not in this property.  However, this would require changing
    ;; the C source of defvar and others as well...
    (put symbol 'standard-value (list default))

First of all, the docstring appears to contain a falsehood.  From the
comment (and from the actual code), it appears that DEFAULT is not
_currently_ stored in the standard theme.  But the docstring clearly
seems to indicate an intent to store it in the standard theme and make
standard-value obsolete, which according to the comment, requires a
rewrite of defvar and various other primitives.

This seems to be completely crazy.  There would not appear to be
anything wrong with standard-value.  On the other hand, there are
plenty of things wrong with the bug-saturated attempt at Custom Themes
support in custom.el.  So I believe that it would be very unwise to
make correct functioning of Custom dependent on correct functioning of
the Custom Themes support.  The idea that implementing Custom themes
requires changes to defvar and various other primitives seems
completely crazy to me.  Do we really want to do that?  If not, should
we not delete the above comment and remove the (apparently) false
claims from the above second paragraph of the docstring:

  DEFAULT is stored in SYMBOL's property `standard-value'.  At the
  same time, SYMBOL's property `force-value' is set to nil, as the value
  is no longer rogue.

Sincerely,

Luc.

Re: custom-declare-variable

[Luc Teirlinck]

>From my previous message:

   If not, should we not delete the above comment

Except that we should, of course, keep the following part:

       ;; Remember the standard setting.

Sincerely,

Luc.

Re: custom-declare-variable

[Per Abrahamsen]

Would it be possible to undo the patch that integrated custom themes
into Emacs cvs?

It might be easier to redo theme support from scratch, than make the
current code work...  I mean, if nobody really understand the ideas
behind the design of custom themes, it is unlikely that stepwise
refinement of the code will produce something useful.

Re: custom-declare-variable

[Kim F. Storm]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Would it be possible to undo the patch that integrated custom themes
> into Emacs cvs?

Does it take much more than "cvs remove ..." ?

>
> It might be easier to redo theme support from scratch, than make the
> current code work...  I mean, if nobody really understand the ideas
> behind the design of custom themes, it is unlikely that stepwise
> refinement of the code will produce something useful.

I've seen little evidence that anybody is actually using custom themes
in its current form, so it can hardly be an "important feature" that
should uphold the release.

Besides, there isn't even a mentioning of "custom themes" in NEWS.

So IMO Luc's time can be better spent on other things that makes a
release "more likely to happen in this decade".

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: custom-declare-variable

[Luc Teirlinck]

Per Abrahamsen wrote:

   Would it be possible to undo the patch that integrated custom themes
   into Emacs cvs?

   It might be easier to redo theme support from scratch, than make the
   current code work...  I mean, if nobody really understand the ideas
   behind the design of custom themes, it is unlikely that stepwise
   refinement of the code will produce something useful.

cus-theme.el is probably usable, even with a completely rewritten
Themes code in custom.el, although it would need bug fixes and
improvements.

In as far as the Themes code in custom.el is concerned, I do not even
understand what it is _trying_ to do and some things about it make me
very wary.  There is the strangeness in `custom-declare-variable'
which I pointed out.  There is `custom-do-theme-reset' whose docstring
describes _twice_ what the function does, giving two completely
contradictory descriptions.  I read the code carefully to see which of
the two was correct.  The actual behavior has nothing to do with
either description.  Things like that make you wonder.

Maybe somebody else can take a look at the Themes code in custom.el
and see whether they understand any of it.  Otherwise, I believe that,
at best, some parts of it maybe could be recycled into the new design
we would come up with, but still it means essentially starting over
from scratch.

Sincerely,

Luc.

Re: custom-declare-variable

[Luc Teirlinck]

Kim Storm wrote:

   I've seen little evidence that anybody is actually using custom themes
   in its current form, so it can hardly be an "important feature" that
   should uphold the release.

Maybe it might be good to give an overview of the presently available
alternatives to Custom Themes and what their advantages and
disadvantages are compared to Custom themes.  From this comparison, it
would appear that Custom Themes fill a need and are worth
implementing, but it also makes it is obvious that there is no sense
in rushing them hastily into Emacs 22.

There is the reportedly widely used and popular color-theme.el.  I
believe that color-themes can not be disabled.  They use setq and setq
does not work well with Custom.

Global minor modes can be used as themes.  They have the big advantage
of being _total_ customization themes, working for keybindings and
other stuff, as well as for user options.  They can be disabled.  To
properly disable the mode, the mode has to store the current value of
an option when it changes it, to restore it when the mode is disabled.
That works OK, because the option's value is usually essential to the
proper functioning of the minor mode, so the user should not change it
while the minor mode is enabled.  Minor modes use setq, but in this
case, this is probably ideal, because Custom will and _should_ tell
the user that customizing the option may not work as expected.  This
seems to be the case with cua-mode, for instance, which sets
transient-mark-mode to t and which, if I understand correctly, makes
not much sense without that.

So what would be the advantages of (properly implemented) Custom
themes?  In as far as I see it, there is are only two (closely
related) advantages.  Firstly, unlike color-themes, Custom Themes work
well with Custom.  Secondly, they can not only be disabled (minor
modes can too), but, unlike with global minor modes, the user can
safely override the values they set with other themes or through
Custom (but not using setq).  Themes and Custom store information
allowing for proper conflict resolution (setq does not).  (These
advantages apply to _properly implemented_ Custom Themes, not to
whatever the current code is trying to implement.)

The advantage only exists if conflict resolution is implemented in a
100% accurate and intuitive fashion.  There is no sense in Custom
Themes that more or less work.  People will not use them if they do
not work 100%.  They will use color-theme.el or global minor modes.

Sincerely,

Luc.

Re: custom-declare-variable

[Richard M. Stallman]

      Firstly, unlike color-themes, Custom Themes work
    well with Custom.  Secondly, they can not only be disabled (minor
    modes can too), but, unlike with global minor modes, the user can
    safely override the values they set with other themes or through
    Custom (but not using setq).

This was indeed the reason why I decided to install Custom Themes.

We will make them work, before the next release.
It just needs doing work.

Re: custom-declare-variable

[Richard M. Stallman]

    First of all, the docstring appears to contain a falsehood.  From the
    comment (and from the actual code), it appears that DEFAULT is not
    _currently_ stored in the standard theme.  But the docstring clearly
    seems to indicate an intent to store it in the standard theme and make
    standard-value obsolete, which according to the comment, requires a
    rewrite of defvar and various other primitives.

    This seems to be completely crazy.  There would not appear to be
    anything wrong with standard-value.

I agree.  I think it would be best to eliminate the `standard' theme
(which currently would normally be empty) and stick with the idea
that all enabled themes override the standard values.

      If not, should
    we not delete the above comment and remove the (apparently) false
    claims from the above second paragraph of the docstring:

      DEFAULT is stored in SYMBOL's property `standard-value'.  At the
      same time, SYMBOL's property `force-value' is set to nil, as the value
      is no longer rogue.

I did that (more or less).  Thanks.