feat(highlight): ns=0 to set :highlight namespace

[lewis6991]

Passing ns=0 to nvim_set_hl will alter the :highlight namespace.

[lewis6991]

Hmm, that seems to have trouble with the Normal highlight group being applied? (I get transparent background and pure white foreground.) This works when using a different namespace and nvim__set_hl_ns(ns).

Other groups seem to work, though.

Ok good to know.

FWIW I've done very little testing with this. Most of the work was just trying to understand how vim hl groups generally behave.

I'll pass this through a full colorscheme and and work out more of the edge cases; and of course add tests.

[lewis6991]

Yeah, I just saw "non-draft" and jumped in :)

Ok. I did add a "WIP" to the title, but I've gone ahead and made this a draft as well.

I used this, if you want a pre-made one (just make the obvious change at the bottom): gist.github.com/clason/c164d718dcefbc27f08d3e0272cf93ae

Thanks. I also have my personal colorscheme to test for this: https://github.com/lewis6991/github_dark.nvim/blob/a0f6f75fc86f1a4f5e1760b0cda0c0258d51d2bc/lua/github_dark.lua#L30-L71, which was partially the motivation for working on this change.

[lewis6991]

We don't do that anymore ;)

But I was mostly curious and wanted to give early feedback; feel free to ignore.

ACK.

Thanks, I really appreciate the feedback.

[lewis6991]

Hmm, that seems to have trouble with the Normal highlight group being applied? (I get transparent background and pure white foreground.) This works when using a different namespace and nvim__set_hl_ns(ns).

Other groups seem to work, though.

Finally, got round to debugging this, turns out Normal is special:

neovim/src/nvim/highlight_defs.h

Lines 174 to 178 in 5205bcc

	EXTERN int cterm_normal_fg_color INIT(= 0);
	EXTERN int cterm_normal_bg_color INIT(= 0);
	EXTERN RgbValue normal_fg INIT(= -1);
	EXTERN RgbValue normal_bg INIT(= -1);
	EXTERN RgbValue normal_sp INIT(= -1);

[lewis6991]

(You're probably aware, but current code segfaults if you set highlights for a non-0 namespace, btw.)

I wasn't...

Thanks

EDIT: Fixed

[clason]

Yep, now it works -- no crash, and Normal gets set correctly!

[lewis6991]

Don't know why CI is failing. Let's un-draft to see what the other jobs do.

[clason]

The CI Is a Harsh Mistress...

[clason]

LGTM, but I'll have to defer to @bfredl on the code itself.

[lewis6991]

BTW, is there any mechanism we can use to detect this change in plugins? Lots of users have some dev build of v0.7 so it would be beneficial to provide some way of checking this.

My only idea would be to add something like vim._has_hl_api_ns0.

This applies to the signs PR too.

[clason]

No, we don't do feature flags -- we only support:

1. the latest stable version (0.6.1 atm)
2. the latest commit on master (which already reports as 0.7.0)

Plugins are strongly recommended to follow the same policy. So in this (and the sign) case, plugins should just check has('nvim-0.7'). People on an older master build should be told to update. ("If you grab the nightly tiger by the tail...")

[lewis6991]

No, we don't do feature flags -- we only support:

Ok I guess...

People on an older master build should be told to update.

This hasn't been so smooth in the past, but let's see how disruptive lewis6991/gitsigns.nvim#463 is.

[clason]

Yeah, there's a segment of the audience who can't resist the temptation of running the latest and shiniest, but can resist the temptation of doing so in an informed manner.

The only thing that can be done is:

1. be extra clear about the requirements and support guarantees (and stick to it when the complaints start) and
2. wait a day or two for the official nightlies to include the feature (and maybe a fixup or two) before shipping a corresponding change in a plugin.

(Step 1 is exactly what I'm doing here, and anywhere else I can shoehorn it in.)