emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Custom themes


From: Luc Teirlinck
Subject: Re: Custom themes
Date: Tue, 28 Jun 2005 13:46:31 -0500 (CDT)

In the patch I sent:

;; You can also write `(require-theme %s)' in your .emacs file.

should of course be:

;; You can also write `(require-theme '%s)' in your .emacs file.

(I forgot the ').

In as far as this .emacs type use of Custom Themes is concerned,
everything works fine and essentially already worked fine before my
patches, except for the total lack of documentation and the fact that
the UI for creating theme files, `custom-create-theme' had several
problems that are now fixed.  If this would be the main use, then that
use is _definitely_ ready to be documented in the Emacs manual.

My patches also add interactive use of Custom themes, by adding
interactive declarations.  This could actually be considered a new
feature instead of a bug or doc fix, since prior to my patches, there
were no interactive commands enabling you to manipulate Custom
Themes, so you could not use Custom Themes interactively at all.  This
type of use, especially unloading themes is the type that could be
classified as "unfinished" or "experimental" and in need of
substantial improvement.

There _was_ support for interactive use before my patches (_all_
I did was adding interactive declarations to existing functions).  But
this support appears to be unfinished.

Problems with interactive use after my patches are varied but seem to
fall into three types given by the examples below.  The first type can
be fixed without replacing requiring by unconditional loading as the
basic theme enabling command, the second type seems to require this
replacement and doing so also would fix the type 1 problems, the
third type requires more fundamental changes.

VAR has standard value 0, Theme1 sets it to 1, Theme2 to 2.

Example 1:

Require Theme1. VAR is 1. Good.  Unload Theme1.  Var is 0.  Perfect.
Require Theme1 again.  No effect, because Theme1 is still provided.

This problem could be fixed by adding:

  (setq custom-loaded-themes (delq theme custom-loaded-themes))
  (setq features (delq (get theme 'theme-feature) features)))

to the end of `custom-do-theme-reset', that is without replacing
`require-theme' by unconditional loading as the basic Theme enabling
command.  But replacing `require-theme' by unconditional loading fixes
it as well and also fixes Example 2.

Example 2:

Require Theme1. VAR is 1. Good. Require Theme2.  VAR is 2.  Good.
Require Theme1 again.  No effect, because Theme1 is already provided.
I would expect to be able to use this to reset VAR to 1.  Basically,
this type of use does require replacing requiring by loading as the
basic interactive theme enabling mechanism.

Example 3:

Require Theme1.  VAR is 1.  Require Theme2.  VAR is 2.  Unload Theme2.
VAR is 0.  I expected it to be 1.  I believe that making it be 1
requires fundamental changes, it would not just result from replacing
`require-theme' by loading.  Again, if you try to manually correct by
requiring Theme1 again, it has no effect.  Loading manually _will_
correct.

Sincerely,

Luc.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]