emacs-devel
[Top][All Lists]
Advanced

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

Re: solarized


From: Arthur Miller
Subject: Re: solarized
Date: Thu, 17 Sep 2020 16:55:01 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Protesilaos Stavrou <info@protesilaos.com> writes:


>> If those are not enough for some extreme case, user can always do what
>> they do now, specify rgb value directly; but for *most* part, hopefully
>> 16 colors would be enough. Nobody said it has to be enough for
>> *everybody everywhere*.
>
> That is always an option.  My impression, however, is that we are
> thinking about how to improve upon the state of affairs.  One such way
> is to offer more complete face/colour coverage for everyone (and they
> can still configure it afterwards).  To that I also add the
> accessibility angle.  Perhaps I misunderstood the intent of this
> discussion, so please accept my apologies.
No need to apologize, I tottaly understand you; I am not trying to be
hars or personal either. I am just trying to say that it is probably
impossible to aim to give a solution that will always work for everyone.
I think it is usually good enough to give a solution that work for the
most of people most of the time.

Another solution, instead of solarized way of thinking (base & accented
colors), would be to give an array such as base16 theme generator does
(linked in some other mail in the discussion), and guide users to think
in terms of: use "upper part" of colors for base elements (gui
background, fg, etc), use lower part for accent colors in order of
importance (just as an idea). The array could be as much as 256 if
number of colors is needed, but I still think 16~32 would do :-).

The most important part is not number of colors, but framework so
everyone, Emacs internals as well as third party packages use same
parametrized names for colors (or faces as corrected by Thomas).


> These are all interesting and fecund.  A good design must avoid
> exaggerations, rainbow effects, and design for its own sake.
>
> This, however, is an indictment against poorly implemented themes,
> though not extended colour palettes as such.  Your attached screenshot
> uses what looks like ~14 colours.
Indeed! For the 99% of 3rd party packages (might be an exaggaration
:-)), default foreground color is probably what they should use but
programmers believe they have to color code every property differently
and we get things to look as they do.

Maybe some of such design issues can be avoided if there was a
framework and user guide telling people something in line:

Use base-1~base-N for the colors of main elements (mostly theme creators
would care about those); use accent-1 ~ accent-N if you wish your text
to stand out in the GUI. Then give them a limited number of colors to
use and they might use color coding more sparingly. If the given amount
of colors is not enough they can always go into rgb valley and pick
some, but probably less will do so then what they do now. (I have no
scientific proof, just my opinion :-)).



reply via email to

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