Starnge comment in Custom Theme code.

Starnge comment in Custom Theme code.

[Luc Teirlinck]

What does the following comment starting on line 679 of custom.el
mean?  I believe that we decided that a theme should never override a
value defined with setq or otherwise set outside Custom.  So the user
value does not have to "come back", it never goes away.

What does the code that follows the comment do?  Nobody will ever find
bugs in the Themes code by using it, because nobody is using it.  So
the only way to find bugs is to read the source code and see what it
does.  Did anybody ever do that?  I tried and concluded that it was
just an incoherent bunch of nonsense, that was not worth trying to fix.

      ;; Add a new setting.
      ;; If the user changed the value outside of Customize, we
      ;; first save the current value to a fake theme, `standard'.
      ;; This ensures that the user-set value comes back if the
      ;; theme is later disabled.

Sincerely,

Luc.

Re: Starnge comment in Custom Theme code.

[Chong Yidong]

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

> What does the following comment starting on line 679 of custom.el
> mean?  I believe that we decided that a theme should never override a
> value defined with setq or otherwise set outside Custom.  So the user
> value does not have to "come back", it never goes away.
>
>       ;; Add a new setting.
>       ;; If the user changed the value outside of Customize, we
>       ;; first save the current value to a fake theme, `standard'.
>       ;; This ensures that the user-set value comes back if the
>       ;; theme is later disabled.

I don't know where "we" decided that, but I wrote that part at
Richard's request.

> What does the code that follows the comment do?  Nobody will ever find
> bugs in the Themes code by using it, because nobody is using it.  So
> the only way to find bugs is to read the source code and see what it
> does.  Did anybody ever do that?  I tried and concluded that it was
> just an incoherent bunch of nonsense, that was not worth trying to fix.

I don't know how many people are using the Themes code, but it is
pretty understandable to me (and I wasn't even the original author).
I don't know what your belly-aching is supposed to accomplish; if
you're suggesting to rewrite the Custom Themes code, it's rather too
late in the release process for that.

Re: Starnge comment in Custom Theme code.

[Luc Teirlinck]

Chong Yidong wrote:

   I don't know where "we" decided that, but I wrote that part at
   Richard's request.

The "we" refers to a discussion several months ago on Emacs devel.  I
believe to remember that Richard then decided that themes should not
override a non-Custom set value.  I could try to find this back in the
archives to be sure that I do not misremember, but if Richard changed
his mind anyway, this is irrelevant.  It is logical to not override a
non-Custom set value, because the user theme is never overridden.

A non-Custom set value is either set by the user, through an explicit
setq or by, say, enabling or disabling a minor mode, or by code that
_needs_ that particular value.  In neither case should a theme
override that.  Doing so would cause trouble.

Sincerely,

Luc.

Re: Starnge comment in Custom Theme code.

[Chong Yidong]

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

> The "we" refers to a discussion several months ago on Emacs devel.  I
> believe to remember that Richard then decided that themes should not
> override a non-Custom set value.

I can't find where this is discussed, if you mean the thread at

http://lists.gnu.org/archive/html/emacs-devel/2005-06/msg01062.html

> but if Richard changed his mind anyway, this is irrelevant.  It is
> logical to not override a non-Custom set value, because the user
> theme is never overridden.

You can also argue that loading a Custom Theme should overrides setq's
since Customize also overrides them.  Note that load-theme can be
called interactively; if a user does M-x load-theme, I don't think he
would expect this to fail to set some variables just because he had
something in his .emacs.

But I have no strong feelings on this, so I'll let Richard make the
decision.

Re: Starnge comment in Custom Theme code.

[Luc Teirlinck]

Chong Yidong wrote:

   You can also argue that loading a Custom Theme should overrides setq's
   since Customize also overrides them.

That is different.  The user explicitly sets individual variables
through Custom.  We decided that Theme values were alternative
"standard" values, that the user should be able to override.  `setq',
minor modes and so on override the regular standard values, so they
should also override the alternative "standard" values set by themes.
That is the only way to be consistent.

Sincerely,

Luc.

Re: Starnge comment in Custom Theme code.

[Chong Yidong]

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

> Chong Yidong wrote:
>
>    You can also argue that loading a Custom Theme should overrides setq's
>    since Customize also overrides them.
>
> That is different.  The user explicitly sets individual variables
> through Custom.

Custom Themes are collections of Custom settings.

Re: Starnge comment in Custom Theme code.

[Luc Teirlinck]

   Custom Themes are collections of Custom settings.

I believe that we just decided some days ago that "Erase
Customization" should reset to the themes value and you actually
implemented that.  This means that we consider themes to be
alternative "standard" values and that we do _not_ consider them as
Custom settings.  "Erase Customization" erases all Custom settings.

Sincerely,

Luc.

Re: Starnge comment in Custom Theme code.

[Luc Teirlinck]

Chong Yidong wrote:

   if a user does M-x load-theme, I don't think he
   would expect this to fail to set some variables just because he had
   something in his .emacs.

It would not "fail" if no as long as the themes value is properly
updated.  Then it does change what is considered the "standard" value.

Sincerely,

Luc.

Re: Starnge comment in Custom Theme code.

[Luc Teirlinck]

Chong Yidong wrote:

   > The "we" refers to a discussion several months ago on Emacs devel.  I
   > believe to remember that Richard then decided that themes should not
   > override a non-Custom set value.

   I can't find where this is discussed, if you mean the thread at

   http://lists.gnu.org/archive/html/emacs-devel/2005-06/msg01062.html

I referred to the following, which Richard wrote when we discussed
Custom Themes many months ago:

    As for settings with setq, those should make the variable a rogue, as
    now.  When the variable is a rogue, theme operations should not touch
    it.

See: http://lists.gnu.org/archive/html/emacs-devel/2005-07/msg00757.html

But what _really_ matters is that we decided a few days ago to
consider Custom Themes (except for the user theme) as alternative
"standard" values.  Together with the fact that later loaded themes
override earlier themes and the standard theme is loaded first, this
unambiguously settles all conflict resolutions in a staightforward
way.  `setq' overrides the regular default even if the defcustom is
later reevaluated, so it should override non-user themes, even if they
are loaded after the setq.

Sincerely,

Luc.

Re: Starnge comment in Custom Theme code.

[Richard M. Stallman]

    I referred to the following, which Richard wrote when we discussed
    Custom Themes many months ago:

	As for settings with setq, those should make the variable a rogue, as
	now.  When the variable is a rogue, theme operations should not touch
	it.

Yes, I did say that in a message.  However, what I subsequently
implemented seems more flexible than that, because it allows themes to
set these variables.

If there are some bugs in custom theme handling of them, I'd rather
fix the bugs than make custom themes not work on them.

    But what _really_ matters is that we decided a few days ago to
    consider Custom Themes (except for the user theme) as alternative
    "standard" values.

What Yidong did (and I think it was right) is call them "themed"
values.  Themed values and standard values are equivalent _in regard
to user Custom settings_, but that's only because both theme values
and default values both come "after" user Custom settings.  It does
not mean they are equivalent in other ways.

I am not sure what is the right way to deal with theme settings of
variables that have been setq's outside Custom, but the argument you
made this time does not seem persuasive.

Re: Starnge comment in Custom Theme code.

[Luc Teirlinck]

Richard Stallman wrote:

   I am not sure what is the right way to deal with theme settings of
   variables that have been setq's outside Custom, but the argument you
   made this time does not seem persuasive.

I believe that setq expresses just as much an individual preference by
the user than a saving or setting through Custom.  If a program did
the setq, the situation may be worse, because the program may be
relying on the setq-ed value for its proper functioning.

One example of a problem that can occur if loading a theme overrides
"rogue" values, but not the user theme:
  
If the user sets cua-mode via Custom then cua-mode seems to set
transient-mark-mode, delete-selection-mode and pc-selection-mode using
setq or minor mode invocation.  Now the user loads a theme with tons
of settings, one of them setting one of these to some other value.
Even if the theme also sets cua-mode to nil, cua-mode stays enabled,
because the theme does not override the cua Custom setting.  With the
cua-set variables away from their cua-defaults, cua-mode is, I
believe, pretty much going to become disfunctional to the user.  There
are also, I believe, going to be problems when the user, seeing the
inconsistency, disables cua-mode.  Then cua-mode seems to reestablish
its own saved old user settings, overriding the theme again.

Sincerely,

Luc.

Re: Starnge comment in Custom Theme code.

[Richard M. Stallman]

    I believe that setq expresses just as much an individual preference by
    the user than a saving or setting through Custom.

That is true in some cases, but it is hard to say anything general
about why a variable was setq'd.

						       If a program did
    the setq, the situation may be worse, because the program may be
    relying on the setq-ed value for its proper functioning.

That is true in some cases.

    If the user sets cua-mode via Custom then cua-mode seems to set
    transient-mark-mode, delete-selection-mode and pc-selection-mode using
    setq or minor mode invocation.

That is an unclean way to do things--I am not surprised that it can
lead to problems.  I can imagine other scenarios where Custom, not
using themes, would give perplexing results for these variables.

I don't know what we should do about it.  Perhaps nothing; it may not
be worth the effort to solve this "right".  However, I don't think we
should try to draw any conclusions about custom themes from a case as
screwed-up as this one.

Re: Starnge comment in Custom Theme code.

[Luc Teirlinck]

>From my previous message:

   Even if the theme also sets cua-mode to nil, cua-mode stays enabled,
   because the theme does not override the cua Custom setting.

Actually, if the user enabled cua-mode _through Custom_, then things
might work more or less OK, because cua-mode would be called again by
the user theme after the other theme was loaded, thereby overriding
the theme for the three other variables too.  But if the user did
`M-x cua-mode' and the theme changed any of the three other variables
without explicitly disabling cua-mode, the problems I described would
occur.  Anyway, these problems apply in general whenever any command
thinks it has to change the values of certain user variables.

Sincerely,

Luc.

Re: Starnge comment in Custom Theme code.

[Luc Teirlinck]

Chong Yidong wrote:

   I don't know how many people are using the Themes code, but it is
   pretty understandable to me (and I wasn't even the original author).

Then could you please make it understandable to other people too by
properly documenting some mysteries?

For instance, take custom-save-variables.  We see:

    (custom-save-delete 'custom-load-themes)
    (custom-save-delete 'custom-reset-variables)
    (custom-save-delete 'custom-set-variables)
    (custom-save-loaded-themes)
    (custom-save-resets 'theme-value 'custom-reset-variables nil)

I understand the third line.  What about the other four?  What
business does the Themes code have writing into a user's Custom file?
All info about themes in supposed to be contained in separate Themes
files.  Nothing I see documented about themes requires Themes to do
_anything_ when variables or faces are saved.

Sincerely,

Luc.

Re: Starnge comment in Custom Theme code.

[Luc Teirlinck]

Chong Yidong wrote:

   I don't know how many people are using the Themes code, but it is
   pretty understandable to me (and I wasn't even the original author).

I should clarify that when I wrote:

   So the only way to find bugs is to read the source code and see
   what it does.  Did anybody ever do that?  I tried and concluded
   that it was just an incoherent bunch of nonsense, that was not
   worth trying to fix.

I was referring to the _original_ Themes code that I tried to read and
fix several months ago.  But there appear to be many remnants of that
code in the present code.

There are still several things in the code that look like a complete
mystery to me.  I gave you one example in custom-save-variables.

Sincerely,

Luc.

Re: Starnge comment in Custom Theme code.

[Luc Teirlinck]

Chong Yidong wrote:

   I don't know what your belly-aching is supposed to accomplish;

Mainly to try to prevent the Custom Theme code from negatively
affecting the general functioning of the non-theme Custom.  Unless
certain issues are satisfactorily resolved, it will.  If these issues
can not be resolved before the release, Custom Themes should quite
simply not be part of the release.

Trying to fix bugs in Custom Themes can easily produce bugs in the
non-theme Custom.  In addition a major problem with Custom Themes
(apart from its bugs) is that to safely make some changes,
enhancements or even bug fixes to Custom, you sometimes have to know
every detail about Custom themes.  These details are vague and
ill-defined, which is a problem in itself, but made worse by the
previous fact.

I believed that we made substantial progress on the issue of clearly
and _simply_ defining what Custom themes are a few days ago.
(Unfortunately, some things you said today put this in doubt again.)
I believe that we decided that a Custom theme was an alternative
standard value, that is, setting a value through a Theme is completely
equivalent with specifying an alternative expression in the defcustom.
If we would _consistently_ stick with that (which implies that Custom
Themes do not override setq) and also consistently stick with the fact
that Themes are stored in separate files loaded in .emacs and that
Custom has nothing to do with it, then Custom Themes would no longer
be the big obstacle to safely making changes in Custom that they are
now.  People would know what Custom Themes are supposed to do without
understanding their code in full detail.

We should remove all Custom Theme code that conflicts with the above
straightforward definition of a Custom Theme and all code that tries to
write into .emacs on behalf of Custom themes.  That would be a big
improvement.  (What about these four lines in `custom-save-variables'
I asked you to explain?)

In addition, things would be a _lot_ cleaner if the theme value got
stored in the standard-value property, to be consistent the above
definition.  Then it would be once again completely safe to make
changes in Custom without worrying about Custom Themes.  But that does
probably imply some more extensive rewriting.

Sincerely,

Luc.

Re: Starnge comment in Custom Theme code.

[Luc Teirlinck]

>From my previous reply:

   For instance, take custom-save-variables.  We see:

       (custom-save-delete 'custom-load-themes)
       (custom-save-delete 'custom-reset-variables)
       (custom-save-delete 'custom-set-variables)
       (custom-save-loaded-themes)
       (custom-save-resets 'theme-value 'custom-reset-variables nil)

   I understand the third line.  What about the other four?

I took a closer look at this myself now and apparently that code is
trying to make the user theme mess with other themes in a way that it
should not be messing.  I propose that we comment out that code, as
well as all related code, and if nobody misses it, eventually remove it.

More precisely, I propose the following two patches, which I can
install if desired.

===File ~/cus-edit-diff=====================================
*** cus-edit.el	24 Dec 2005 09:51:55 -0600	1.260
--- cus-edit.el	24 Dec 2005 18:03:27 -0600	
***************
*** 4069,4079 ****
  (defun custom-save-variables ()
    "Save all customized variables in `custom-file'."
    (save-excursion
!     (custom-save-delete 'custom-load-themes)
!     (custom-save-delete 'custom-reset-variables)
      (custom-save-delete 'custom-set-variables)
!     (custom-save-loaded-themes)
!     (custom-save-resets 'theme-value 'custom-reset-variables nil)
      (let ((standard-output (current-buffer))
  	  (saved-list (make-list 1 0))
  	  sort-fold-case)
--- 4069,4079 ----
  (defun custom-save-variables ()
    "Save all customized variables in `custom-file'."
    (save-excursion
! ;;    (custom-save-delete 'custom-load-themes)
! ;;    (custom-save-delete 'custom-reset-variables)
      (custom-save-delete 'custom-set-variables)
! ;;    (custom-save-loaded-themes)
! ;;    (custom-save-resets 'theme-value 'custom-reset-variables nil)
      (let ((standard-output (current-buffer))
  	  (saved-list (make-list 1 0))
  	  sort-fold-case)
***************
*** 4134,4142 ****
  (defun custom-save-faces ()
    "Save all customized faces in `custom-file'."
    (save-excursion
!     (custom-save-delete 'custom-reset-faces)
      (custom-save-delete 'custom-set-faces)
!     (custom-save-resets 'theme-face 'custom-reset-faces '(default))
      (let ((standard-output (current-buffer))
  	  (saved-list (make-list 1 0))
  	  sort-fold-case)
--- 4134,4142 ----
  (defun custom-save-faces ()
    "Save all customized faces in `custom-file'."
    (save-excursion
! ;;    (custom-save-delete 'custom-reset-faces)
      (custom-save-delete 'custom-set-faces)
! ;;    (custom-save-resets 'theme-face 'custom-reset-faces '(default))
      (let ((standard-output (current-buffer))
  	  (saved-list (make-list 1 0))
  	  sort-fold-case)
***************
*** 4188,4230 ****
        (unless (looking-at "\n")
  	(princ "\n")))))
  
! (defun custom-save-resets (property setter special)
!   (let (started-writing ignored-special)
!     ;; (custom-save-delete setter) Done by caller
!     (let ((standard-output (current-buffer))
! 	  (mapper `(lambda (object)
! 		    (let ((spec (car-safe (get object (quote ,property)))))
! 		      (when (and (not (memq object ignored-special))
! 				 (eq (nth 0 spec) 'user)
! 				 (eq (nth 1 spec) 'reset))
! 			;; Do not write reset statements unless necessary.
! 			(unless started-writing
! 			  (setq started-writing t)
! 			  (unless (bolp)
! 			    (princ "\n"))
! 			(princ "(")
! 			(princ (quote ,setter))
! 			(princ "\n '(")
! 			(prin1 object)
! 			(princ " ")
! 			(prin1 (nth 3 spec))
! 			(princ ")")))))))
!       (mapc mapper special)
!       (setq ignored-special special)
!       (mapatoms mapper)
!       (when started-writing
! 	(princ ")\n")))))
  
! (defun custom-save-loaded-themes ()
!   (let ((themes (reverse (get 'user 'theme-loads-themes)))
! 	(standard-output (current-buffer)))
!     (when themes
!       (unless (bolp) (princ "\n"))
!       (princ "(custom-load-themes")
!       (mapc (lambda (theme)
! 	      (princ "\n   '")
! 	      (prin1 theme)) themes)
!       (princ " )\n"))))
  
  ;;;###autoload
  (defun customize-save-customized ()
--- 4188,4230 ----
        (unless (looking-at "\n")
  	(princ "\n")))))
  
! ;; (defun custom-save-resets (property setter special)
! ;;   (let (started-writing ignored-special)
! ;;     ;; (custom-save-delete setter) Done by caller
! ;;     (let ((standard-output (current-buffer))
! ;; 	  (mapper `(lambda (object)
! ;; 		    (let ((spec (car-safe (get object (quote ,property)))))
! ;; 		      (when (and (not (memq object ignored-special))
! ;; 				 (eq (nth 0 spec) 'user)
! ;; 				 (eq (nth 1 spec) 'reset))
! ;; 			;; Do not write reset statements unless necessary.
! ;; 			(unless started-writing
! ;; 			  (setq started-writing t)
! ;; 			  (unless (bolp)
! ;; 			    (princ "\n"))
! ;; 			(princ "(")
! ;; 			(princ (quote ,setter))
! ;; 			(princ "\n '(")
! ;; 			(prin1 object)
! ;; 			(princ " ")
! ;; 			(prin1 (nth 3 spec))
! ;; 			(princ ")")))))))
! ;;       (mapc mapper special)
! ;;       (setq ignored-special special)
! ;;       (mapatoms mapper)
! ;;       (when started-writing
! ;; 	(princ ")\n")))))
  
! ;; (defun custom-save-loaded-themes ()
! ;;   (let ((themes (reverse (get 'user 'theme-loads-themes)))
! ;; 	(standard-output (current-buffer)))
! ;;     (when themes
! ;;       (unless (bolp) (princ "\n"))
! ;;       (princ "(custom-load-themes")
! ;;       (mapc (lambda (theme)
! ;; 	      (princ "\n   '")
! ;; 	      (prin1 theme)) themes)
! ;;       (princ " )\n"))))
  
  ;;;###autoload
  (defun customize-save-customized ()
============================================================

===File ~/custom-diff=======================================
*** custom.el	24 Dec 2005 09:51:55 -0600	1.110
--- custom.el	24 Dec 2005 19:21:27 -0600	
***************
*** 1121,1131 ****
        (push theme themes-loaded))
      (put by-theme 'theme-loads-themes themes-loaded)))
  
! (defun custom-load-themes (&rest body)
!   "Load themes for the USER theme as specified by BODY.
  
! See `custom-theme-load-themes' for more information on BODY."
!   (apply 'custom-theme-load-themes 'user body))
  \f
  ;;; Enabling and disabling loaded themes.
  
--- 1121,1131 ----
        (push theme themes-loaded))
      (put by-theme 'theme-loads-themes themes-loaded)))
  
! ;; (defun custom-load-themes (&rest body)
! ;;   "Load themes for the USER theme as specified by BODY.
  
! ;; See `custom-theme-load-themes' for more information on BODY."
! ;;   (apply 'custom-theme-load-themes 'user body))
  \f
  ;;; Enabling and disabling loaded themes.
  
***************
*** 1232,1247 ****
    (dolist (arg args)
      (custom-push-theme 'theme-value (car arg) theme 'reset (cadr arg))))
  
! (defun custom-reset-variables (&rest args)
!   "Reset the specs of some variables to their values in certain themes.
! This creates settings in the `user' theme.
  
! Each of the arguments ARGS has this form:
  
!     (VARIABLE FROM-THEME)
  
! This means reset VARIABLE to its value in FROM-THEME."
!     (apply 'custom-theme-reset-variables 'user args))
  
  ;;; The End.
  
--- 1232,1247 ----
    (dolist (arg args)
      (custom-push-theme 'theme-value (car arg) theme 'reset (cadr arg))))
  
! ;; (defun custom-reset-variables (&rest args)
! ;;   "Reset the specs of some variables to their values in certain themes.
! ;; This creates settings in the `user' theme.
  
! ;; Each of the arguments ARGS has this form:
  
! ;;     (VARIABLE FROM-THEME)
  
! ;; This means reset VARIABLE to its value in FROM-THEME."
! ;;     (apply 'custom-theme-reset-variables 'user args))
  
  ;;; The End.
  
============================================================

Re: Starnge comment in Custom Theme code.

[Richard M. Stallman]

       For instance, take custom-save-variables.  We see:

	   (custom-save-delete 'custom-load-themes)
	   (custom-save-delete 'custom-reset-variables)
	   (custom-save-delete 'custom-set-variables)
	   (custom-save-loaded-themes)
	   (custom-save-resets 'theme-value 'custom-reset-variables nil)

       I understand the third line.  What about the other four?

They seem to be saving the current set of loaded themes.
I don't see anything wrong with doing that here.
This is the only place in Lisp code that does so.

Are you arguing that this should be done somewhere else?  If so,
where?  It has to be done somewhere, and no other place does it.
Just to delete this code cannot be desirable.

Re: Starnge comment in Custom Theme code.

[Luc Teirlinck]

Richard Stallman wrote:

   They seem to be saving the current set of loaded themes.
   I don't see anything wrong with doing that here.
   This is the only place in Lisp code that does so.

   Are you arguing that this should be done somewhere else?  If so,
   where? 

I am arguing that either it should _not_ be done, or the Themes doc in
the Emacs manual is wrong or incomplete.  That doc says that to enable
a theme permanently, you have to put (load-theme 'FOO) in your .emacs
file.  If you load a theme interactively, it is only for the current
session.  I completely agree with this particular setup.  But given
that, why would Custom ever want to save loaded themes?

   Are you arguing that this should be done somewhere else?  If so,
   where?

By the user in his .emacs, as documented in the Emacs manual.

Sincerely,

Luc.

Re: Starnge comment in Custom Theme code.

[Richard M. Stallman]

      That doc says that to enable
    a theme permanently, you have to put (load-theme 'FOO) in your .emacs
    file.  If you load a theme interactively, it is only for the current
    session.  I completely agree with this particular setup.

It is entirely consistent, but it is not very good.  Everything else
about custom themes can be done with a convenient interface, but
permanently _using_ a theme requires writing Lisp code.  That is not
good.  We need a convenient interface to permanently adjust the set of
themes.

I agree now that making various custom operations do so is not the
right interface.  But we need to add a good one.  Telling users "edit
.emacs" is not adequate.

Perhaps the interface could be to customize custom-enabled-themes.  We
could make enable-theme and disable-theme work with Custom so that
they won't make it a rogue value.

Re: Starnge comment in Custom Theme code.

[Luc Teirlinck]

Richard Stallman wrote:
   
   They seem to be saving the current set of loaded themes.

No, that is not what it does (I checked).  It is not what it should do
either, for the reasons I explained.

Sincerely,

Luc.

Re: Starnge comment in Custom Theme code.

[Richard M. Stallman]

I see that the manual does not document any feature to save
the set of loaded themes.  So maybe it is ok if Custom does
not save them.  However, it seems to me that it would be much
easier for non-Lisp-programmers to use Custom themes
if we provide some way they can choose them permanently
without having to write Lisp code by hand.

Re: Starnge comment in Custom Theme code.

[Luc Teirlinck]

Richard Stallman wrote:

   However, it seems to me that it would be much
   easier for non-Lisp-programmers to use Custom themes
   if we provide some way they can choose them permanently
   without having to write Lisp code by hand.

(load-theme 'FOO) is trivial syntax, even for people knowing no Lisp
whatsoever.  It is not like specifying keybindings or adding functions
to hooks which both do involve a non-trivial syntax.

In the meantime, we have code that does not do anything useful, that
has the potential for inadvertently messing up a user's init file when
unrelated changes to other Themes code is made (as recently happened)
and that can confuse people who are trying to understand the code.

Should we not just comment it out, as my patches do?  If at some later
point, that code could be rewritten to do something useful (which I
doubt), one could easily uncomment it anyway.

Sincerely,

Luc.

Re: Starnge comment in Custom Theme code.

[Richard M. Stallman]

    What does the code that follows the comment do?  Nobody will ever find
    bugs in the Themes code by using it, because nobody is using it.

It is not released yet, so of course not many people are using it.

								      So
    the only way to find bugs is to read the source code and see what it
    does.  Did anybody ever do that?

I would like more people to do it.

				      I tried and concluded that it was
    just an incoherent bunch of nonsense, that was not worth trying to fix.

We're going to fix it, and your reports are helping us do it.
But could you please leave out the abuse, and just tell us the
facts that will help us fix the bugs?
 
      I believe that we decided that a theme should never override a
    value defined with setq or otherwise set outside Custom.

We recently reaffirmed that themes should never override Custom
settings, but I don't remember discussing the question wrt non-Custom
settings.  Could you tell me when that discussion was, so I can find
the old mail?

I looked at various places in custom.el, and they seem to be 
consistent about treating non-Custom user settings as background
for custom themes.

Re: Starnge comment in Custom Theme code.

[Luc Teirlinck]

Richard Stallman wrote:

   We recently reaffirmed that themes should never override Custom
   settings, but I don't remember discussing the question wrt non-Custom
   settings.  Could you tell me when that discussion was, so I can find
   the old mail?

June 2005.  Thread: More bugs in Custom themes

I provided the exact quote and URL in another message.

Sincerely,

Luc.