Questions about mini.hues related to java syntax highlighting

[231tr0n]

Hi echasnovski! I had a suggestion about java highlighting for mini.hues.



The thing is that java extensively uses @type.java which links to Type highlight group. Now the issue is that type interfaces like Map and classes like Integer in java are all linked to the Type highlight group.
So I checked as to what highlight group can I apply to color the Type highlight group and the only color which I could use is orange which is probably the only one not used.
So I applied orange only to realize that important keywords like public and class in java are bold and things like Integer and Interfaces like Map are colored orange.
So I inverted those colors and added the following highlights resulting in the below picture which is perfect. I also removed orange highlighting for Delimiter and made Operator highlight group to bold.

                -- Global.palette holds mini.hues generated colors.
		Hi("Statement", { bg = "NONE", fg = Global.palette.orange })
		Hi("Delimiter", { bold = true })
		Hi("Type", { bold = true })
		Hi("Operator", { bold = true })
		Hi("@constructor.lua", { bold = true })

I actually felt like this makes java syntax highlighting better overall. This also effects C syntax highlighting as well as before these changes int keyword of c which is linked to Type highlight group is not highlighted at all.
Without above changes c syntax highlighting

c syntax highlighting with above c changes

I also tested these changes in languages other than java namely lua(little obvious), go, python.
Do you think these changes can be made in mini.hues as I feel like they improve java highlighting by a huge margin. They improve syntax highlighting of c and java by a huge margin as shown in above pictures while not disturbing highlights of other languages.

I wanted to know about your opinion on this and since this is related to syntax highlighting of a language and if possible consider for these changes to be made in mini.hues.

Also, I wanted to talk a little bit about #1256. Like can the highlighting for @none be changed to bg = "NONE" and fg = "NONE" since that probably could be considered another interpretation for treesitter-highlighting guidelines. I am asking about this again since many people who might use mini.hues will for sure come across this treesitter highlight group over cursorline thingy and will have to make those changes and I feel like this is a valid change for mini.hues as well.

[echasnovski]

Do you think these changes can be made in mini.hues as I feel like they improve java highlighting by a huge margin. They improve syntax highlighting of c and java by a huge margin as shown in above pictures while not disturbing highlights of other languages.

I wanted to know about your opinion on this and since this is related to syntax highlighting of a language and if possible consider for these changes to be made in mini.hues.

If you suggest changing how 'Statement', 'Delimiter', 'Type', 'Operator', etc. are highlighted, then I am afraid their current highlighting works good and probably won't change.

If you suggest changing them on a per-language basis (similar to how '@constructor.lua' is adjusted here), then this will definitely not happen for Java, since adding language specific highlight group is a very big exception (like with '@string.special.vimdoc').

All in all, my main suggestion has not changed: if there are any issues with highlighting of a handful of groups, adjust them manually with the follow up vim.api.nvim_set_hl(0, 'Xxx', { ... }).

Also, I wanted to talk a little bit about #1256. Like can the highlighting for @none be changed to bg = "NONE" and fg = "NONE" since that probably could be considered another interpretation for treesitter-highlighting guidelines. I am asking about this again since many people who might use mini.hues will for sure come across this treesitter highlight group over cursorline thingy and will have to make those changes and I feel like this is a valid change for mini.hues as well.

Having vim.api.nvim_set_hl(0, '@none', { fg = 'NONE', bg = 'NONE' }) is the same as vim.api.nvim_set_hl(0, '@none', {}). Both do not match the "completely disable the highlight" description in 'nvim-treesitter/nvim-treesitter'. Unless wording there is changed or it is removed completely (which, I think, is planned), it won't change in 'mini.hues'.