Highlights are based on the literal syntax only, hence often incorrect

[wookayin]

Highlights in vim-flog buffers are based on the syntax only rather than its structure (as per the git log format), which can be incorrect if commit messages contain some characters as shown in the above screenshot. Although the commit messages in the screenshot are written a bit artificially, I can see similar issues on several in-the-wild git repositories.

For example:

• [ alphanumericwords ] : recognized as commit hash
• ( ...something ... ) : recognized as refspec
• { ...something ... } : recognized as authors

So any parenthesis, brackets, braces in a commit message will be recognized by flog. Or, if the format string doesn't wrap the commit hash (%h) with [...], it won't be highlighted as flogHash. Similar things can be said for flogAuthor without {...}, etc.

Would it be possible to improve syntax for the highlights so that it could be agnostic to the specific git log format used by Flog (i.e., the -format args)?

[rbong]

Would it be possible to improve syntax for the highlights so that it could be agnostic to the specific git log format used by Flog (i.e., the -format args)?

To properly support both strictly correct highlighting which works with custom log formats, Flog would have to implement a parser for the -format command and dynamically generate highlight groups.

I think the added complexity would not be worth it, even if I were not trying to keep Flog light, and there could be a performance hit as well. The simple highlight groups are the tradeoff for custom log formats.

One thing you could do is use the AnsiEsc plugin with Flog. This will use shell highlighting in Flog, however there will be a performance hit, and you will have to use color items (ex. %CredThis text will appear in red%Creset) in your log format. Instructions here.

There has been some interest as well in adding an option to insert hidden characters into the format to improve highlight groups. However, you would have to include these characters in your output format as well. Let me know what you think of this option.

Finally I have made some syntax fixes based on your example. This eliminates ref highlighting sometimes when it can, and it eliminates a bug as well.
You can see it helps but there are still issues.

I know none of this is exactly what you want to see, but I hope it helps.

[wookayin]

Thank you @rbong for the detailed and fast response. I understand this would be tricky and difficult to implement. Given that the content of commit logs are not generated by the plugin but by git log ..., we do not have much thing under control. Now I think that, without knowing the format string (technically, even if the plugin knows it), there will be ambiguity in parsing so there will be no perfect/ideal syntax-based approach to have an always correct highlighting.

That said, using AnsiEsc.vim sounds like a good workaround for this. The approach of #64 also sounds interesting.

[rbong]

The only viable true solution right now is to use hidden characters.

Because I am not very interested in this feature, I can't think of a nice user experience, and the last time I benchmarked inserting a ton of hidden characters into the output it was not performant, I'm unlikely to fix this issue unless if there's a lot of support.

Also AnsiEsc support has been removed from v2 since the biggest reason it was implemented (graph branch color) has been resolved. If there is interest in bringing it back, I may just implement Ansi code highlighting myself since it would be much more controlled and performant.