Richard Stallman wrote:
With the current code, they do _not_ get reloaded when already loaded.
If I would re-implement it, they would be reloaded.
How about making that fix? It should pretty easy.
It is not at all as trivial as it seems. The current Custom themes
code is not a
With the current code, they do _not_ get reloaded when already loaded.
If I would re-implement it, they would be reloaded.
How about making that fix? It should pretty easy.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/
With the current code, they do _not_ get reloaded when already loaded.
If I would re-implement it, they would be reloaded.
If that's the easiest way to get correct functioning, please do it.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http
David Kastrup wrote:
I guess that a theme, when required, will get reloaded even if it has
been loaded previously.
With the current code, they do _not_ get reloaded when already loaded.
If I would re-implement it, they would be reloaded.
Sincerely,
Luc.
_
It seems impossible to figure out what custom-do-theme-reset is really
_trying_ to do
You said it resets all themes. That sounds like a good definition.
Please take that as the purpose of the function.
What the function apparently wants to do is "exactly the same thing as
what th
It seems impossible to figure out what custom-do-theme-reset is really
_trying_ to do
You said it resets all themes. That sounds like a good definition.
Please take that as the purpose of the function.
What the function apparently wants to do is "exactly the same thing as
what th
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> I do not use XEmacs and I do not know whether the XEmacs version is
> actually in active use and works according to some consistent
> philosophy. I do not know how important compatibility with XEmacs in
> the Emacs Custom Themes implementation.
If you
"Richard M. Stallman" <[EMAIL PROTECTED]> writes:
> If I had to implement themes from scratch, my philosophy would be that
> if two loaded themes conflict, then the most recently added one takes
> precedence.
>
> That sounds like a good approach. I see a few approaches that
> could ma
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> The situation with Custom themes is a lot worse that I thought
> yesterday. I discovered two new bugs, one so serious that it makes
> the Custom themes feature unusable. It is nearly guaranteed that
> even if those two bugs could be solved plenty of ot
Richard Stallman wrote:
Can you fix that doc string to be accurate?
Then you could easily implement a command to undo one theme
using the method I suggested above.
It seems impossible to figure out what custom-do-theme-reset is really
_trying_ to do, and custom-do-theme-reset is used in
Unfortunately, after taking a closer look at it, things are way worse
than I originally thought. It does not appear that there is _any_
support for undoing the requiring of an individual theme in the
current code. You can apparently more or less undo all themes
together (altho
Richard Stallman wrote:
That sounds like a good approach. I see a few approaches that
could make sense:
1. Most recent takes priority.
2. Let user specify the priority order.
3. Don't allow loading themes that conflict.
4. Ask the user what to do, each time there is a conflict.
If I had to implement themes from scratch, my philosophy would be that
if two loaded themes conflict, then the most recently added one takes
precedence.
That sounds like a good approach. I see a few approaches that
could make sense:
1. Most recent takes priority.
2. Let user specify
Unfortunately, after taking a closer look at it, things are way worse
than I originally thought. It does not appear that there is _any_
support for undoing the requiring of an individual theme in the
current code. You can apparently more or less undo all themes
together (although you have to ask
I think even a somewhat incorrect documentation would be a good thing
because it would hopefully give us bug-reports that'll help us improve both
the code and the doc.
I agree completely. Meanwhile, I think Luc's latest fixes make it
work well enough to be useful. So let's document i
So here is what I am going to do.
I keep require-theme as the basic theme enabling mechanism and do
_not_ replace it by unconditional loading. I implement the solutions
specified below to my three problems. I will install soon. Then
people can try it out and see whether the entire stuff, includ
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 al
Note that, after my patches, the bugs in the Custom Theme machinery
that I am aware of _only_ occur after unloading previously loaded
themes.
What does it mean to "unload" a theme? I can't find anything in the
code that refers to such an operation.
__
Stefan Monnier wrote:
> So it might seem too early to document them in the Emacs manual.
I think the main reason why they're unused is that they're
completely undocumented. I'd love to see some rough documentation for it.
In the patches I sent, I provided documentation in the buffers c
Stefan Monnier wrote:
I think even a somewhat incorrect documentation would be a good thing
because it would hopefully give us bug-reports that'll help us improve both
the code and the doc.
I believe that the documentation I wrote is correct.
However, the problems that remain after my p
> So it might seem too early to document them in the Emacs manual.
I think the main reason why they're unused is that they're
completely undocumented. I'd love to see some rough documentation for it.
It will hopefully help us all better understand the feature and improve it
(especially the UI par
Note that, after my patches, the bugs in the Custom Theme machinery
that I am aware of _only_ occur after unloading previously loaded
themes. I could point out more explicitly in my docs that this is the
only problem. I believe that neither color-theme.el nor etheme.el
even attempt to undo a prev
I took a somewhat more detailed look at the Custom Themes code. It
definitely is unfinished work that is _not_ currently in progress.
>From looking at past threads, I believe that Alex Schroeder just gave
up on it and decided that color-theme.el was the way to go. The
problem with color-theme.el
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> I guess Per may know some of the details.
Nope. Jan Vroonhof wrote the code for XEmacs. I once tried to
integrate it into Emacs, but gave up. I don't believe I was involved
when Dave Love and Alex Schroeder actually went ahead and did integrate it.
I could at least partially alleviate the worst parts of the problems
with cus-theme.el I pointed out, as long as I would know what is an
appropriate default directory for theme files. A new customizable
variable custom-theme-directory with default the user's home directory?
Yes, b
Thanks for finding the bugs in custom themes.
Would you like to fix these bugs? They don't sound terribly
difficult to fix, and then it will be a useful feature.
We've already installed this feature, and it ought to be useful once
it works. We might as well fix the bugs now--there's no benefit
i
Richard Stallman wrote:
I don't remember the details, but it is a matter of defining
a collection of custom settings and giving them a name.
Then you can enable them and disable them by name.
I have the impression nobody knows the details, or would be able to
document them, except a very
>From my previous message:
it was (nearly) two years ago.
Actually, nearly three years ago.
Sincerely,
Luc.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
And there is color-theme.el, which works nicely, is widely deployed in
the Emacs users community, there are many predefined themes and well,
it's just nice.
That does not seem to be included with the CVS Emacs distribution. I
found an Emacs devel thread from about two years ago about add
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Here is a list of problems with `customize-create-theme':
[cut]
And there is color-theme.el, which works nicely, is widely deployed in
the Emacs users community, there are many predefined themes and well,
it's just nice.
--
Did you ever realize how mu
But, by experimentation, I was able to figure out
what it currently actually does: it writes files into random
directories all over your file system without warning.
That is a rather vague description of the behavior.
Perhaps you're describing a bug where it writes
Some questions and remarks _were_ naive. At second look
`customize-create-theme' seems to be a user level command rather than
a Lisp programmer level command, as I first thought. Trying it out,
it seems to have a very unfinished look to it. I still do not really
know what it
But, by experimentation, I was able to figure out
what it currently actually does: it writes files into random
directories all over your file system without warning.
That is a rather vague description of the behavior.
Perhaps you're describing a bug where it writes
a file into the wr
After _trying_ to use Custom themes, it seems totally obvious that
this is a completely unfinished package, completely unready to be used
or documented in its present form. One obvious problem is a total
lack of documentation at any level. That is bad enough, but there is
way worse. In its curre
>From my earlier reply:
I know nothing about them, but some naive questions:
Some questions and remarks _were_ naive. At second look
`customize-create-theme' seems to be a user level command rather than
a Lisp programmer level command, as I first thought. Trying it out,
it seems to have a ve
Richard Stallman wrote:
Could someone please document Custom themes in the Emacs manual?
I know nothing about them, but some naive questions:
Do they already work? Are they used anywhere? The command to create
a theme seems to be `customize-create-theme'. Grepping seems to show
that it is
36 matches
Mail list logo
