The elflord remake looks very different from the original

[GergelyKalmar]

I really like the idea of modernizing the 20+ year old color schemes, in particular, adding support for newer Vim features, however, the new elflord remake looks so different from how the original looked that it should probably be just a separate color scheme. Here is an example of how the legacy elflord renders in Gnome Terminal with a green on black theme:

Here is how it looks with the new elflord scheme:

I would love having a remake that works more like the original (which followed the terminal theme for the default text color and did not interfere with the Terminal background transparency either). It feels like a major backwards incompatible change, and while it's great that there is a way to get the "legacy" color schemes back, I think some may have been retired prematurely.

[romainl]

When we started our work on the legacy colorschemes, the biggest challenge we faced was that all of them where actually very badly designed. Lack of consistency was the most common problem and elflord happened to be one of the worst, if not the worst in that respect. For example, here is how elflord handles the Statement highlight group:

hi Statement term=bold      ctermfg=Yellow gui=bold guifg=#aa4444

For reference, this is how #aa4444 looks:

and this is how Yellow looks in the default xterm palette:

and, of course, Yellow can look like anything depending on the user's terminal palette. Hell, it may even have been set to #aa4444 in the author's palette, which would actually make elflord quite consistent, for some meaning of "consistent". Who knows?

The general approach when designing colorschemes is to start with the highest definition (GUI, millions of colors) and work your way to the lowest acceptable definition, which can vary from project to project. In web development circles, it is called "graceful degradation". That is also the approach we chose for the remakes: we started from the highest definition information available and tried as best as we can to stay close to it in lesser environment. Loss and deviation are sadly unavoidable in that context but I think we did a pretty good job over all.

After the initial facepalm, we approached elflord like we approached all the others:

• when a guibg or guifg value is available, use it as-is for GUI,
• use its closest approximation for 256c,
• use a generic approximation based on the hue and darkness for 16c,
• use a generic approximation based on the hue for 8c,
• etc.

We didn't do it the other way around, from lesser environment to better environments, because how a given color looks in 8c or 16c is intrinsically tied to the user's terminal palette. Yellow can mean #cdcd00 with the default xterm palette or #b58900 with Solarized, etc. How can we infer a "correct" guifg value if the initial information, Yellow, is essentially meaningless? Thankfully, the author gave us #aa4444, whose precision and explicitness make for a more reasonable and dependable starting point.

We also didn't follow the original's "system" because it was inconsistent and inconsistency is what we were set out to fix.

In the case of Statement in elflord, this is what we came up with:

• (GUI) guifg=#aa4444
• (256c) ctermfg=131
• (16c and 8c) ctermfg=darkred

Basically, we favored a) consistency across environments over fidelity with the original, and b) fidelity with the GUI over fidelity with the TUI. To that end, we based on our choices on what we could make of the author's intent: from the GUI colors when available.

The net result is a vastly improved experience across environments (from left to right: 16c, 256c, GUI):

at the expense of fidelity with the original, which looked different for everyone to begin with.

For comparison, this is a screenshot of the original elflord in GUI on the left and the remake in GUI on the right:

All that to say that it will be very hard to convince us of the necessity to make elflord broken again. But feel free to unfix it as you which. I guess you can use the template in this repo as a starting point, or follow the instructions under :help colorscheme-override.

[GergelyKalmar]

That all sounds very reasonable. However, it does not change the fact that this theme has changed quite drastically for probably most terminal users (unless they indeed had weird color mappings).

Note that having a terminal version that is less forceful about colors was a feature, not a bug, to me. The previous elflord scheme was very careful about colors, and it picked up the main color theme of my terminal very nicely, which resulted in a very consistent experience when considering the entire experience of working in the terminal. While I understand that the new theme looks more consistent in isolation, it is now practically impossible to find a color scheme that is consistent with even the simplest terminal color schemes.

It must also be said that using GUI Vim is probably very different from using Vim in the terminal, therefore I'm still not sure that throwing away the terminal color schemes completely was a wise decision.

[lifepillar]

it is now practically impossible to find a color scheme that is consistent with even the simplest terminal color schemes.

The old color schemes were mostly “chameleon” color schemes: although you describe that as a feature, other people (myself included) would find that unintuitive, and often annoying because that “feature” might result in unreadable text with a change of environment (try using Elford when your terminal uses Solarized Light…).

It is basically impossible to design a color scheme by describing that the text should use color “zero”, comments color “nine’, and error messages color “one”, where “zero”, “nine”, and “one” can be literally anything. How do you even address a user wanting more contrast or a different color for comments when you have no idea how that user's version of the color scheme looks like, and, most importantly, without breaking the other zillions versions of the remaining users?

The path that was taken—namely, let the color schemes have a consistent appearance within the limitations of the 256 color palettes, and freeze the legacy color schemes—was the only sensible thing to do.

And I've said frozen: the old color schemes were not “thrown away completely”. You may grab the legacy elford from this repo and put it your Vim folder. The legacy colors are even available as a plugin.

[lifepillar]

Yet another option to try:

:set t_Co=16
:colorscheme elford

Where, in this case, you'd be using the new elford that comes with Vim.

[GergelyKalmar]

It is basically impossible to design a color scheme by describing that the text should use color “zero”, comments color “nine’, and error messages color “one”, where “zero”, “nine”, and “one” can be literally anything. How do you even address a user wanting more contrast or a different color for comments when you have no idea how that user's version of the color scheme looks like, and, most importantly, without breaking the other zillions versions of the remaining users?

It clearly isn't impossible to design such a color scheme, someone has already done it in the past :). Perhaps they had different requirements in mind, but surely their design has some usefulness to it too. To respond to your question: if the user wants more contrast in a "chameleon" scheme, they can just adapt their terminal color scheme, and suddenly they solved their contrast problems for all well-behaving apps in the terminal. It is a very useful feature!

I don't mind either way, although I would have loved if the "chameleon" terminal version of the theme was maintained as part of Vim proper (perhaps with a different name). Sure, I can download the old color files from anywhere, but if there is all this effort in improving Vim's color schemes, I thought perhaps we can think about and design for the use cases that chameleon schemes solve, too.

[romainl]

It clearly isn't impossible to design such a color scheme, someone has already done it in the past :).

All the built-in colorschemes, including default, are "chameleons" if you have a 16-colors or 8-colors $TERM. We didn't change that at all because it simply can't be changed.

From a designer perspective, the main challenge posed by those environments is not the limited palette but the fact that there is no way to control that palette from within Vim.

In the richest environments (GUI and in "true colors" terminals), the designer can reasonably assume that the specific "dark red" that he wants for Statement will look the same for everyone.

In more limited environments (say 256-colors terminals), the designer can still pick an actual "dark red" and, again, be reasonably confident in the outcome, but it may not necessarily be exactly the same as the one he would have chosen for the GUI.

In even more limited environments (16colors/8-colors terminals), all the designer can hope is that the color attributed to 1 or darkred by the user in his terminal's palette is in fact some kind of "dark red". When working within those constraints, there are two possible strategies:

• design against a vaguely standard-ish palette and hope that your user's terminal palettes don't deviate too much from it,
• design against your own terminal palette and accept the fact that your colorscheme may only be usable by yourself and, eventually, by the lucky few who use a somewhat compatible terminal palette.

The original author of Elflord clearly chose the latter (and he did that for a few other legacy colorschemes)… and you are one of the lucky few for whom it worked. In our opinion, that strategy is selfish and short-sighted, and can only result in colorschemes that may work for some while being broken for most. For the remakes and the new ones, we opted for the former strategy, in combination with the "graceful degradation" I mentioned earlier, whose outcome is colorschemes that work equally well for most but may not work as well for some. This, in our opinion, is how a built-in colorscheme should work.

Regarding @lifepillar's mention of Solarized Light, here is a screenshot taken with a 16colors $TERM to illustrate the point:

• The top row is the new Elflord, with the default xterm palette, then solarized light, then my own custom palette.

  Despite the different palettes, the overall look is maintained across environments. User A's Elflord is pretty close to User B's, which is pretty close tou User C's. And, as shown in earlier comments, that consistency goes all the way to the GUI. And we achieve that by only using colors 0-15, just like the original, but in a much more deliberate way.

• The bottom row is the original Elflord, with the same palettes as above.

  The original looks pretty similar with the xterm palette and mine because they are pretty close, but it is beyond broken with Solarized Light (which is sadly still extremely popular). We simply couldn't leave it like that, could we?

  Third-party colorschemes are explicitly installed by individual users who… like them, so their authors can make all the short-sighted decisions they want. It is entirely their prerogative to write a colorscheme that looks different in GUI and in TUI and is broken outside of the author's environment. But, because they are built-in, built-in colorschemes must be designed more conservatively and with a larger viewpoint than "works for me".

  The indices are the same but the values at those indices vary from palette to palette so it is actually impossible to conclusively decide if the author's tentative yellow was actually some kind of "yellow" or, as hinted by the "dark red" used for guifg, some kind of "red"? Because we valued consistency across environments and users over fidelity with the original, we used indices closer to the GUI color in our referential palette: Statement became "dark red" everywhere and for everyone instead of "yellow" for some, "dark red" for others, or an unusable "dark blueish grey" for yet others, and so on. A win for most, a loss for a very few.

Again, we won't re-break Elflord or adjust it to one user's terminal palette.

The original is still available if you want, and you are free to do what we all end up doing at some point: write your own variation of your favorite colorscheme. If you want to take that route, the template at colortemplate/elflord.colortemplate is a good starting point because it supports all the modern features that the original didn't and is guaranteed to generate a working colorscheme. The actual stylistic changes we made to ensure internal consistency are very few so it shouldn't take too long to have your own Elflord clone. Hell, you can even ping us if you need help and submit it for inclusion (with a different name, "chameleon" sounds good) when it is ready.