[WIP] RFC

[romainl]

This is a draft of the message we are going to send to the mailing list regarding the remakes. What should I remove? What should I change? What should I add?

(no markdown because this is supposed to be sent to the mailing list)

---

Hello,

We started the vim/colorschemes [1] project in May 2020 in the wake of two threads about the built-in colorschemes started by Christian Brabandt [2][3].

Christian's initial push for introducing popular colorschemes was met with enthusiasm but it was pretty obvious a) that such a move couldn't happen overnight and b) that it would come with lots of challenges. For example, many popular colorschemes come with various technical requirements, expose options and, generally, require some documentation. Merging those colorschemes also means merging their documentation and adding their requirements to Vim proper. And what about popular colorschemes that are pretty much abandoned and thus don't support new Vim features? And what about the existing colorschemes?

We created vim/colorschemes in the hope that it would help move the whole question of built-in colorschemes forward, along three axes:

• modernizing the existing built-in colorschemes,
• adding new colorschemes created by members of the community,
• providing better documentation and tooling to colorscheme authors

The whole thing is still a work in progress, of course, but we are happy to announce that, thanks to the hard work of a small but motivated team, a first milestone is finally within reach: we consider the modernized versions of all the built-in colorschemes (except "default") to be in a shippable state and we would like the community to play with them and report any issue to the team.

As of now, all of the "remakes", as we call them, are usable in 0 colors, 16 colors, and 256 colors terminal emulators, as well as GUIs, with the usual caveats regarding terminal capabilities.

If you want to participate to this effort, feel free to install vim/colorschemes alongside your other plugins and use our issue tracker [4] to report problems or suggest improvements.

[1] https://github.com/vim/colorschemes [2] https://github.com/vim/vim/issues/1665 [3] https://github.com/vim/vim/issues/4996 [4] https://github.com/vim/colorschemes/issues

[habamax]

Looks good for me

[neutaaaaan]

You might want to add a few words about the colorschemes that were not properly implemented to begin with, but I'm not even sure that'd spare us from 0.5% of the flood of false positives.

Aside from that, looks good to me.

[romainl]

DRAFT #2

---

Hello,

We started the vim/colorschemes [1] project in May 2020 in the wake of two threads focusing on expanding the built-in colorschemes roster [2][3].

The initial push for introducing popular colorschemes was met with enthusiasm but it was pretty obvious a) that such a move couldn't happen overnight and b) that it would come with lots of challenges:

• many popular colorschemes need documentation and hacks,
• many popular colorschemes generate large amount of support request (linked to the previous point),
• many popular colorschemes are pretty much unmaintained anyway so they don't support new features,
• each popular colorscheme is written in a different way than the others,
• the two threads mentioned above were not the ideal place for that process,
• etc.

Additionally, adding more "modern" colorschemes to the roster would only emphasize the problems exhibited by the old guard:

• they have been unmaintained for years/decades, which means that they don't support "recent" features,
• they are very inconsistent, both internally and between themselves,
• they have all been pretty much broken in one way or another for a long time, some of them being borderline unusable outside of a (possibly) very specific context.

Looking at the situation closely, it is quite clear that the whole thing required a rethinking. We created vim/colorschemes in the hope that it would help move the whole question of built-in colorschemes forward, principally along three axes:

• modernizing the existing built-in colorschemes,
• adding new colorschemes created by members of the community,
• providing better documentation and tooling to colorscheme authors.

The project is still a work in progress, of course, but we are happy to announce that, thanks to the hard work of a small but motivated team, a first milestone is finally within reach: as of today, we (the vim/colorschemes team) consider the modernized versions of all the built-in colorschemes (except "default") to be in a shippable state and we would like the community to play with them and report any issue to the team.

As of now, all of the "remakes", as we call them, are usable in 0 colors, 16 colors, and 256 colors terminal emulators, as well as GUIs, with the usual caveats regarding terminal capabilities.

Of note:

• they are all identical in monochrome environments (&t_co == 0 for example),
• diff colors are the same for every colorscheme,
• whenever possible, the colors are derived from the original's GUI colors,
• due to the many inconsistencies plaguing the originals, we generally favored the spirit to the letter so the peachpuff remake _is not the original peachpuff; it still is "peachpuffesque" but in a much more usable way.

If you want to participate to this effort, feel free to install vim/colorschemes alongside your other plugins and use our issue tracker [4] to report problems or suggest improvements.

[1] https://github.com/vim/colorschemes [2] https://github.com/vim/vim/issues/1665 [3] https://github.com/vim/vim/issues/4996 [4] https://github.com/vim/colorschemes/issues

[neutaaaaan]

I think you should either drop the explicit reference to peachpuff, or slide "for example" somewhere in that sentence, but that's really because I feel like being pedantic.

Aside from that, looks good to me.

[romainl]

DRAFT #3

---

Hello,

We started the vim/colorschemes [1] project in May 2020 in the wake of two threads focusing on expanding the built-in colorschemes roster [2][3].

The initial push for introducing popular colorschemes was met with enthusiasm but it was pretty obvious a) that such a move couldn't happen overnight and b) that it would come with lots of challenges:

• many popular colorschemes need documentation and hacks,
• many popular colorschemes generate large amount of support request (linked to the previous point),
• many popular colorschemes are pretty much unmaintained anyway so they don't support new features,
• each popular colorscheme is written in a different way than the others,
• the two threads mentioned above were not the ideal place for that process,
• etc.

Additionally, adding more "modern" colorschemes to the roster would only emphasize the problems exhibited by the old guard:

• they have been unmaintained for years/decades, which means that they don't support "recent" features,
• they are very inconsistent, both internally and between themselves,
• they have all been pretty much broken in one way or another for a long time, some of them being borderline unusable outside of a (possibly) very specific context.

Looking at the situation closely, it is quite clear that the whole thing required a rethinking. We created vim/colorschemes in the hope that it would help move the whole question of built-in colorschemes forward, mainly along three axes:

• modernizing the existing built-in colorschemes,
• adding new colorschemes created by members of the community,
• providing better documentation and tooling to colorscheme authors.

The project is still a work in progress, of course, but we are happy to announce that, thanks to the hard work of a small but motivated team, a first milestone is finally within reach: as of today, we (the vim/colorschemes team) consider the modernized versions of all the built-in colorschemes (except "default") to be in a shippable state and we would like the community to play with them and report any issue to the team.

As of now, all of the "remakes", as we call them, are usable in 0 colors, 16 colors, and 256 colors terminal emulators, as well as GUIs, with the usual caveats regarding terminal capabilities.

Of note:

• they are all identical in monochrome environments (&t_co == 0 for example),
• diff colors are the same for every colorscheme,
• whenever possible, the colors are derived from the most high-definition source available,
• conversion from one color space to the other was done without software assistance,
• due to the many inconsistencies plaguing the originals, we generally favored the spirit to the letter so the peachpuff remake (to really pick a random example) _is not the original peachpuff; it still retains much of what made peachpuff peachpuff but in a much more usable and up-to-date package.

If you want to participate to this effort, feel free to install vim/colorschemes alongside your other plugins and use our issue tracker [4] to report problems or suggest improvements.

[1] https://github.com/vim/colorschemes [2] https://github.com/vim/vim/issues/1665 [3] https://github.com/vim/vim/issues/4996 [4] https://github.com/vim/colorschemes/issues

[neutaaaaan]

I am hereby complaining that I can't find anything to complain about in this draft.

Aside from that, looks good to me.

[habamax]

sorry to be that guy :), if I were the reader (not involved into colorscheme remakes) I might miss that there are remade colorschemes to try and probably include into vim distribution as of now.

TLDR-alike preface would be nice to have (initial message was shorter, thus it didn't suffer from this)

Hello,

SUMMARY: All legacy colorschemes are ready to be tested/included into vim distribution.

We started the vim/colorschemes [1] project in May 2020 in the wake of two threads focusing on expanding the built-in colorschemes roster [2][3]. ...

[romainl]

DRAFT #4 (added summary as well as a few lines at the bottom)

---

Hello,

SUMMARY: The remakes of all legacy colorschemes are ready to be tested/included into the Vim distribution. Feedback welcome.

We started the vim/colorschemes [1] project in May 2020 in the wake of two threads focusing on expanding the built-in colorschemes roster [2][3].

The initial push for introducing popular colorschemes was met with enthusiasm but it was pretty obvious a) that such a move couldn't happen overnight and b) that it would come with lots of challenges:

• many popular colorschemes need documentation and hacks,
• many popular colorschemes generate large amount of support request (linked to the previous point),
• many popular colorschemes are pretty much unmaintained anyway so they don't support new features,
• each popular colorscheme is written in a different way than the others,
• the two threads mentioned above were not the ideal place for that process,
• etc.

Additionally, adding more "modern" colorschemes to the roster would only emphasize the problems exhibited by the old guard:

• they have been unmaintained for years/decades, which means that they don't support "recent" features,
• they are very inconsistent, both internally and between themselves,
• consequently, they have all been pretty much broken in one way or another for a long time, some of them being borderline unusable outside of a (possibly) very specific context.

Looking at the situation closely, it is quite clear that the whole thing required a rethinking. We created vim/colorschemes in the hope that it would help move the whole question of built-in colorschemes forward, mainly along three axes:

• modernizing the existing built-in colorschemes,
• adding new colorschemes created by members of the community,
• providing better documentation and tooling to colorscheme authors.

The project is still a work in progress, of course, but we are happy to announce that, thanks to the hard work of a small but motivated team, a first milestone is finally within reach: as of today, we (the vim/colorschemes team) consider the modernized versions of all the built-in colorschemes (except "default") to be in a shippable state and we would like the community to play with them and report any issue to the team.

As of now, all of the "remakes", as we call them, are usable in 0 colors, 16 colors, and 256 colors terminal emulators, as well as GUIs, with the usual caveats regarding terminal capabilities.

Of note:

• they are all identical in monochrome environments (&t_co == 0 for example),
• diff colors are the same for every colorscheme,
• whenever possible, the colors are derived from the most high-definition source available,
• conversion from one color space to the other was done without software assistance,
• due to the many inconsistencies plaguing the originals, we generally favored the spirit to the letter so the peachpuff remake (to really pick a random example) _is not the original peachpuff; it still retains much of what made peachpuff peachpuff but in a much more usable and up-to-date package.

If you want to participate to this effort, feel free to install vim/colorschemes alongside your other plugins and use our issue tracker [4] to report problems or suggest improvements. We would also like to get some community input regarding the remaining topics:

• documentation,
• tooling,
• and how to select the new colorschemes.

Thank you.

[1] https://github.com/vim/colorschemes [2] https://github.com/vim/vim/issues/1665 [3] https://github.com/vim/vim/issues/4996 [4] https://github.com/vim/colorschemes/issues

[habamax]

_is not the original peachpuff

^^^^

[romainl]

It's a mardown renderer artefact. The actual text is not in markdown.

[chrisbra]

As of now, all of the "remakes", as we call them, are usable in 0 colors, 16 colors, and 256 colors terminal emulators, as well as GUIs, with the usual caveats regarding terminal capabilities.

Does GUI include (configured) terminals with truecolor capabilities?

[habamax]

@chrisbra if you are into g:terminal_ansi_colors then yes.

Although, looks like current vim has an issue with it https://github.com/vim/colorschemes/issues/54#issuecomment-1019834057 (and revealed here https://github.com/romainl/Apprentice/issues/66)

[chrisbra]

no I didn't mean terminal colors. I meant If I enable termguicolors, the colorschemes will basically support GUI colors, right?

[chrisbra]

okay thanks

[romainl]

@chrisbra they all support true colors in this scenario:

" set the option first
set termguicolors
" then choose a colorscheme
colorscheme blue

but AFAIK this scenario is still problematic:

" choose a colorscheme
colorscheme blue
" then set the option
set termguicolors

I think this must be handled at the colortemplate level.

The problem we have with the problematic scenario is that the gui attributes are only set when in GUI or when termguicolors is on. If termguicolors is enabled after the colorscheme is sourced, then the gui attributes are not defined and Vim can't infer the correct values.

This is colortemplate's layout:

if (has('termguicolors') && &termguicolors) || has('gui_running')
  hi Normal guifg=#ffdf00 guibg=#000087 gui=NONE cterm=NONE
  ...
endif

if &t_Co >= 256
  hi Normal ctermfg=220 ctermbg=18 cterm=NONE
  ...
endif

if &t_Co >= 16
  hi Normal ctermfg=yellow ctermbg=darkblue cterm=NONE
  ...
endif

if &t_Co >= 0
  hi Normal term=NONE
  ...
endif

For a colorscheme to work properly in both scenarios, GUI attributes must either be set unconditionally:

hi Normal guifg=#ffdf00 guibg=#000087 gui=NONE cterm=NONE

if &t_Co >= 256
  hi Normal ctermfg=220 ctermbg=18 cterm=NONE
  ...
endif

if &t_Co >= 16
  hi Normal ctermfg=yellow ctermbg=darkblue cterm=NONE
  ...
endif

if &t_Co >= 0
  hi Normal term=NONE
  ...
endif

or :

if &t_Co >= 256 || has('gui_running')
  hi Normal guifg=#ffdf00 guibg=#000087 gui=NONE ctermfg=220 ctermbg=18 cterm=NONE
  ...
endif

if &t_Co >= 16
  hi Normal ctermfg=yellow ctermbg=darkblue cterm=NONE
  ...
endif

if &t_Co >= 0
  hi Normal term=NONE
  ...
endif

That way, the gui attributes are pretty much guaranteed to be present when doing :set termguicolors.

[habamax]

I have mentioned here @lifepillar (with regards to colortemplate to fix this) in between of @chrisbra messages and "Later I found out messages were duped" in my browser so I deleted one of it.

Both were deleted :(

[romainl]

"Deleted"?

[habamax]

I have deleted one, but yeah, both were deleted instead.

Anyway, doesn't matter now as Lifepillar was pinged in another issue about this.

[lifepillar]

Does GUI include (configured) terminals with truecolor capabilities?

@chrisbra if you are into g:terminal_ansi_colors then yes. Although, looks like current vim has an issue with it https://github.com/vim/colorschemes/issues/54#issuecomment-1019834057

I think this must be handled at the colortemplate level.

This is fixed in the current Colortemplate's master. The change is essentially untested (it actually breaks my test suite, but I don't have time to fix it right now). So, please be my guinea-pigs 😁

[habamax]

@lifepillar it has issues. I will describe them in a relevant topic

[habamax]

Actually for legacy colorschemes it works (there are no "dual" colorschemes for both dark and light where there is https://github.com/lifepillar/vim-colortemplate/issues/54 )

[lifepillar]

Ok, reverted to previous master for now. I'll test it more in a separate branch. Discussion at Colortemplate's repo is here (thanks for opening the issue!).

[habamax]

@chrisbra we've fixed termguicolors to be applied immediately using all builtin colorschemes.

[romainl]

Message sent to vim_use and vim_dev.