Make typechecker errors vim quickfix friendly

[lekemula]

A minor change to the typechecker output, but a life-changing one for Vim/Emacs users.
(I mention only Vim in the title, because that's what we vim-ers do :) )

This is similar to: https://docs.rubocop.org/rubocop/formatters.html#emacs-style-formatter

Everything in Vim revolves around something called quickfix. It's essentially a list of "things needed to be fixed" where you can easily navigate between next/prev/first/last, and do a lot more around them.

Among other things, one can run a terminal command and have this list populated; for example:

cexpr system("bundle exec solargraph typecheck --level strict"), and have this convenient list populated:

[lekemula]

Hmm.. I'm not sure why overcommit fails on typechecking, when the typechecker step itself succeeded 🤔

[apiology]

It broke because overcommit is an automated tool that relies on the formatting of our messages already - see https://github.com/sds/overcommit/blob/main/lib/overcommit/hook/pre_commit/solargraph.rb

Maybe we can act like rubocop, make this a command line argument to specify the output format and keep the current default?

[lekemula]

It broke because overcommit is an automated tool that relies on the formatting of our messages already - see sds/overcommit@main/lib/overcommit/hook/pre_commit/solargraph.rb

Maybe we can act like rubocop, make this a command line argument to specify the output format and keep the current default?

@apiology Thanks for the hint - I wonder, though, how much it makes sense to keep both formats when essentially they differ only by a single character. Would it make more sense to adapt the MESSAGE_REGEX on the overcommit side to look for both (-|:)?

[apiology]

Thanks for the hint - I wonder, though, how much it makes sense to keep both formats when essentially they differ only by a single character.

I think the option is going to exist eventually anyway - there are tools like reviewdog that I'd like to integrate with that take different formats entirely.

As to what the default should be - I guess my priorities would be:

1. Enable as many new users without configuration as possible.
2. Don't break existing users.

If we had many more existing users, I'd probably flip those, but I think most of our user base is yet to come once the word gets out that typechecking Just Works here. I'd say maybe 10% of users would go through the trouble to configure their editor to match the output of tools.

https://railsdeveloper.com/survey/2024/

Looks like our ideal default would be something compatible with VSCode, Vim and RubyMine out of the box - and if we had to choose, maybe count up points by how much coverage each gets.

That said, I have no idea if this is that format or not--we'd probably want to test before changing anything. My editor of choice (emacs) is only 3% so I'm resigned to reconfigure if needed ;)