[Top][All Lists]

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

Re: New version of the Leuven theme (for Emacs 24.4)

From: Dmitry Gutov
Subject: Re: New version of the Leuven theme (for Emacs 24.4)
Date: Fri, 24 May 2013 17:38:53 +0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6

On 24.05.2013 12:24, Fabrice Niessen wrote:
You can always do it, yes. The sooner it's committed, the less "bad reactions"
I'll get...

I'm committing it now, then, and also CCing emacs-devel, maybe we'll get some more feedback.

I'm not entirely sure yet how I feel about orange foreground in strings (it
could be too bright), but I'm coming around.

I could imagine darkening it very slightly, but I think I want it to stay
(more or less) like it is now. And I really like the overall changes I made on
font-lock faces.

I've tried the commented out color near string face (D0372D), and it's definitely easier to read. I think I prefer it.

Alas, when you apply it, not everything's perfect.
font-lock-keyword-face comes strongly ahead as the brightest face. Maybe make it a bit darker blue?

2) `show-paren-match' and `show-paren-mismatch' should be swapped, showing
errors in red is more natural.

Right. Not swapped, but improved (IMHO). See inline patch below.

You're right, that purple wouldn't have been the best choice. The new show-paren-match is better, but it's fairly close in colors to the string literals. Maybe do something about that?

3) `font-lock-type-face' with grey foreground is too bland. Ruby and Python
modes use this face for class constants, and this way they're much less
noticeable (see the screenshot).

I agree it was a bit too light. I've darkened it, not too much though, so that
it still stands out from black and the other faces.

Still too grey for my taste. More importantly, other themes emphasize that face with color, to make it stand out. Here it's more subdued, fading more into the background.

4) Different faces in the email header still make it look uglier than it could
be, see the second screenshot. I still believe that themes should not specify
font family anywhere.

I don't really specify an accurate font family, just the generic "Sans Serif".

It still overwrites the font I've chosen, spending some time and effort.

The problem is that these headers tend to become very long, and I dislike the
overwrap on such lines. When in "sans serif", they normally stay on one line.

I see. Well, it's never been a problem for me, because Gnus likes to take over the whole frame when it's launched.

Anyway, I'm not against testing one proposition of yours, if you want to try
to convince me ;-)

Why don't you move the face family customizations to your init file, or maybe even some auxiliary package?

On one hand, it's a fairly specific setting, on the other hand, it could be used with other themes.

Here the changes I made today, following (most, if not all) your comments.

Thanks, but unlike some of the Emacs committers, I'm more comfortable obtaining the latest version from Git. Now that I found your repo, I see that it's one commit ahead of the patch (so I've installed the newer version).

Now, here's another issue (straight from the OCD department): the line-width customizations stop the lines from lining up. :) Screenshot attached. I have my frame height picked so that all visual lines are always displayed in full, and here we see that even lines from adjacent windows don't line up, so picking correct frame height is impossible.

Speaking of heights, I've just noticed that you customize Org faces heavily, including the heights. It makes an org buffer look like something from a rich editor, which IMO goes against the point ("it's all text!"). I don't use Org much, though; I could be in the minority.

To sum up, I like most of the colors, but dislike messing with dimensions. Maybe add some customization variables? At least two boolean ones, one for faces and another for line-widths and heights.


Attachment: leuven-line-heights.png
Description: PNG image

reply via email to

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