Extmark with `number_hl_group` does not combine highlighting with any `*LineNr*` highlight group

[echasnovski]

Extmark with `number_hl_group` does not combine highlighting with any `*LineNr*` highlight group

[luukvbaal]

Vim (not Nvim) behaves the same?

No (doesn't have this functionality)

Not true, number_hl_group just implements the legacy sign numhl property. FWIW, vim behaves the same, not combining any attrs for numhl: https://github.com/vim/vim/blob/15935e7f54f0e00782a55ebc39a68e4cd94c2571/src/drawline.c#L479

Whether it should, or we want to regardless of what vim does, is up for debate I suppose.

[echasnovski]

Not true, number_hl_group just implements the legacy sign numhl property. FWIW, vim behaves the same, not combining any attrs for numhl: https://github.com/vim/vim/blob/15935e7f54f0e00782a55ebc39a68e4cd94c2571/src/drawline.c#L479

I see. Although, it looks more like an implementation detail, as extmarks are not the same as signs. As Vim does not have extmarks, to me it can not behave the same when question is about their behavior.

[luukvbaal]

To the contrary, extmark signs and legacy signs use the same drawing code path and are functionally identical. The same "issue" can be reproduced in both vim and nvim with :sign commands.

[echasnovski]

To the contrary, extmark signs and legacy signs use the same drawing code path and are functionally identical.

This is implementation details. As is the fact that number_hl_group is implemented using legacy signs.

Here is the documentation of number_hl_group option which says nothing about it being related to signs:

• number_hl_group: name of the highlight group used to
highlight the number column. Note: ranges are unsupported
and decorations are only applied to start_row

[luukvbaal]

I mean yeah but it's a relevant implementation detail. I don't think it makes sense to consider the extmark case in isolation.

[luukvbaal]

The :h sign-define docs specifically state that numhl overrides the *LineNr* hl groups BTW.

[luukvbaal]

Here is the documentation of number_hl_group option which says nothing about it being related to signs:

I think the extmark *hl_groups should mention their :sign define counterparts, or at least not omit information which is present there.

And if the behavior is to be changed, it should be proposed as a vim patch first. I think overriding but combining is reasonable also for Vim.

[bfredl]

overriding is an anti-pattern. Combining (with well-definied ordering) is how we process highlight sources in general, and should be how number_hl_group takes effect as well.

Still I concur the the first thing to try is to send a patch/issue to vim, so we can keep the code as unified as possible while being consistent with vim, as long as this is possible.

[zeertzjq]

I don't think combining is a good idea. Removing attributes is harder than adding. E.g., how are you supposed to remove a bold or italic attribute when combining?

[bfredl]

@zeertzjq Very simple: you just don't. if information source X adds a color and information source Y adds a bold attribute, the effect of having both sources at the same place is to have both the color and the attribute. If this is undesired, you reconfigure the source whose behavior you don't want. This is how highlight combining works all over the place. There is no reason to make number_hl_group different.