[vim/vim] update colorschemes (PR #12163)
Maxim Kim
new colorschemes
- wildcharm: dual background contrast colorscheme, vibrant and playful, at least one popular AI thinks it is.
- retrobox: port/variation of gruvbox
- sorbet: inspired by cold colorschemes like nord/iceberg
- zaibatsu: liberally inspired by the so-called "neo-tokyo", "neon-noir", "cyberpunk", "vaporware", etc. a e s t h e t i c, as well as popular colorschemes like dracula, tokyonight, or onedark.
updated colorschemes
- lunaperche
- quiet
- habamax
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/12163
Commit Summary
- 07d049e update colorschemes
File Changes
(7 files)
- M runtime/colors/habamax.vim (72)
- M runtime/colors/lunaperche.vim (135)
- M runtime/colors/quiet.vim (441)
- A runtime/colors/retrobox.vim (874)
- A runtime/colors/sorbet.vim (444)
- A runtime/colors/wildcharm.vim (753)
- A runtime/colors/zaibatsu.vim (563)
Patch Links:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Maxim Kim
Thx to @romainl, @neutaaaaan
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
codecov[bot]
Codecov Report
Merging #12163 (07d049e) into master (1433802) will increase coverage by
0.37%.
The diff coverage isn/a.
@@ Coverage Diff @@ ## master #12163 +/- ## ========================================== + Coverage 81.95% 82.33% +0.37% ========================================== Files 160 154 -6 Lines 193810 183678 -10132 Branches 43840 41400 -2440 ========================================== - Hits 158834 151227 -7607 + Misses 22138 19904 -2234 + Partials 12838 12547 -291
| Flag | Coverage Δ | |
|---|---|---|
| huge-clang-none | 82.67% <ø> (+<0.01%) |
⬆️ |
| huge-gcc-none | ? |
|
| huge-gcc-testgui | 51.96% <ø> (+<0.01%) |
⬆️ |
| huge-gcc-unittests | 0.29% <ø> (?) |
|
| linux | 82.33% <ø> (-0.07%) |
⬇️ |
| mingw-x64-HUGE | ? |
|
| mingw-x86-HUGE | ? |
|
| windows | ? |
Flags with carried forward coverage won't be shown. Click here to find out more.
see 138 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Maxence Weynans
Just a heads-up : this commit doesn't touch CODEOWNERS and CODEOWNERS is currently lacking entries for the habamax, lunaperche, and quiet colorschemes that already ship with the runtime.
They need to be added to CODEOWNERS, along with the new colorschemes zaibatsu, wildcharm, sorbet and retrobox
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Maxim Kim
@habamax pushed 1 commit.
- a00abb8 Update CODEOWNERS
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
Romain Lafourcade
Hmm, speaking of CODEOWNERS, GitHub doesn't seem to like how it is used:
@brammool @chrisbra, the doc clearly says that it should contain the names of people with write permissions, which is clearly not the case for most people in that file.
Are they notified anyway, even if they are outsiders?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
yeah I have noticed in the past and wondered if it really helps. You could test it out by creating a dummy PR against e.g. runtime/colors/blue.vim and see if you get notified.
But even if this doesn't work, it at least is (yet another) way to know whom to notify
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
About the colorschemes: Any comments on including these? I like to keep the number of distributed colorschemes small, so that users are not overwhelmed. They should be quite different.
About CODEOWNERS: I don't know why github requires write access. Is that configurable somewhere?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
bfrg
I've noticed an inconsistency between a few colorschemes. Some colorschemes contain highlight groups that are defined by 3rd party plugins (e.g. fugitive, ALE, etc.), or syntax files (e.g. vimOper, elixirOperator, javaScript*, etc.), while others don't. Is that by accident? IMO, all distributed colorschemes should provide the same highlight groups.
Should filetype-specific highlight groups like vimOper, elixirOperator etc. even be defined in a colorscheme? If this becomes a common theme, the colorschemes will grow very quickly once users start adding filetype-specific highlight groups to each colorscheme (there are over 500 different syntax files, each one defining several syntax groups). I can understand the reasoning behind it but I feel like they will quickly become unmaintainable.
I thought the purpose of a colorscheme file was to define only general highlight groups (like :h highlight-default and :h group-names).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Romain Lafourcade
@bfrg Yes, the fact that some have those specific groups and some don't is definitely an accident. I agree, non-default highlight groups have nothing to do here.
@habamax can we talk about lunaperche and habamax?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Maxim Kim
Sure, we can, @romainl. Let's remove it, though it wouldn't be the colorschemes I, as an author, aimed to create anymore.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Maxence Weynans
They should be quite different
@brammool while the work done last year indirectly did a lot to improve variety between the older colorschemes, most of them use rather aggressive or dull colors, with little thought given to the overall balance and feel. This cannot be fixed without drastically altering them, much beyond what we already had to do to ensure they'd behave properly in different environments.
This is the main reason why retrobox, sorbet, zaibatsu and wildcharm (as well as quiet, habamax and lunaperche, that already ship as part of the runtime) exist. Those newer colorschemes are based on styles popular within the larger vim colorscheme ecosystem in terms of palette and general feel, and aim to round out the current set of colorschemes.
And as they are specified rather exhaustively, it's viable for an end user to pick one and, through the use of autocommands, use it as a "platform" for their own modifications, without having to understand too much about colorschemes, or being forced to shlep many files around.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> I've noticed an inconsistency between a few colorschemes. Some
> colorschemes contain highlight groups that are defined by 3rd party
> `elixirOperator`, `javaScript*`, etc.), while others don't. Is that by
> accident? IMO, all distributed colorschemes should provide the same
> highlight groups.
>
> `elixirOperator` etc. even be defined in a colorscheme? If this
> becomes a common theme, the colorschemes will grow very quickly once
> users start adding filetype-specific highlight groups to each
> colorscheme (there are over 500 different syntax files, each one
> defining several syntax groups). I can understand the reasoning behind
> it but I feel like they will quickly become unmaintainable.
>
> I thought the purpose of a colorscheme file was to define only general
Hopefully only the default highlight groups need to be defined. If for
some syntax file this doesn't work that is an indication that there is
something wrong. This can be how the default groups are used in a
syntax file, or perhaps the set of default groups is not quite right. I
see that "vimOper" links to "Operator" and "Operator" is not used for
anything else. So why not define highlighting for "Operator"?
--
Facepalm statement #4: "3000 year old graves? That's not possible, it's only
2014!"
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Romain Lafourcade
FWIW, Operator is linked to Statement in syntax/syncolor.vim and linked to in 480+ places under syntax/.
In my opinion, everything under :help highlight-groups is fair game, as well as any other group that is used by Vim out of the box, without necessarily being documented in that section. Like… the following list, taken from syntax/syncolor.vim:
SynLink String Constant
SynLink Character Constant
SynLink Number Constant
SynLink Boolean Constant
SynLink Float Number
SynLink Function Identifier
SynLink Conditional Statement
SynLink Repeat Statement
SynLink Label Statement
SynLink Operator Statement
SynLink Keyword Statement
SynLink Exception Statement
SynLink Include PreProc
SynLink Define PreProc
SynLink Macro PreProc
SynLink PreCondit PreProc
SynLink StorageClass Type
SynLink Structure Type
SynLink Typedef Type
SynLink Tag Special
SynLink SpecialChar Special
SynLink Delimiter Special
SynLink SpecialComment Special
SynLink Debug Special
or debugPC and debugBreakpoint, which are underdocumented.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Romain Lafourcade
Sure, we can, @romainl. Let's remove it, though it wouldn't be the colorschemes I, as an author, aimed to create anymore.
That's precisely why I won't submit Apprentice or Malotru for inclusion.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Maxence Weynans
I've mentionned that during a private conversation with @habamax already, but I think getting rid of all the custom links is a bad idea.
Anything that ships with the runtime is fair game in my opinion, and if some elements end up being highlighted in a way that feels semantically misleading, and the issue isn't clearly with the syntax file itself, then this ought to be fixed in the colorscheme.
There will always be such instances of awkward highlighting because of design decisions that work perfectly fine in the context the author was initially thinking about, but don't pan out when editing specific filetypes.
Shell scripts will never not look like a clown got food poisoning. DiffRemoved inherits its color from the Special group for some reason, but there's no guarantee of Special being red.
Those discrepancies and issues just pile up as more work goes into refining a colorscheme. It's unavoidable.
Some of the older colorschemes rewire minor groups pretty liberally. I can only assume this is because the original authors had similar issues within the small subset of filetypes they worked with. This shouldn't have been allowed to happen.
Case by case overrides is the only way to address this.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Thomas Köhler
On Sun, Mar 19, 2023 at 02:29:07AM -0700, Maxence Weynans <vim-dev...@256bit.org> wrote:
[...]
> liberally. I can only assume this is because the original
> filetypes* they worked with. This shouldn't have been allowed
> this.
one you mentioned, we also didn't have all of the highlightning
groups we have today when we started out, a few were added at
later points in time. So we sometimes took the liberty to rewire
things a bit differently than we would otherwise - of course all
of us only looking at our subset of filetypes we worked with at
the time (of which there were also a lot less than there are
today).
Ciao,
Thomas - the guy whose fault the "koehler" colorscheme is ;)
--
Thomas Köhler Email: jean...@picard.franken.de
<>< WWW: http://gott-gehabt.de
IRC: tkoehler Freenode: thkoehler
PGP public key available from Homepage!
bfrg
DiffRemovedinherits its color from the Special group for some reason, but there's no guarantee of Special being red.
I think you're talking about diffRemoved which is defined in syntax/diff.vim. And I agree, this syntax group is an exception. Most users will expect a red foreground. It is different from DiffRemoved which is used in diff-mode where most users will expect it to have a red background. I'm sure there are more exceptions where neither of the highlight groups mentioned in :h group-names fit well. Maybe that list should be extended?
Currently, there are 5 different group names for the Preprocessor. Most colorschemes I've seen use the same color for all 5 groups. Likewise, there are different group names for for/while loops, conditionals, labels and exceptions. The colorschemes I've seen will all highlight them as Statement. But then, on the other hand, there is only Underline. Where is Bold and Italic? Similarly, there's one highlight group called Error, but Warning and Info are missing. Maybe a few more group names could be added so that syntax files can link to them? OTOH, html and many doc file like markdown, rst, asciidoc, latex etc. use different headings. html uses h1 to h6, the other formats use something similar. But Vim provides only one highlight group that is useful and that is Title. A few more default names could be added. Then other syntax files could link against them and colorschemes would adopt these names.
Most other highlight groups that I can see, for example, in the colorscheme habamax, I would expect them to be defined in after/syntax/<filetype>.vim. For example:
hi! link javaScriptFunction Statement hi! link javaScriptIdentifier Statement
I use the exact same javascript links. But since I want this behavior for every colorscheme, I have put these links in after/syntax/javascript.vim.
I really wonder how other editors solve all this.
That's precisely why I won't submit Apprentice or Malotru for inclusion.
@romainl Is Apprentice broken when you remove certain links? Maybe after/colors/<colorscheme>.vim should be automatically sourced once a specific colorscheme is loaded, similar to after/ftplugin/<filetype>.vim? I know this is already possible with autocommand and the ColorScheme event but working with files is easier and it is already done for filetype and syntax files.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Maxence Weynans
Some housekeeping would be nice, but more groups would not help this particular situation, as overrides would inevitably happen regardless. Colorschemes are as much about aesthetics as they are about shaping up your interpretation of the underlying semantics.
Similarly, I don't see how throwing more files into the runtime to handle the exceptions could help. That's just shuffling the solution around for the sake of correctness, whilst making the whole thing harder to grasp for an end user.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
I'll include this now, as there are no relevant objections. There are always remarks about what looks good or bad to some users. We will keep improving this over time.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Closed #12163.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.