vim9 readiness + legacy colorscheme remakes

[Maxim Kim]

Hi Bram,

Could you share your thoughts on when you think vim9 would be released (as you're closing vim9script it looks like this year for me).

We would like to be ready with legacy colorschemes remake before vim9 release happen.

As of now all of them are remade with a couple 'major' issues to resolve

* incsearch visibility (there is already a PR to address it)

* diff visibility issues with error highlighting.

Remakes would definitely be a "breaking change" as they:

* try to use 256 color palette where possible with fallback to 16 colors and no colors depending on t_Co

* some colorschemes were using completely different colors in gui and tui -- we did pick one and made it consistent too.

It means that, for example, peachpuff now is light even in tui -- and there for sure people who use peachpuff with dark background relying on terminal 0-15 colors who probably would not be very happy with this change.

Thank you!

[Thomas Köhler]

Hi all,

Actually, please let me know if any changes are required for
koehler.vim or let me have a look at the new version if you
already made those changes. I would take the opportunity to have
a look into those changes (plus into any additional highlight
groups that might exist and that I would then fully support).

> Thank you!

Thanks,
Thomas

--
Thomas Köhler Email: jean...@picard.franken.de
<>< WWW: http://gott-gehabt.de
IRC: tkoehler Freenode: thkoehler
PGP public key available from Homepage!

[Christian Brabandt]

On Di, 11 Jan 2022, Thomas Köhler wrote:

> Actually, please let me know if any changes are required for
> koehler.vim or let me have a look at the new version if you
> already made those changes. I would take the opportunity to have
> a look into those changes (plus into any additional highlight
> groups that might exist and that I would then fully support).

Improving the existing Colorschemes are worked on in the
vim/colorschemes repository. For koehler, you can have a look at:
https://github.com/vim/colorschemes/blob/master/colors/koehler.vim

Best,
Christian
--
Ich empfehle Daniel Kehlmann unbedingt.
-- Daniel Kehlmann
(Marc-Uwe Kling: Falsch zugeordnete Zitate; eigentlich Klaus Bednarz)

[Bram Moolenaar]

Thanks for asking. It would indeed be very nice if Vim9 can include the
revamped color schemes.

Most work on Vim9 is done, but getting all the last pieces in place will
still take a few weeks. I would also like to get an update on the
translations, which is why I recently moved all the error messages (and
updated a few of them). I expect we need to give translators a couple
of months to do their work. So in about three months we should have a
complete version, and we can decide if it's ready to launch.

--
Facepalm statement #1: "I'm going to New York tomorrow, hopefully I have time
to visit the White House"

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Thomas Köhler]

Hi all,

On Tue, Jan 11, 2022 at 04:10:23PM +0100, Christian Brabandt <cbl...@256bit.org> wrote:
> On Di, 11 Jan 2022, Thomas Köhler wrote:
>
> > Actually, please let me know if any changes are required for
> > koehler.vim or let me have a look at the new version if you
> > already made those changes. I would take the opportunity to have
> > a look into those changes (plus into any additional highlight
> > groups that might exist and that I would then fully support).
>
> Improving the existing Colorschemes are worked on in the
> vim/colorschemes repository. For koehler, you can have a look at:
> https://github.com/vim/colorschemes/blob/master/colors/koehler.vim

Thanks.
I just tested a bit and found an issue:
When I run vim in an xterm and then decide to switch to the gui
via ":gui", the colorscheme doesn't fully apply.
The reason for this is that the code that defines everything for
the gui is enclosed in code like this:

if (has('termguicolors') && &termguicolors) || has('gui_running')
let g:terminal_ansi_colors = ['#000000', '#cd0000', '#00cd00', '#cdcd00', '#0000ee', '#cd00cd', '#00cdcd', '#e5e5e5', '#7f7f7f', '#ff0000', '#00ff00', '#ffff00', '#5c5cff', '#ff00ff', '#00ffff', '#ffffff']
hi ColorColumn guifg=NONE guibg=#8b0000 gui=NONE cterm=NONE
[...]
unlet s:t_Co
finish
endif

So in other words, if you start vim in xterm, termguicolors may
not be available and gui_running obviously is not the case, which
leads to g:terminal_ansi_colors not being set and and the "hi"
commands that would setup highlightning for the gui correctly are
not executed. If you then decide to run ":gui", the colorscheme
isn't loaded again, skipping this part completely. I ended up
with gvim and white background even though my colorscheme has
been developed for a black background.

I could fix this by adding the following lines near the beginning
of the file:

augroup COLORSCHEME
au! GuiEnter * colorscheme koehler
augroup END

However, I'm not sure if this is actually a safe way to address
the issue (just using an autocommand didn't work in my case as my
.vimrc contains another "au! GuiEnter ..." which overwrites all
autocommands for the GuiEnter event; that's why I tried the
augroup in the first place). Someone might create a COLORSCHEME
augroup in his .vimrc which might then collide with the one
defined here.

Maybe one of the people working on the colorschemes has a better
idea how to resolve this?

> Best,
> Christian

Bye,

[Maxim Kim]

Yes, we know about it, see https://github.com/vim/colorschemes/issues/54

This is something we would like to address in some future with the help of colortemplate author, @lifepillar

воскресенье, 23 января 2022 г. в 14:17:26 UTC+3, jean...@picard.franken.de:

[Thomas Köhler]

Hi,

On Sun, Jan 23, 2022 at 03:20:04AM -0800, Maxim Kim <hab...@gmail.com> wrote:
> Yes, we know about it, see https://github.com/vim/colorschemes/issues/54

Thanks for pointing me to this issue.

> This is something we would like to address in some future with the help of
> colortemplate author, @lifepillar

[...]

I have commented above issue with a potential solution/workaround.
Let's hope @lifepillar will implement something like this in the
next version.