Version FUTURE

[thomasf]

Are there limitations, annoyances, inconsistencies or just something that's inconvenient about the theme right now?

Most important points

• The basic functionality of just using the theme by doing M-x load-theme will never change. If you just use the theme you will not notice anything other than maybe getting more option

• V3.0 as a concept is about the possibility of breaking current usage at one point in time by planning instead of maybe breaking it more times by incremental improvements that requires some breaking change.

• By breaking change we mean things like changing a function signature. If for some reason something is truly removed we will give you a migration guide.

• At this stage I just want to hear ideas and wishes. It does not have to be fully formulated thought at this point. Remember that wishes might not lead to actual changes so don't be too hard on other peoples wishes.

• The changes will be related towards user customization options and how the theme internally constructs its various parts for increased maintainability.

Please comment here if you have any wishes of what you want to be able to do with the theme that you cant do now or if something is bothers you.

The end result of this discussion not be any new version at all, just insight.

(note: I have minimized a lot of comments because they are off topic. This issue is not for endless complaints about past decisions, it's about looking forward. I kept a little bit of the least off topic parts visible for context.)

[thomasf]

A small list of things that comes to mind right now.

To keep

Stay Solarized

I do NOT want to get away from the basic solarized "limitation" of 8 tones and 8 accent colors. This is the core values of solarized in general and this theme in particular. Even if we allow for extending the palette some times to make up for Emacs lack of blending we also have a much stricter usage of some accent colors than most other Solarized themes has.

Solarized is a 24bit color scheme

I believe that it's time to officially state that this is a 24bit theme, in practical terms this is already more or less true but we still have the oldest still open issue "Incorrect Colours in Terminal" hanging around. Almost all terminal emulators that people use will probably have 24bit support within a few years anyways.

To improve

Composability at lower levels

I want it to be possible to have snippets of face definitions and palettes that splices together a finished theme. Instead of filling the insides of the theme body with conditionals I would like to be able to compose a theme from lists, something like (create-solarized-theme :faces solarized-faces-base solarized-faces-more-italics solarized-faces-high-contrast-modeline :palettes solarized-palette-dark my-high-contrast-blue ) We are in semi constant battle with the theme system when doing things like this but maybe there is a clear way forward somewhere.

To remove

solarized-theme.el

All the themes are in the same directory as a file named solarized-theme.el, this file is picked up by load-theme but fails to load. That file should probably not exist.

accent colors with -l -d -hc -lc suffixes

The usage of these are note well defined and were intended to be used both with a light and dark solarized theme. That was proven to not really work and now they just live in a unknown space. I have begun a project to either get rid of the internal usage or clearly define their purpose. Even if the theme itself stops using them they should be kept around if someone else is referencing them.

[conao3]

Solarized-theme should offer only solarized-dark and solarized-light. The ability to create other themes is a minor thing.
Also, those who use the extras are highly familiar with solarized internals, and specifically no one will enable the bundled solarized-wombat-dark-theme.

Downloading wasted code from MELPA and byte-compiling is a waste of computer resources.
In Version 2.0, please remove the following files from the package and only give me what I need.

• solarized-gruvbox-dark-theme.el
• solarized-gruvbox-light-theme.el
• solarized-wombat-dark-theme.el
• solarized-zenburn-theme.el
• solarized-light-high-contrast-theme.el
• solarized-dark-high-contrast-theme.el

(user can use high-contrast theme with some options for solarize-theme?)
Or, if you want a different bundle theme like doom-theme, you will be welcomed to create a new package with a package name like solarized-misc-themes and place the file there.

[thomasf]

Solarized-theme should offer only solarized-dark and solarized-light. The ability to create other themes is a minor thing.

While I respect your opinion that not everything needs to be included in one package I would like to point out that it's still the same theme, just with different palettes. All the work that has gone into theming using the Solarized palette is reusable with other palettes as long as they are able to fit within the 8 tones 8 accents formula.

I'm pretty sure that more computer resources will be consumed by separating into multiple packages but that's hardly relevant.

[conao3]

I would like to point out that it's still the same theme, just with different palettes.

So you should not bundle those files. How to use it is to write in README. If you want to prepare a concrete example, you should place the file in another directory that is not packaged by MELPA.
Anyway, my opinion is over because you want to ask for opinions widely in this thread.

[alphapapa]

A small list of things that comes to mind right now.

1. All the themes are in the same directory as a file named solarized-theme.el, this file is picked up by load-theme but fails to load. That file should probably not exist.
2. I believe that it's time to officially state that this is a 24bit theme, in practical terms this is already more or less true but we still have the oldest still open issue "Incorrect Colours in Terminal"
3. I want it to be possible to have snippets of face definitions and palettes that splices together a finished theme. Instead of filling the insides of the theme body with conditionals I would like to be able to compose a theme from lists, something like (create-solarized-theme :faces solarized-faces-base solarized-faces-more-italics solarized-faces-high-contrast-modeline :palettes solarized-palette-dark my-high-contrast-blue ) We are in semi constant battle with the theme system when doing things like this but maybe there is a clear way forward somewhere.
4. I do NOT want to get away from the basic solarized "limitation" of the 8 tones and 8 accent colors. This is the core values of solarized even if we allow for extending the palette some times to make up for Emacs lack of blending support.

Those are some very interesting ideas regarding making themes easier to define. A library to define Emacs themes more easily could be very helpful.

But please do those in a separate project which is dedicated to defining Emacs themes in a flexible, powerful way. This project and repo is for Solarized themes, and it should not be repurposed into a general-purpose theme framework.

After you're created such a project and it has become mature, this repo and its Solarized themes could be converted to use that framework.

[thomasf]

But please do those in a separate project which is dedicated to defining Emacs themes in a flexible, powerful way. This project and repo is for Solarized themes, and it should not be repurposed into a general-purpose theme framework.

I haven't created anything yet, these are just ideas and/or wishes for now. Please add your own if you have any. I have no idea what this issue will lead to.

[alphapapa]

I have no idea what this issue will lead to.

Then that is the first problem to be solved: to answer the question, What is the purpose of the solarized-emacs package?

AFAIK it is to provide Solarized themes for Emacs. I think that should continue to be its purpose. If you want to write a theme library, wonderful, that would be very helpful to theme authors. Please do so in the appropriate place, and maybe these Solarized themes can use it someday.

@bbatsov May I ask, are you still running this project? If so, it seems necessary now to define its purpose before it may be reconfigured into a theme-definition framework which happens to include some Solarized themes. If that is going to happen, it may be necessary to fork the project to preserve its usefulness as-is.

[thomasf]

Then that is the first problem to be solved: to answer the question, What is the purpose of the solarized-emacs package?

The primary goal will always continue be that M-x load-theme solarized-dark/light will give you the best possible experience regardless of how the underlying code is organized. Palettes other than Solarized will never have influence over theming decisions , they are complementary.

[thomasf]

I do not expect non-solarized-palette Emacs themes existing in this repository to contain more than a list of color codes (a palette) and maybe in rare exceptions a handful of face adjustments for very basic faces.

[alphapapa]

You merged the PR that broke the macro's signature. As a maintainer, it's your job to consider such breakage and avoid it when possible.

What I'm after is serving users' interests. Maintaining a widely used package is a matter of stewardship, which often means putting the users' interests before the maintainer's interests, sometimes at the expense of the maintainer's fun.

Of course, you could easily make a new repo and do the fun stuff there. Make your new thing, make it amazing, and then use it as a dependency here, when it's mature. But you seem unwilling to consider doing that for some reason.

If we break something, even restructure all of the code people will still probably be able to adapt their customization in less than 5 minutes.

5 minutes * 10,000 users = 34 man-days of time. That's disrespectful of users unless the benefits are really worth it.

Well, it's your project, so I'll leave you to it. I do appreciate your work on it, I just wish you'd do it separately, without breaking things.

[thomasf]

Of course, you could easily make a new repo and do the fun stuff there. Make your new thing, make it amazing, and then use it as a dependency here, when it's mature. But you seem unwilling to consider doing that for some reason.

Again, I am not ruling out anything at this point. I primarily want to know what people wishes . The low level theme construction stuff is absolutely to make the theme itself better. It doesn't have to be much more code than it is right now. As long that it is the right code it can probably be quire short but that's details about something that just exists as a wish right now. I do not have a clearly formulated picture in my head how it would work either.

Right now it's very cumbersome to give users more choices by means of defcustoms of a theme because of the (if (eq variant 'light..) and stuff spread out all over the several thousand lines long list of faces. There is a clear limit on how many customisations even can be added before it gets too hard to follow and test the permutations when working on faces. If these were broken out to some kind of composable units we can give users much more options.

As long as they are distinct entities we can have 8 different mode line looks and feels, right now a single defcustom causes this mess.

  (s-mode-line-fg (if solarized-high-contrast-mode-line
                              base03 base0))
          (s-mode-line-bg (if solarized-high-contrast-mode-line
                              base0 base02))
          (s-mode-line-underline (if solarized-high-contrast-mode-line
                                     nil s-line))

          (s-mode-line-buffer-id-fg (if solarized-high-contrast-mode-line
                                        'unspecified base1))
          (s-mode-line-inactive-fg (if solarized-high-contrast-mode-line
                                       base0 base01))
          (s-mode-line-inactive-bg (if solarized-high-contrast-mode-line
                                       base02 base03))
          (s-mode-line-inactive-bc (if solarized-high-contrast-mode-line
                                       base02 base02))

... somewhere else ...

    `(mode-line
         ((,class (:inverse-video unspecified
                                  :overline ,s-mode-line-bg
                                  :underline ,s-mode-line-underline
                                  :foreground ,s-mode-line-fg
                                  :background ,s-mode-line-bg
                                  :box (:line-width 1 :color ,s-mode-line-bg
                                                    :style unspecified)))))
       `(mode-line-buffer-id ((,class (:foreground ,s-mode-line-buffer-id-fg :weight bold))))
       `(mode-line-inactive
         ((,class (:inverse-video unspecified
                                  :overline ,s-mode-line-inactive-bc
                                  :underline ,s-mode-line-underline
                                  :foreground ,s-mode-line-inactive-fg
                                  :background ,s-mode-line-inactive-bg
                                  :box (:line-width 1 :color ,s-mode-line-inactive-bg
                                                    :style unspecified)))))

With composition of faces lists these could just simply be two different face definition blocks.

I have IIRC declined suggestions to make some things into defcustoms just to keep the code readable as it is constructed now, these are not problems I'm just making up. Some things can probably be retrofitted without breaking anything but others can't.

There is no requirement that a wish here has to break something

[bbatsov]

It saddens to me see such negatively charged conversations taking place here. I haven't paid much attention to solarized recently, but I understand the sentiment of too much complexity for something as simple as a colour theme. Generally it seems to me that some theme infrastructure should be decoupled from the actual theme and names like solarized-zenburn for instance are super confusing. I guess we can package together the basics in something like base-theme and potentially distribute it separately. @purcell Would you be open to having a reusable theme foundation package on MELPA?

[thomasf]

Yes, the theme name is confusing. In hindsight its obvious that I should have thought more about how to present that situation. It was intentionally done both by namespace and maybe to force people to think about what it means before choosing to use any of those alternative palette variations.

However, solarized-zenburn is not straight up zenburn based themes and it never will be. Regardless of what others have been saying they are in fact the same theme (in a more abstract sense than a file named -theme.el ). The design, color selection will always be made usng the solarized palette primarily. Other zenburn themes which have zenburn as an origin in both palette and theme will always be able to do a "more" zenburn interpretation.

Since OG zenburn doesnt have an violet it is created by blending zb blue and magenta to get it to fit into the theme so it's tilted towards solarized in more ways than one.

Just to be clear: I never argued against removing those from the solarized MELPA package either in this discussion. I only tried to explain why I made that decision regardless if it was right or wrong.

I was just considering locking this issue but I unpinned it instead for now.. It started off so badly, nowhere near my stated intentions. Too much uncalled hostility, from what I can tell no attempt was ever even made to ask if the original insuperable event of adding an extra argument to a function was a mistake/oversight or not.

This made me loose a lot of enthusiasm in general for the time being but who knows, maybe it comes back.

[bbatsov]

Don't take this personally - OSS has always had this toxic vibe attached to it. Trust me - I'm an expert. :-) Accidents do happen, mistakes get made, we shouldn't make a drama out of them, but learn how we can do things better.

However, solarized-zenburn is not straight up zenburn based themes and it never will be. Regardless of what others have been saying they are in fact the same theme (in a more abstract sense than a file named -theme.el ). The design, color selection will always be made usng the solarized palette primarily. Other zenburn themes which have zenburn as an origin in both palette and theme will always be able to do a "more" zenburn interpretation.

Fair enough. This has to be documented somewhere, though, as it's definitely not obvious. I was under the impression that much of this work was done with the intention the just reuse the list of faces known to a theme to create easily other themes with different palettes. Clearly I got this wrong. For me when I was still working actively on Solarized and Zenburn it was always annoying I had to make pretty much the same edits to both themes.

Just to be clear: I never argued against removing those from the solarized MELPA package either in this discussion. I only tried to explain why I made that decision regardless if it was right or wrong.

👍

I was just considering locking this issue but I unpinned it instead for now.. It started off so badly, nowhere near my stated intentions. Too much uncalled hostility, from what I can tell no attempt was ever even made to ask if the original insuperable event of adding an extra argument to a function was a mistake/oversight or not.

I totally get it. I also considered just locking this, as it seemed it was going nowhere, but decided to to join the convo and try to help. It certainly doesn't seem like we're dealing with some insurmountable issue. :-)

[bbatsov]

All the themes are in the same directory as a file named solarized-theme.el, this file is picked up by load-theme but fails to load. That file should probably not exist.

Agreed.

Or, if you want a different bundle theme like doom-theme, you will be welcomed to create a new package with a package name like solarized-misc-themes and place the file there.

This sounds like a reasonable solution, although we can probably come up with a better package name.

[purcell]

@purcell Would you be open to having a reusable theme foundation package on MELPA?

@bbatsov Yes, definitely.

[t-soliduslink]

I am bitten by the change to solarized-with-color-variables, too. It is not quite obvious what the right incarnation is to have it do the same that it did a week ago.

I.e. what do I have to replace

(solarized-with-color-variables 'light ...)

with in HEAD?

Thanks!

[conao3]

In short:

(solarized-with-color-variables 'light ...)

;; to

(eval `(solarized-with-color-variables 'light ,solarized-light-color-palette-alist ...))

[t-soliduslink]

Thank you!

[thomasf]

retitled this issue version FUTURE because what is going to be 2.0 is what is in master now and might be ready soonish (within a few months or so). Also adopted an semantic version and adced note about it in the readme.

[alphapapa]

FYI:

doomemacs/themes#314 (comment)
https://github.com/hlissner/emacs-doom-themer