Remake default.vim

[romainl]

We can base it on the colortemplate sample and/or on @neutaaaaan's effort.

[habamax]

I wouldn't touch default.vim at all. Not brave enough :)

[lifepillar]

What do you mean by “remaking default”? Vim's default color scheme is hard-coded, and replacing it is not viable, I think. Do you mean making a new color scheme which looks like default?

[habamax]

Who do you ask, @lifepillar ?

Technically, there is default.vim in a vim's repo, which is almost empty. We could use it to make better default, but I believe this is a no go.

[lifepillar]

Who do you ask

Maybe @romainl, who has opened the issue, may elaborate on what would be done: a “default9.vim” color scheme?

Technically, there is default.vim in a vim's repo, which is almost empty. We could use it to make better default, but I believe this is a no go.

Yes, that is what I meant with “it is not viable”.

[romainl]

default is spread over:

1. $VIMRUNTIME/colors/default.vim, which doesn't do much.

2. $VIMRUNTIME/syntax/syncolor.vim, which defines syntax-related highlight groups for dark and light background.

   Some parts of this file could be improved, like Brown or the incoherent use of names and hex for gui*g or the difference in some groups between gui*g and cterm*g.

3. src/highlight.c, which defines UI-related highlight groups for dark and light background.

   This file has lots of broken stuff like above as well as non-working Visual and so on.

I don't think we can use colortemplate to fix any of this but making changes to files 2 and 3 should be doable in the main Vim repo, maybe with an issue opened here for each task.

FWIW, I don't know why it is done that way but having the GUI groups in the core and the syntax groups in the runtime makes no sense to me.

[neutaaaaan]

This exists because I extracted the values from the source code and created a template back when I was working on ron or koehler. It just made more sense to figure out the underlying behaviour once and for all, then implement the changes.
That template is probably buried somewhere in another issue closed aeons ago.

We were young and naive then.

As with many things in vim, I don't understand how the way default is laid out passed the most basic of sniff tests. It's crap. It's always been crap. It's never not been crap.
On the other hand, I'm convinced that changing how it works would turn the vim ecosystem into an absolute moshpit. You just have to look at the mess that turning the mouse on by default created. It was a stupid idea, based on a faulty rationale, and all it's actually done is make vim inconsistent across environments.

[lifepillar]

FWIW, I don't know why it is done that way but having the GUI groups in the core and the syntax groups in the runtime makes no sense to me.

So, maybe the first thing is to check with Bram why things are the way they are and if it is feasible to make the default color scheme a “normal” color scheme (my wild guess: probably it isn't).

Then, I sympathize with @neutaaaaan's sentiment about changing something that is really fossilized Vim, even if it would piss off at worst a (vocal) minority. Cosmetic code changes that improve consistency without affecting appearance are fine; anything else, including fixing broken stuff… I don't know. Collecting feedback (say, by the same people who have complained about mouse=a) before merging into Vim would make the decision easier.

[lifepillar]

all it's actually done is make vim inconsistent across environments.

In the case of “fixing” default colors, you would actually achieve the opposite. Nonetheless, I can imagine someone complaining, say, that «now the default background is always white» (because Normal is set), while «before it changed according to my environment».

[neutaaaaan]

@lifepillar I was specifically thinking about distro-specific "fixes" through a systemwide .vimrc.

[romainl]

So, maybe the first thing is to check with Bram why things are the way they are and if it is feasible to make the default color scheme a “normal” color scheme (my wild guess: probably it isn't).

The reason why some of default is hardcoded is because Vim can be distributed without a runtime and, in such cases, it must still be able to do some basic highlighting (visual, status line, etc.). The reason why the rest is in syncolor.vim is very likely to allow the :syntax on switch. That separation has been the cause of many issues in the past, where people build their Vim incorrectly and end up without a proper runtime. Fringe PEBKAC cases but still.

I don't really care about that separation, to be honest, it's only mildly irritating, but the content of those files is chaotic and I would like to do something about it.

When I see things like that:

SynColor Underlined term=underline cterm=underline ctermfg=DarkMagenta gui=underline guifg=SlateBlue
                                                           ^^^^^^^^^^^                     ^^^^^^^^^

I can't escape the feeling that we can do better.