Improved C syntax highlighting for Vim(github.com)
github.com
Improved C syntax highlighting for Vim
https://github.com/pulkomandy/c.vim
30 comments
AFAIK vimscript after/syntax/ files still work fine with neovim. But if you're on neovim 0.5+ I would recommend using the tree-sitter highlighting integration instead :)
Is tree-sitter highlighting enabled by default?
It is not, but there's an installation and configuration guide here [0] that I found pretty easy to follow
[0] https://github.com/nvim-treesitter/nvim-treesitter
[0] https://github.com/nvim-treesitter/nvim-treesitter
the blue parenthesis are very hard to read in his screenshot
other than that, looks very nice, good job!
other than that, looks very nice, good job!
The parentheses color are not caused by this script, but by my usage of rainbow parentheses (some variant of https://github.com/luochen1990/rainbow) which I have configured for my usual light background vim theme.
I did not spend time to set up a more empty vim configuration to take the screenshots.
The script does not introduce any new colors, it just changes what is highlighted as cType.
It does change the color of parentheses for "if" statements to be the same color as the keyword. I am undecided if I should keep that or not. Opinions from people not using rainbow or similar plugins are welcome.
I did not spend time to set up a more empty vim configuration to take the screenshots.
The script does not introduce any new colors, it just changes what is highlighted as cType.
It does change the color of parentheses for "if" statements to be the same color as the keyword. I am undecided if I should keep that or not. Opinions from people not using rainbow or similar plugins are welcome.
Really, really cool!
Unfortunately doesn't work for me, it complains about not having definitions for cppType and cppStatement. Looking in the file it undefined them [1] [2], putting them back just messes with the formatting (as the code comments suggest). It looks like this was something that was changed from the original code [3].
[1] https://github.com/pulkomandy/c.vim/blob/main/cpp.vim#L2
[2] https://github.com/pulkomandy/c.vim/blob/main/cpp.vim#L6
[3] https://github.com/pulkomandy/c.vim/commit/4159fe507815f897f...
[1] https://github.com/pulkomandy/c.vim/blob/main/cpp.vim#L2
[2] https://github.com/pulkomandy/c.vim/blob/main/cpp.vim#L6
[3] https://github.com/pulkomandy/c.vim/commit/4159fe507815f897f...
I highly recommend looking into Treesitter for anyone who wants to improve syntax highlighting.
I know its supported today natively in neovim. Not sure about regular vim or other editors/ides.
But its a massive improvement on the otherwise regex approach to syntax highlighting every editor takes.
I know its supported today natively in neovim. Not sure about regular vim or other editors/ides.
But its a massive improvement on the otherwise regex approach to syntax highlighting every editor takes.
I'm on neovim nightly and recently turned off treesitter. The highlighting is nice but it consistently was giving me segfaults while autocompleting, adds substantially to my startup time, and renders the editor completely unresponsive when opening large files. I think it's worth mentioning it's still early in development before highly recommending it, but it's cool to tinker with if you're in the mood for it.
> renders the editor completely unresponsive
I thought one of the points of neovim was to support true async stuff. So in theory, it should be possible to just open the file without syntax highlights but still be able to edit?
I thought one of the points of neovim was to support true async stuff. So in theory, it should be possible to just open the file without syntax highlights but still be able to edit?
I'm not disagreeing with you (because I don't know the original 'points' of neovim and I've never used it) but plain vim now (as of v8 I think) supports 'async stuff'. I'm sure neovim has other benefits to some, but that alone at least I think is no longer one.
Vim only supports async stuff because vim had to keep up with neovim which first introduced async support.
I think vim's time is nearly over. Just as it replaced vi, neovim will replace vim.
It may not get to the ubiquity of being installed everywhere by default, but certainly as the go to cli editor on devs' work and personal machines
I think vim's time is nearly over. Just as it replaced vi, neovim will replace vim.
It may not get to the ubiquity of being installed everywhere by default, but certainly as the go to cli editor on devs' work and personal machines
This might be the push I need to finally make the switch to Neovim.
'All' of the (three or so?) neovim plugins I've come across wanting to use, and found Ah damn, 'neovim' in the name, work just fine in vanilla vim, FYI.
I don't know how much (or if anything) a plugin has to do to support it, but there's some kind of python RPC thing that allows it. IME it's been install that once, and neovim plugins 'just work'. (But I have only found/tried ones that explicitly mention it.)
(Edit, this: https://github.com/roxma/vim-hug-neovim-rpc)
I don't know how much (or if anything) a plugin has to do to support it, but there's some kind of python RPC thing that allows it. IME it's been install that once, and neovim plugins 'just work'. (But I have only found/tried ones that explicitly mention it.)
(Edit, this: https://github.com/roxma/vim-hug-neovim-rpc)
make sure you use versions above 0.5
It’s kind of janky, but my current strategy is to parse my code base with libclang and dump a vim script file that adds all of the types, enums, function declarations etc. as literal syntax keywords. I also generate a tag file at the same time.
Do you have the code for this or a writeup somewhere? I'd be interested in trying out this approach.
I extracted it out of one of my projects and put it into its own git repo here: https://github.com/DaveP1776/clangtags
There’s still some project-specific stuff baked in, but that’ll show the idea.
There’s still some project-specific stuff baked in, but that’ll show the idea.
The default syntax highlighting for most of the languages I've used in vim is pretty bad. Usually people will download plugins to resolve it. The syntax highlighter for HTML also loads in the syntax highlighter for visual basic for reasons I don't really understand.
Probably legacy that 20 years ago VBscript could be used instead of JavaScript in IE.
More likely due to ASP, VBScript mixed into HTML server-side much like PHP.
VBScript could, and occasionally was, used client-side, but it was very rare in my experience. Outside of articles pushed by MS the “same language on server and client” angle didn't hold enough water to override the “only supported by IE” issue even when IE had ~90% market share in the early 2000s.
VBScript could, and occasionally was, used client-side, but it was very rare in my experience. Outside of articles pushed by MS the “same language on server and client” angle didn't hold enough water to override the “only supported by IE” issue even when IE had ~90% market share in the early 2000s.
use neovim above 0.5 that has native LSP support and use treesitter
I havent used syntax highlighting in 8 years or so (global-font-lock-mode 0)
highly recommend it, if you could try.
for example this code[1]:
I think colors break the flow of code in unintended ways, and mistreat comments (either overvalue with some pink color or undervalue with some toned down gray), and almost all themes make keywords extremely important.
[1] https://github.com/jackdoe/programming-for-kids/issues/3#iss...
highly recommend it, if you could try.
for example this code[1]:
// the code will run twice
bool panic = true
while (true) {
panic = !panic;
if (panic) break;
}
I think colors break the flow of code in unintended ways, and mistreat comments (either overvalue with some pink color or undervalue with some toned down gray), and almost all themes make keywords extremely important.
[1] https://github.com/jackdoe/programming-for-kids/issues/3#iss...
That code is even easier to read with semantic highlighting than "basic" syntax highlighting. That said, syntax highlighting definitely helps when handling embedded strings, differentiating between value types, figuring out if something is a macro, function or global variable (which is important, as in a language like C++, the behaviour of `foo(x++)` depends on which of the above it is)
Highlighting doesn't tell you what's important, it tells you what's different. You should find a scheme that roughly weighs what's important to you;
Highlighting doesn't tell you what's important, it tells you what's different. You should find a scheme that roughly weighs what's important to you;
I've tried the no highlighting approach. It doesn't work for me. Glad it works for you, but I'll take my candy colors over nothing any day.
Ok, but GL acceleration for HaikuOS when?
JK, good luck for the author.
JK, good luck for the author.
Cool, thanks
Maybe in ~/.config/nvim/after/syntax/