unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* themes
@ 2010-10-13  3:35 Miles Bader
  2010-10-13  5:57 ` themes Chong Yidong
  0 siblings, 1 reply; 7+ messages in thread
From: Miles Bader @ 2010-10-13  3:35 UTC (permalink / raw)
  To: emacs-devel

The scuttlebutt has always been that the color-theme stuff is very
flaky, but since there's been some effort to set it up by default, I
decided to try it out.

Some observations:

  1. I normally have a dark-background.  Since the "tango" theme is a
     light-background theme, I did "load-theme RET tango RET" expecting
     it to change my background color ... which it didn't.  Instead, my
     window flashed, and some random faces changed, but mainly things
     seemed exactly the same.

     Is this a bug, or does this theme intentionally not change the
     background color?  If the latter, isn't that kind of awkward, given
     that themes seem to be designed for specific background colors, and
     look pretty bad when on some other background color?  [It seems
     pretty user-unfriendly to make a user change the background color
     himself to match the theme ... most will not even realize they need
     to do so.]

  2. The basic interface seems to be "load-theme", which also turns on
     the theme, and then you can subsequently use "disable-theme" and
     "enable-theme" to turn it off or on again.

     Isn't this kind oaf out-of-sync with general Emacs policy, which is
     that "loading" should only load stuff, and not actually execute it?
     
     Perhaps it would be better to deprecate load-theme for user usage,
     make `enable-theme' the main entry point, and give the latter the
     ability to auto-load themes (and do completion on unloaded themes) etc.

  3. Themes _seem_ to be stacked, which I guess could be nice, but is
     also kind of confusing.

     I wanted to try out various themes, so I did load-theme x,
     load-theme y, etc.  I then wanted to go back to my own settings, so
     at first I did "enable-theme user" which didn't work... then I
     realized that maybe I needed to do "disable-theme x" for all the
     themes I had tried; I did this, but I'm still not back to my
     original faces... Now I'm not sure if there is anyway to get back
     without restarting emacs.

     Anyway, I'm kind of confused.  Am I misunderstanding this stuff?
     Is it simply buggy?  Is this really a good interface...?

Thanks,

-miles

-- 
I'd rather be consing.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: themes
  2010-10-13  3:35 themes Miles Bader
@ 2010-10-13  5:57 ` Chong Yidong
  2010-10-13  6:36   ` themes Miles Bader
  0 siblings, 1 reply; 7+ messages in thread
From: Chong Yidong @ 2010-10-13  5:57 UTC (permalink / raw)
  To: Miles Bader; +Cc: emacs-devel

Miles Bader <miles.bader.fz@renesas.com> writes:

> 1. I normally have a dark-background.  Since the "tango" theme is a
>    light-background theme, I did "load-theme RET tango RET" expecting
>    it to change my background color ... which it didn't.  Instead, my
>    window flashed, and some random faces changed, but mainly things
>    seemed exactly the same.

That sounds like a bug.  The tango theme defines "#eeeeec" for the
background of the `default' face.  Indeed, I just tried with a dark
background set using .Xresources (Emacs.background: Black), and
M-x load-theme RET tango RET changes the background to pale grey.  Could
you provide more details?

> 2. The basic interface seems to be "load-theme", which also turns on
>    the theme, and then you can subsequently use "disable-theme" and
>    "enable-theme" to turn it off or on again.
>
>    Isn't this kind oaf out-of-sync with general Emacs policy, which is
>    that "loading" should only load stuff, and not actually execute it?
>
>    Perhaps it would be better to deprecate load-theme for user usage,
>    make `enable-theme' the main entry point, and give the latter the
>    ability to auto-load themes (and do completion on unloaded themes) etc.

I think this is a good idea.

The main entry point for users, however, should be M-x customize-themes,
rather than the load-theme/enable-theme/disable-theme commands.  This
interface, by default, allows only one theme to be selected at once
(unchecking the "Allow more than one theme at a time" box allows
multiple selections).  This should alleviate the confusion you allude to
over stacking themes.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: themes
  2010-10-13  5:57 ` themes Chong Yidong
@ 2010-10-13  6:36   ` Miles Bader
  2010-10-13 16:01     ` themes Chong Yidong
  0 siblings, 1 reply; 7+ messages in thread
From: Miles Bader @ 2010-10-13  6:36 UTC (permalink / raw)
  To: Chong Yidong; +Cc: emacs-devel

Chong Yidong <cyd@stupidchicken.com> writes:
>> 1. I normally have a dark-background.  Since the "tango" theme is a
>>    light-background theme, I did "load-theme RET tango RET" expecting
>>    it to change my background color ... which it didn't.  Instead, my
>>    window flashed, and some random faces changed, but mainly things
>>    seemed exactly the same.
>
> That sounds like a bug.  The tango theme defines "#eeeeec" for the
> background of the `default' face.  Indeed, I just tried with a dark
> background set using .Xresources (Emacs.background: Black), and
> M-x load-theme RET tango RET changes the background to pale grey.  Could
> you provide more details?

I set my background by customizing the `default' (and _also_ via
.Xresource, since otherwise emacs flashes and goes crazy during
startup).  The custom-theme stuff doesn't seem to be able to cope with
that.

Here's a recipe:

(1) emacs -Q

(2) Evaluate via "C-:" or something:

   (custom-set-faces '(default ((t (:background "black" :foreground "white")))))

(3) M-x customize-themes

(4) Try the various themes; none will succeed in changing the
    background color.


> The main entry point for users, however, should be M-x customize-themes,
> rather than the load-theme/enable-theme/disable-theme commands.

Yeah that's a lot more friendly.  [A good M-x interface would still be
nice of course.]

Thanks,

-Miles

-- 
Infancy, n. The period of our lives when, according to Wordsworth, 'Heaven
lies about us.' The world begins lying about us pretty soon afterward.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: themes
  2010-10-13  6:36   ` themes Miles Bader
@ 2010-10-13 16:01     ` Chong Yidong
  2010-10-13 17:05       ` themes Miles Bader
  0 siblings, 1 reply; 7+ messages in thread
From: Chong Yidong @ 2010-10-13 16:01 UTC (permalink / raw)
  To: Miles Bader; +Cc: emacs-devel

Miles Bader <miles@gnu.org> writes:

> I set my background by customizing the `default' (and _also_ via
> .Xresource, since otherwise emacs flashes and goes crazy during
> startup).  The custom-theme stuff doesn't seem to be able to cope with
> that.

Ah, yes.  This is due to a design decision in the Custom Themes code: it
deliberately ensures that the user's own customizations override
anything set by a theme, which in term overrides changes set outside
Customize.  (All settings should be reversible.)

The idea is that you should be able to load a theme, and then change
individual settings to you disagree with.  This seems like a reasonable
thing to want, though it's true that it could lead to confusion.  Maybe
the Customize Themes buffer should display a warning about this.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: themes
  2010-10-13 16:01     ` themes Chong Yidong
@ 2010-10-13 17:05       ` Miles Bader
  2010-10-13 21:20         ` themes Frank Schmitt
  2010-10-17  0:07         ` themes Chong Yidong
  0 siblings, 2 replies; 7+ messages in thread
From: Miles Bader @ 2010-10-13 17:05 UTC (permalink / raw)
  To: Chong Yidong; +Cc: emacs-devel

Chong Yidong <cyd@stupidchicken.com> writes:
>> I set my background by customizing the `default' (and _also_ via
>> .Xresource, since otherwise emacs flashes and goes crazy during
>> startup).  The custom-theme stuff doesn't seem to be able to cope with
>> that.
>
> Ah, yes.  This is due to a design decision in the Custom Themes code: it
> deliberately ensures that the user's own customizations override
> anything set by a theme, which in term overrides changes set outside
> Customize.  (All settings should be reversible.)
>
> The idea is that you should be able to load a theme, and then change
> individual settings to you disagree with.  This seems like a reasonable
> thing to want, though it's true that it could lead to confusion.

That might be a good policy if everybody started out using themes, chose
a theme they liked, and then made a few tweaks on top of it -- but I
think that may not reflect reality very well... a fair number of people
may be like me, and have a large number of tweaked faces already in
place when they hear about themes.  They'll try out themes, notice they
all seem a bit off, and might even abandon the concept...

> Maybe the Customize Themes buffer should display a warning about this.

I guess, though a warning doesn't seem all that useful -- what should a
user _do_ when he sees it?  Go through all his customizations and turn
them off one by one?

Maybe a "convert all my settings to a theme" function would be useful --
it could prompt for a name, and create a  theme with all the user's
default settings; then it remove them as "overriding" settings.  Then a
user could easily switch between his "original" settings, and various
themes.

On top of that, a function/mode/whatever that made it very simple to
copy individual faces from themes to/from other themes or the
"non-theme" settings.

Maybe even in "one-theme-at-a-time" mode, there could be a distinguished
"override" theme that would represent overriding non-theme settings?

I dunno...

-Miles

-- 
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: themes
  2010-10-13 17:05       ` themes Miles Bader
@ 2010-10-13 21:20         ` Frank Schmitt
  2010-10-17  0:07         ` themes Chong Yidong
  1 sibling, 0 replies; 7+ messages in thread
From: Frank Schmitt @ 2010-10-13 21:20 UTC (permalink / raw)
  To: emacs-devel

Miles Bader <miles@gnu.org> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> Ah, yes.  This is due to a design decision in the Custom Themes code: it
>> deliberately ensures that the user's own customizations override
>> anything set by a theme, which in term overrides changes set outside
>> Customize.  (All settings should be reversible.)
>>
>> The idea is that you should be able to load a theme, and then change
>> individual settings to you disagree with.  This seems like a reasonable
>> thing to want, though it's true that it could lead to confusion.
>
> That might be a good policy if everybody started out using themes, chose
> a theme they liked, and then made a few tweaks on top of it -- but I
> think that may not reflect reality very well... a fair number of people
> may be like me, and have a large number of tweaked faces already in
> place when they hear about themes.  They'll try out themes, notice they
> all seem a bit off, and might even abandon the concept...

Definitely. I might have custom faces matching a blue background but
those will look totally odd on e.g. a white one.

-- 
Have you ever considered how much text can fit in eighty columns?  Given that a
signature typically contains up to four lines of text, this space allows you to
attach a tremendous amount of valuable information to your messages.  Seize the
opportunity and don't waste your signature on bullshit that nobody cares about.




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: themes
  2010-10-13 17:05       ` themes Miles Bader
  2010-10-13 21:20         ` themes Frank Schmitt
@ 2010-10-17  0:07         ` Chong Yidong
  1 sibling, 0 replies; 7+ messages in thread
From: Chong Yidong @ 2010-10-17  0:07 UTC (permalink / raw)
  To: Miles Bader; +Cc: emacs-devel

Miles Bader <miles@gnu.org> writes:

> Maybe a "convert all my settings to a theme" function would be useful --
> it could prompt for a name, and create a  theme with all the user's
> default settings; then it remove them as "overriding" settings.  Then a
> user could easily switch between his "original" settings, and various
> themes.

I've added such a facility.  If you do M-x customize-themes when
customizations are present, it displays a warning and a link to migrate
your customizations into a theme.  Could you test it out, and let me
know what you think.

The interface is a little more complicated than I like.  If anyone has
suggestions, they're very welcome.



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2010-10-17  0:07 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-10-13  3:35 themes Miles Bader
2010-10-13  5:57 ` themes Chong Yidong
2010-10-13  6:36   ` themes Miles Bader
2010-10-13 16:01     ` themes Chong Yidong
2010-10-13 17:05       ` themes Miles Bader
2010-10-13 21:20         ` themes Frank Schmitt
2010-10-17  0:07         ` themes Chong Yidong

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).