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 ;)

[lekemula]

@apiology I agree with all of your points here

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.

I'm not strictly against options, I'm just not sure how intentional the existing format was.

@castwide, is the existing format tailored to any of the editors, specifically to VSCode, or was it arbitrary? If the latter, I'd recommend going with a format similar to Rubocop's --emacs as the default and only for now, which I would expect to be more standard.

As per the overcommit failure, I think that we can easily adapt in a backward-compatible way, by extending the regex to cover both old and new cases.

[lekemula]

@apiology @castwide FYI prepared a draft PR for overcommit: sds/overcommit#873