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.

[alphapapa]

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.

No, Solarized is its palette. Its own web site says so:

Solarized is a sixteen color palette (eight monotones, eight accent colors) designed for use with terminal and gui applications. It has several unique properties. I designed this colorscheme with both precise CIELAB lightness relationships and a refined set of hues based on fixed color wheel relationships. It has been tested extensively in real world use on color calibrated displays (as well as uncalibrated/intentionally miscalibrated displays) and in a variety of lighting conditions.

The generic 8-hues-8-accents formula is not Solarized, and other such themes that follow that generic pattern are not Solarized and do not belong in solarized-emacs.

[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]

The generic 8-hues-8-accents formula is not Solarized, and other such themes that follow that generic pattern are not Solarized and do not belong in solarized-emacs.

No, but they are compatible with a Solarized theme if the colors have reasonably similar properties. They are also subsets and modified to fit this theme.

I have maybe spent several hundred hours adding and tweaking faces for this theme, I probably know more than anyone else about how well fitted it is for various palettes.

[alphapapa]

The generic 8-hues-8-accents formula is not Solarized, and other such themes that follow that generic pattern are not Solarized and do not belong in solarized-emacs.

No, but they are compatible with a Solarized theme if the colors have reasonably similar properties. They are also subsets and modified to fit this theme.

No, those are not Solarized, so they shouldn't be called Solarized.

I have maybe spent several hundred hours adding and tweaking faces for this theme, I probably know more than anyone else about how well fitted it is for various palettes.

Please respond to the points I have made. If you want to create variations on Solarized, wonderful, I might be interested in using them myself. If you want to make a theme-defining library, wonderful, I'll probably use it myself. But please do those in the appropriate place, not by commandeering this package.

[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 haven't answered any points that @conao3 or I have raised. You've simply ignored and dismissed our objections.

One of the things I, and many other users, value most about Emacs and its packages is stability. You and/or @conao3 have already broken my config with your recent change to the solarized-with-color-variables macro's signature. Now you're proposing to essentially remake the package from scratch into a theme-defining library which happens to include some Solarized themes, only some of which are actually Solarized themes.

Move fast and break things is not a motto that this project should follow. There's already enough of that in the software world.

I guess I should fork the project and reset HEAD to https://github.com/bbatsov/solarized-emacs/commit/55cd77b61b6968048c61e13358ba487d217f24c0. I'll rename it to ya-solarized or something like that.

[thomasf]

Now you're proposing to essentially remake the package from scratch into a theme-defining library which happens to include.

No, I wrote clearly that we should list wishes, wishes are not the same thing as requirements. I have updated the issue text to reflect this even more clearly now.

Move fast and break things is not a motto that this project should follow. There's already enough of that in the software world.

Exactly, I saw that happen and as a consequence I created this issue to collect ideas and and break it once instead of incrementally fixing things and breaking it multiple times.

Going to a breaking 2.0 after around 10 years is not moving fast and breaking things.

I guess I should fork the project and reset HEAD to 55cd77b. I'll rename it to ya-solarized or something like that.

If you think that that is less work than changing one argument to a function call in your own code (or whatever the breakage was) I wish you good luck. I have already spent around 30hrs since this weekend on core theme concerns, mostly picking out the diff/refine blends.

[alphapapa]

This is the problem:

(or whatever the breakage was)

You don't seem to care about, to use Linus's words, "breaking userspace." You want to do big things--that's wonderful, there are many improvements to be made. The problem is that you want to do them by breaking things here instead of in your own projects. That's not cool.

[thomasf]

This is the problem:

(or whatever the breakage was)

You don't seem to care about, to use Linus's words, "breaking userspace." You want to do big things--that's wonderful, there are many improvements to be made. The problem is that you want to do them by breaking things here instead of in your own projects. That's not cool.

I just forgot exactly what the breaking issue was. You do know it wasn't me who broke it, right?

We can extend that line of reasoning in absurdum as well if you like, every change of theming a face could be a breaking change for someone because in the end it's about taste as well as usability.

Now it just seems like you are after drama, you are cutting out one small part of my statement that included a very clear message about not wanting to break stuff to complain that I am breaking stuff.

Also, this is not the Linux kernel, we don't have millions of lines of code and billions of users. 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.

[conao3]

I was mentioned. @alphapapa, you can't pursue its selfishness just because solarized internal function broke. I know that this is a violation of manners, but it is a bad joke that you are a member of helm and insist on it. Any Emacs user knows that helm does destruction and creation.

And I have repeatedly insisted that users can only use theme files and undocumented solarized-create-theme, all others are internal functions. I admit that the naming is wrong, but it is not desirable to rely heavily on internal functions just because Elisp functions are defined globally.

Also, I don't think it's a better choice to keep things broken as you wrote in the comment. https://github.com/alphapapa/prism.el/blob/49c8b97b286c7403bf239645964416200ea82dd5/prism.el#L774-L778

[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.

[alphapapa]

I was mentioned. @alphapapa, you can't pursue its selfishness just because solarized internal function broke. I know that this is a violation of manners, but it is a bad joke that you are a member of helm and insist on it. Any Emacs user knows that helm does destruction and creation.

Before you blame me for breakage in Helm repositories, you should look at the commits I have actually made to Helm repos, which are very few and haven't broken anything, as well as discussions I've participated in, in which I have argued against breaking changes and gotten them reverted. I am consistent in this philosophy, and it's wrong of you to accuse me otherwise.

And I have repeatedly insisted that users can only use theme files and undocumented solarized-create-theme, all others are internal functions. I admit that the naming is wrong, but it is not desirable to rely heavily on internal functions just because Elisp functions are defined globally.

As you know, private/internal functions are merely a convention, as Emacs is in fact a Lisp system image. Users use code that is available. It's often poor stewardship to fall back on "that was a private function, you shouldn't have used it" to excuse breakage. It is, of course, a matter of judgment in each case.

Also, I don't think it's a better choice to keep things broken as you wrote in the comment. https://github.com/alphapapa/prism.el/blob/49c8b97b286c7403bf239645964416200ea82dd5/prism.el#L774-L778

I don't think you understand that code or that comment. If you wish to talk about it, you may comment on that repo, which its readme says is in "Early prototype stages."

In any case, it's bizarre for you to dig through my code in other, unrelated projects for something you think is ugly and try to use it as an insult here. I've never seen anyone do such a thing. I point out breakage you caused in this project, which you may or may not have thought was justified, which is a matter of judgment, and you respond by making false accusations of me about other projects?

Rest assured, you've certainly dissuaded me from participating further here.

[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

[conao3]

?? @alphapapa, you mentioned prism.el at first at https://github.com/bbatsov/solarized-emacs/pull/330#discussion_r342851332 . So I read the code and found the comment.

It is a nice situation to have maintainers moving their hands. If there are no maintainers to move the hand, the package will be devastated and no one can use it. If you want to rely on broken solarized at some point, you should use Cask to specify the dependent commit and clean up the dependencies. Mentioning helm is my bad joke. I am sorry.

[alphapapa]

?? @alphapapa, you mentioned prism.el at first at #330 (comment) . So I read the code and found the comment.

Then, as I said, I don't think you understand the code or the comment--or, I don't understand what point you're trying to make about it.

It is a nice situation to have maintainers moving their hands. If there are no maintainers to move the hand, the package will be devastated and no one can use it.

Sure.

If you want to rely on broken solarized at some point, you should use Cask to specify the dependent commit and clean up the dependencies.

This package is not broken. I'm asking that it not be broken from users' perspectives.

Mentioning helm is my bad joke. I am sorry.

Ok, thanks.

[conao3]

Maintaining code that the maintainer cannot maintain, even if it wasn't broken from the user's point of view, is not a good choice.

If you're a programmer, don't give such a low opinion. If it breaks temporarily from the user's point of view, changing it to a code that can be maintained is beneficial in the long run. You can't miss this advantage.

[alphapapa]

Yes, that's what programmers always say to justify rewriting working code. And the users are always the ones who pay the price. ;)

Sometimes it is actually justified.

In this case, the question seems to be about supporting additional, non-Solarized themes in this solarized-emacs package which already works. So is it really justified to rewrite everything?

Instead, how about making a new project called thomasf-conao3-solarizy-themes that does all the things better?

[conao3]

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.

My opinion. This formula is wrong. Only a few use internal functions like solarized-with-color-variables, and most users use solarized-theme via load-theme. We (@thomasf and me) have no intention of changing this usage or behavior. The impact related change is minimal or nothing.

[thomasf]

In this case, the question seems to be about supporting additional, non-Solarized themes in this solarized-emacs package which already works. So is it really justified to rewrite everything?

That is not the reason (hint: we already have support for that) I don't understand why you still say things like that after I repeatedly have explained and clarified the opposite

[alphapapa]

That is not the reason (hint: we already have that) , I don't understand why you still say things like that after I repeatedly have explained and clarified the opposite

Is this really hinging on the question of what qualifies as a "Solarized" theme?

[thomasf]

No. Even if the other palettes and their -theme.el files were removed exactly the same things would be needed. This recent multiple palette support just made it possible for me to start work on having one palette for Solarized dark and one for light in an convenient way. I have wanted it for some years now to be able to easily add full light/dark precalculated palettes to be able to achieve better mode specific blending. This work also just happened to create the possibility of adding in other palettes as well.

All this code was written to generate solarized colors, as a "bonus" it was very easy to create more "Solarized" using other colors but that was never the primary intention. Having more palettes in there has proven to be valuable when evaluating the color values because I can switch between the solarized's and other ones to get a better understanding what works and why.

https://github.com/bbatsov/solarized-emacs/blob/master/colorlab/main.go#L737

[alphapapa]

You're writing code in Go to generate a theme in Elisp? And you say you're not needlessly rewriting working code?

Again, it belongs in its own package, I say. But you've clearly made up your mind to do your experimentation here--in master, no less! :(

[thomasf]

It is not a part of the package, the resulting color alist is. I wrote it in Go becasue color.el doesn't have remotely near the feature that among others some Go packages have. I might port needed features to move color generation back into elisp later. I wrote it in Go specifically to avoid having to first write a color library first.

Maybe you are also interested to know that I also have written javascript to generate colors for this theme earlier for the same reasons. https://github.com/thomasf/solarized-work

Neither of these tools are anything that comes packaged with the theme but I did have problem just to day trying to find the right repository and revision used tog greate the -l and -d accent color versions. I didn't find them but I approximated them here now in the go code so they will at least exist in the same repository at the same point in time as they were created which might be relevant later on.

              pal.Accents.
			ChangeSaturation(0.2).
			Blend(pal.Base03, .2).
			ChangeLightness(-.1).
			NamedColors().
			WithSuffix("-d"),

		pal.Accents.
			ChangeSaturation(0.2).
			Blend(pal.Base2, .2).
			ChangeLightness(.05).
			NamedColors().
			WithSuffix("-l"),

The problem I am trying to solve it to understand if these colors even have a real place or not anymore .