RE: [External] : Re: Why has the light blue theme been made obsolete?

[Drew Adams]

> > > I'm even surprised that anyone noticed (came
> > > across) this deprecation.  Very surprised.
> 
> I came across it now. And I was user of light blue theme
> for long time, though I use various default themes.
> 
> I understand the theme is obsolete from 29.1 and when
> looking into source it appears you are author Drew.
> 
> Is it intended that after the selection of obsolete theme
> the theme disappears from the list of themes? That is
> exactly what happened here on my side. It is still in sources.
> 
> Cannot you, instead of making it obsolete, improve
> the theme so that it remains as one of defaults for future?

FWIW -

1. I have no intention of "improving" the theme,
   especially along the lines of what some (not
   I) might think is improvement.

   "Les goûts et les couleurs ne se discutent pas."

   (Culture and even geography can play a role
   in what appears to one person as dull or too
   noisy can appear to another as balanced or
   fresh.  A winter landscape far from the
   equator presents a different palette from
   one near the equator.)

2. Anyone is free to take the light-blue theme
   and run with it - "improve" it any way they
   see fit.  Or not.  It's free software.

3. I don't use any themes, myself.  My personal
   setup does use something similar to the frame
   parameters of the light-blue theme, for most
   frames.  But see #7, below.

4. I offered the light-blue theme to Emacs as
   one color-scheme possibility.  I think it
   offers possibilities of good color contrast
   - as opposed to value contrast, which is
   what's important for accessibility.  (But I
   think it generally offers good value
   contrast also.)

   In particular, the background is light, but
   it's dark enough that some light colors are
   usable against it.  I think a wide range of
   colors, with different values (light-dark),
   can be used effectively with it.  That's
   maybe not true of a lot of themes (dunno).

   Of course, just because you _can_ use a wide
   range of colors with such a background
   doesn't mean you need to or you should.

5. I have in mind that _legibility_ of text is
   NOT the only criterion of interest (at least
   for someone who doesn't have particular
   visual accessibility difficulties).

   Text that you need to _read_ or study needs
   to have high contrast - that's for sure.
   No disagreement about that.

   And that applies to the details of _code_
   you need to study and work with closely.
   Such a need for legibility and study doesn't
   apply to keywords such as `defun' etc., IMO.
   Those are essentially labels.

   Some such, e.g. `error', are things to
   notice - you want them to stand out.  But
   their legibility isn't very important.  And
   other such labels are neither important to
   read nor important to stand out.

   Text that you need only to recognize or
   notice does NOT need to have high value
   contrast, and sometimes _color_ contrast, not
   just value contrast, can be important for
   making such text stand out.

   This should be obvious from our world:
   product packaging, advertising, magazines,
   etc.  Think "bling", if you must.  It's
   there for a reason.

   There's no hesitation to use different
   colors together that might nevertheless have
   similar, even the same, values (i.e., little
   or no value contrast).

   I haven't tried to research what's known
   about this; I've just assumed it.  The world
   around me proclaims that it's true.  (But
   shouts and appearances can deceive, which is
   why we have science - put it to the test.)

   But again, this takes nothing away from the
   truth that for _reading_, and perhaps even
   for spending long hours staring at a screen,
   it's likely that nothing beats high value
   contrast.

   (I think there were some studies long ago
   that showed that reading black text on pale
   green paper is easier on the eyes that black
   on white paper.  Of course, paper != screen.)

   I'm no expert on any of this.  I just passed
   along the parameters I use for most frames as
   a simple custom theme to Emacs.
 
6. As with everything I offer, I expect it might
   serve some as a starting point, or as food
   for thought.  If not, fine.  It was never my
   intention to provide a cut-&-dried, "complete",
   monolithic theme - one theme to rule them all.

   The criterion imposed now by Emacs Dev is
   apparently that Emacs should offer only such
   "complete" themes.  I don't see the point of
   such a strict rule, but so be it.

   On n'arrête pas le progrès. ;-)

7. Personally, as I say, I don't use _any_ theme. 
   I use a standalone minibuffer frame with
   particular frame parameters and faces; I use
   custom *Completions* and *Help* frames, with
   particular parameters; and I use particular
   parameters for frames dedicated to buffers
   with name matching `*...*'.  (That includes
   *info*.  And yes, Info is for reading, as
   well as recognizing things.  But there are
   also labels that need to stand out.)

   In other words, I use `default-frames-alist',
   `minibuffer-frame-alist', and
   `special-display-frame-alist'; and I use
   `special-display-buffer-names' together with
   functions that display *Completions* and
   *Help* frames specially (dynamic definition).

8. My general opinion about themes includes this:

   a. A theme _need not_ define lots of faces
   and variables.  And generally it's probably
   better for users if it does not do so.  (No
   one need agree.)

   That's the general nature of _color themes_:
   define only frame parameters.  (Variables
   are not even part of color themes - they
   were introduced for custom themes).

   https://www.emacswiki.org/emacs/ColorThemes

   https://www.emacswiki.org/emacs/CustomThemes

   b. A priori, there's nothing _wrong_ with a
   custom theme being all-inclusive & monolithic.
   But there's also nothing _right_ about that,
   and there' nothing wrong with it not being so.

9. The light-blue (custom) theme follows that
   minimal model of typical color themes.  It
   doesn't define variables or faces, leaving
   that up to you or to other themes you might
   want to use together with it.

   Composing themes that way is something that
   color themes did and were good at, IIRC.
   Custom themes don't, in general, play so well
   together, IIRC - they're not so additive.
   Don't protest if I'm wrong about that.  As I
   say, I don't use themes, and I'm no expert.

   (My libraries that let you browse and try out
   themes (Icicles and Do Re Mi) work equally
   well with color themes and custom themes.)