Detect Git commit summaries not following the 50/72 rule

[ebkalderon]

One aspect of the standard gitcommit syntax highlighting present in Vim and Neovim that I particularly love is that it includes built-in rules that follow the 50/72 rule of writing Git commit messages. That is:

1. If the commit summary extends beyond 50 characters, the syntax highlighting changes accordingly to gently warn you to shorten it, if you can.
2. If the commit message extends beyond 72 characters, the syntax highlighting warns you that GitHub will automatically truncate your message (sometimes mid-word), insert ..., and overflow the rest into the commit message body, and you should definitely shorten it if you'd like your summary to remain intact.

This is helpful for folks writing commit messages who are looking to keep them nice. For reference, an example of such assistive highlighting in Neovim (using the standard gitcommit.vim syntax) is shown below:

On the other hand, this is how tree-sitter-gitcommit (installed via nvim-treesittter on my machine) highlights the same commit message:

It'd be great if this TS parser could apply similar syntax rules as those used in Vim/Neovim to detect poorly formed commit messages as they're being written, enabling editor color schemes to highlight these malformed sections accordingly. Thanks for maintaining this great open source parser!

[gbprod]

Hey!

Thanks for your feedback, it's really interesting!

Currently, this parser change the syntax color you if the message is longer than 50 characters :

What is the colorsheme you use ?

Anyway, I really like the 50/72 rule ! I will try to implement it soon!

[ebkalderon]

That's wonderful! 🎉 I currently use tamelion/neovim-molokai as my primary color scheme.

[stevenxxiu]

Could there be some way to opt out of this? I always soft line wrap my Git commits, and never hard wrap.

Having some arbitrary line length for the subject and summary, that can't be changed, feels overly restrictive.

[EDIT] I managed to remove the warning colors with the following command, but I think some official option would be better.

vim.cmd('highlight link @comment.warning.gitcommit @spell')

[gbprod]

Hey @stevenxxiu , thanks for your feedback, I wasn't aware of this change in treesitter 😅
Otherwise, you found the good way to opt-out from this ;)

[stevenxxiu]

Thanks, but do you think you could add an option to actually configure this, instead of hard coding it? My way to opt-out seems more like a hack more than anything.

[mkalinski]

I'm also looking for a way to disable this. I'm not knowledgeable about treesitter, but the highlight link command seems off to me, even if it works:

1. Linking to @spell seems weird. Wouldn't it be more correct to link to @none? It also works, though I couldn't find any documentation on @none despite it being used all over the place in treesitter.
2. The core problem seems not to be @comment.warning.gitcommit group but that this (overflow) match gets assigned a warning highlight unconditionally. Is there no real way to disable that in the first place?
3. I'm not sure what the linked "this change in tresitter" implies. Does it somehow affect the possibility of opting out of this warning?

[gbprod]

Hello,

1. You're right, linking to @spell is weird, it's more correct to link to @none. The best way to disable it is to add this in your lua neovim config : vim.api.nvim_set_hl(0, "@comment.warning.gitcommit", { link = "@none"}) (I will add a section in the readme for that)
2. This parser only mark that there is an overflow, the highlight of this node as a warning is done by nvim-treesitter, not by the parser. I can't add an option here to disable the parsing of this node. I think it's a good thing to parse this node and let the user decide if he wants to highlight this or not.
3. In first place, as said here, I would prefer to let user add the config to set this highlight group, but this was added to the default highlights of nvim-treesitter sooner than expected 😅

I hope that I answer all your questions 😅

[stevenxxiu]

I think it's a good thing to parse this node and let the user decide if he wants to highlight this or not.

What about a configurable length? Line lengths, wrap lengths, ruler positions, etc. are always configurable. This is the first time I've seen something that's not.

[gbprod]

Feel free to open a pull request if you find a way to do it 😉

[mkalinski]

After I fiddled with this, I found that just adding a highlight link to @none in init.lua might not work depending on how your colorscheme behaves, so consult the manual for that as well, if that's the case.

EDIT: Another way to try and make sure the highlight sticks is to put it in {init dir}/after/ftplugin/gitcommit.lua.

My problem with overriding @comment.warning.gitcommit highlight is that the group's name is very vague, and could be used for some other purpose than bothering the user about line length overflow. It would be better if there was a group specific to oveflow that could be disabled.

Judging by what I've seen so far in other cases, treesitter is pretty much impossible to configure on the user side (the answer in each case seems to be "write your own queries file from scratch"), so I doubt it's possible to add configurable length in this case.

I'm disappointed in general in Neovim's seeming insistence to force the 50/72 rule on everyone without any configuration options, both in the default syntax plugin and now in treesitter plugin. Imagine if Nvim decided that tabstop can no longer be anything else than 8, and any line longer than 80 characters will be highlighted as error, just because Linus said that's how he likes to format kernel code.

[gbprod]

I understand your point.
Anyway, this project only parse different parts of gitcommit syntax. In Neovim, the highlight is done by nvim-treesitter, you can find the pull request introducing this here : nvim-treesitter/nvim-treesitter#6222.

I don't know if we should highlight overflow in commit body by default but maybe you can open a issue (or a pull request) on nvim-treesitter project to start a discussion about that.

[stevenxxiu]

IMO the overflow detection shouldn't be in this repo at all, if its length cannot be configured, or if it cannot be turned off.

This belongs in another plugin, not in a syntax parser.

[gbprod]

I've asked the reddit community about that : https://www.reddit.com/r/neovim/comments/1cm5zir/question_should_i_commit_summaries_not_following/
@ebkalderon @mkalinski @stevenxxiu @mhanberg feel free to contribute :)

[mkalinski]

I don't have a Reddit account, and I don't think it's worth creating one just for that discussion. But I can roll out my arguments here, for your consideration. 😃

I don't want to come off as someone who just hates the 50/72 convention for no reason. I'm indifferent to it. But I also work with projects where no one heard of that rule, and the commits are expected to be formatted in a certain way that's incompatible with it. Nobody is going to overhaul a projects conventions because someone on the other side of the net decided that 50/72 is just the best. Saying that all tools adhere to 50/72 because Github does is very myopic.

Perhaps the strongest argument I've seen is that the pre-treesitter syntax script also has this overflow highlight behaviour, so doing it in treesitter is just keeping backwards compatibility. I think it's the only reason why anyone proposed that a syntax highlighter should be concerned with style errors, because as you and others have noted, that's not what's normally expected at all.

My counter arguments would be:

• The author of Vim's gitcommit syntax script is Tim Pope, who also came up with the 50/72 rule in the first place. If you allow me to be cynical, I think this syntax script was merged into Vim because he was long known for very high quality contributions to Vim, but also wanted to evangelize his rule.
• Despite the above, at some point in history, Vim actually commented out the overflow highlight by default 😛 (just for clarity, Neovim also uses the same syntax file as part of including patches from Vim)

[Flimm]

If you're wondering like me why the overflow isn't being highlighted in a different colour any more, and you came across this issue, tree-sitter-gitcommit removed the overflow feature in this commit: aa5c279 (see #68).