Syntax highlighting differences between this fork and the original repository

[willwillsiii]

I saw that some colors were updated to match the definitions in the ayu-colors repository. I'm not sure if this change is due to that, but I've noticed differences in syntax highlighting between this fork and the original: (this fork on right, old on left)

Notice the difference in which variables recieve the blue color. Perhaps I'm just used to it, but I find the old highlighting to be easier to parse.

Was this intentional?

Sorry if this overlaps with the other syntax highlighting issues that are open.

[Luxed]

Was this intentional?

In short, yes.

To explain further, "variables", in my fork, should always be shown as the "normal" color. The blue that was used before is reserved for either "types" or "properties/fields" (slightly different shade).

Perhaps I'm just used to it

That is often the case. When I make a change, I always make sure to use it myself for a while before pushing it. If I forget about it after a while, it means it's fine, if I don't it means it needs to be changed (which is why #22 is still not merged). But I you could argue that g: is a variable (representing the global dictionary) and vim_markdown_math is a property of that dictionary. But the vim syntax files are not good enough to differentiate those, which is why I chose to use the "variable" color instead of the "property" color.

Another thing to note is that I mostly use treesitter so I have a tendency to use that as a "source of truth". I've found treesitter to be a lot more consistent across languages than most syntax files. Still, I'll look into it. If it turns out the vim syntax and treesitter are different, then I'll see what to do. If everything already looks the same, I'll give you a configuration to add to go back to the previous look.

[willwillsiii]

For what it's worth, I've tested other themes and they seem to follow the behavior of the original repository.

I've also noticed that if I start vim on a different colorscheme, switch to this colorscheme, and then back to the original, the syntax highlighting of the original colorscheme is affected:

(Original gruvbox on left, gruvbox after colorscheme ayu)

[willwillsiii]

Still, I'll look into it. If it turns out the vim syntax and treesitter are different, then I'll see what to do. If everything already looks the same, I'll give you a configuration to add to go back to the previous look.

I appreciate the effort!

[Luxed]

I've also noticed that if I start vim on a different colorscheme, switch to this colorscheme, and then back to the original, the syntax highlighting of the original colorscheme is affected

I've tried this with this gruvbox theme (you didn't give information on which gruvbox theme you are using). I don't have the issue with Neovim or Vim 9.

Still, I'll look into it. If it turns out the vim syntax and treesitter are different, then I'll see what to do. If everything already looks the same, I'll give you a configuration to add to go back to the previous look.

I appreciate the effort!

This is what it looks like with Neovim and TreeSitter. g: uses the @namespace highlight which makes sense. Anything after is highlighted as a "variable". So I'm now sure that it's not a bug and everything looks exactly as intended. You can, however, change the highlight for yourself. Since you are using the default vim syntax, you will need to add the following line call ayu#hi('vimVar', 'syntax_tag', ''). For more information on how to customize Ayu, see this section of the readme (customizing the theme this way means it won't affect any other theme).

[willwillsiii]

I've tried this with this gruvbox theme (you didn't give information on which gruvbox theme you are using). I don't have the issue with Neovim or Vim 9.

Apologies, the issue appears across every colorscheme after loading ayu.vim, which I could have made more clear.

The colorscheme mangling does appear to be a Vim8 bug unfortunately. There's a solution in that issue here.

Thanks for the assistance!