The links added in #13776 are way too noisy for the contexts in which the diff syntax is applied (git commits, patches, etc.).
This commit…
diffAdded, diffChanged, and diffRemoved, valid when using the default colorscheme and other colorschemes that don't explicitly override those highlight groupsFor reference:
diff before the change introduced in #13776
diff after the change introduced in #13776
diff after this commit
https://github.com/vim/vim/pull/13825
(4 files)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
This essentially adds new filetype-specific "default group names" (as in :h group-name); if this is an option, this is clearly a better alternative than relying on default links.
I think this is a good idea, since the current, programming language-oriented, default groups are a poor fit for many markup or data languages (Markdown, Vimdoc, LaTeX, JSON, ...)
Are you generally considering adding more of such groups (as need arises, and obviously not in this PR)?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Thanks, definitely an improvement. Can you please also document those new groups at :h group-name?
Are you generally considering adding more of such groups (as need arises, and obviously not in this PR)?
If need arises
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
(And you probably want to update the bundled colorschemes to account for this change.)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
This essentially adds new filetype-specific "default group names" (as in :h group-name);
Should these be capitalised?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
In default gvim (white bg), diffAdded is kind of hard to read:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
What about DarkGreen for light bg?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@romainl pushed 2 commits.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@romainl pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
limegreen is still too bright to my taste/eyes
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
I've…
:help group-name,syntax/help.vim,green to limegreen for diffAdded in GUI,blue to dodgerblue for diffChanged in GUI.Light background:
Capture.d.ecran.2024-01-07.a.10.00.29.png (view on web)Dark background:
Capture.d.ecran.2024-01-07.a.10.01.14.png (view on web)limegreen is darker and less saturated than green without being as dark as darkgreen, so it is more legible on white and less jarring on black.
dodgerblue is lighter than blue but not too bright so it works equally well on white and black.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
limegreen is still too bright to my taste/eyes
Could you suggest a few alternatives from https://en.wikipedia.org/wiki/X11_color_names#Color_name_chart ?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Interesting, in your screenshots limegreen is actually readable compared to mine. I guess font-size matters a lot here.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Could you suggest a few alternatives from https://en.wikipedia.org/wiki/X11_color_names#Color_name_chart ?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
The header diffOldFile and diffNewFile link to DiffFile which resolves to Type which uses SeaGreen, so let's use this one for DiffAdded as well.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
I have made a few minor changes, which turned out to be even more involved:
Added, Changed and Removed (I initially went with capitalizing the diffAdded to DiffAdded, but since hightlighting groups are not case sensitive, it causes problems for linking the groups in the color schemes, so I had to make the name different and removed the diff prefix)diff syntax file.That is what I have temporarily queued, not sending out yet, would like to get an okay for that.:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
but it didn't include that commit.
You would have to checkout branch gh-13825, e.g.: https://github.com/chrisbra/vim/tree/gh-13825
Let me include it now, we can always further re-adjust
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.![]()
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.![]()
Default colors for Added/Changed/Removed are good enough for most of the bundled colorschemes.
The only outlier was murphy where green is the normal fg color and it gets in the way with Added, so I changed it to white:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.![]()
Do we have a reliable, unequivocal way of pointing out to distro maintainers that some patches are fixes to existing features that don't work properly in the current major or minor version, so they don't rebase upon that without including those fixes ?
As we've seen with the colourscheme work that was pushed late into the vim 8.2 cycle, and all the fixes pushed early into the vim 9.0 cycle, or with this specific pull request, this is sorely needed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.![]()