Fix variable name face

[bbatsov]

The face is used for definitions, not variable references. (think defvar in Elisp)

Old:

That face should have font-locked the names in the var definitions here.

New:

Same as above, but with names in var defs in lavender.

[sgoudham]

I don't have the context to this but Catppuccin, generally, should only modify the colours in a port and not change the font size / shape / etc. We should always rely on defaults wherever possible so the introduction of this PR feels like we're modifying this elsewhere where we shouldn't be?

If this is introducing new customisation options then I'd personally push back against it as you shouldn't need to configure font settings via a colourscheme.

[bbatsov]

My point is mostly that the way this was configured simply doesn't make sense in the context of Emacs. From what I gather the original version was written for Vim and then was ported to other editors, but variable-name-face in Emacs is not an usage of a variable, but a definition of a variable and almost all Emacs themes font-lock this, so those would stand out.
It seems to me that whoever styled this, thought this pertains to variable usage, but in reality it doesn't.

E.g. here's how the same snippet looks with the popular Solarized theme:

[bbatsov]

Similarly you'll notice that for some reason doctrings are styled as comments, even if they are strings. Even in the reference catppuccin screenshots those are green:

[bbatsov]

To summarize - my main concern (and the problem I'm trying to solve) is that it seems to me that some of the fundamental font-lock-* colors differ from the ones in the original theme, as probably it wasn't very clear what categories in Emacs map to what categories in Vim.

[jtbx]

I don't have the context to this but Catppuccin, generally, should only modify the colours in a port and not change the font size / shape / etc. We should always rely on defaults wherever possible so the introduction of this PR feels like we're modifying this elsewhere where we shouldn't be?

If this is introducing new customisation options then I'd personally push back against it as you shouldn't need to configure font settings via a colourscheme.

@sgoudham Variables such as catppuccin-enlarge-headings have been around since the beginning, but I think removing them would be just fine.

[jtbx]

@bbatsov Thanks! I looked into this on #189 and found that different modes use these faces for different things, e.g. nix-ts-mode uses variable-name-face for property names, and c-ts-mode uses variable-name-face for property references. So simply adding a foreground colour to variable-name-face might looks fine for some modes such as elisp mode but it might make c-ts-mode a bit disconcerting due to the amount of colour. It's tricky, it's almost entirely based on how modes use faces and maybe it could work if every mode used every face for the same thing. But I'm afraid it doesn't really work well for a lot of modes...

[bbatsov]

Yeah, it's true that different modes use this face differently, but I still think it's weird to treat variable definitions and uses in the same manner. Sadly, many major modes were put together hastily without consideration of the semantics of some font-lock-* faces which created a very messy situation across modes.

What about font-lock-doc-face? Would you be open to changing to something that resembles more the face for strings, as the neovim original theme does? (and Emacs themes typically work)

[sgoudham]

@sgoudham Variables such as catppuccin-enlarge-headings have been around since the beginning, but I think removing them would be just fine.

Yeah, I'd like to see them removed in a future PR.

[bbatsov]

@sgoudham Sure, I can do this. Should I remove only catppuccin-enlarge-headings or all of the configuration options?

[jtbx]

catppuccin-enlarge-headings and all the catppuccin-height- variables please :-)

[bbatsov]

See #217.