Add rubocop and standardrb formatters for Ruby

[knu]

Kudos for the multiple formatter support!

[lassik]

Thank you very much for adding more formatters!

Can you make these changes:

• Keep formatter names and definitions in alphabetical order (i.e. Ruby (rubocop, rufo, standardrb) and the like).
• Extract the bundle exec code that is common to rubocop and standardrb into a utility function format-all--buffer-ruby. The formatter definition could then call (format-all--buffer-ruby "standardrb" "-a "-s").
• The shell-command-to-string can probably be replaced with (with-temp-buffer (insert-file-contents ...) (re-search-forward ...)).

Would the existing Ruby formatter, rufo, benefit from using format-all--buffer-ruby as well?

[lassik]

Hmm. We've had discussions of local-formatter support (e.g. #33) and bundle exec is kind of in that territory. We can go with a `format-all--buffer-ruby´ function for now, but should probably make a generic solution to project-local formatters later.

[knu]

@lassik Thanks for the review! How does it look now?

[lassik]

Thanks for putting a lot of effort into this!

What does ruby -ne 'print unless 1../^={20}$/'" do, and could we implement it in Emacs Lisp? That way we'd avoid depending on bash which isn't installed on BSDs and small Linux distros by default.

[knu]

It removes warnings that Rubocop generates from the output. Rubocop is basically a very noisy linter and it emits warnings to stdout where the formatted source code is also output. That's why I proposed adding --stderr, which got successfully merged. It will take some time until everyone starts to use a version of Rubocop with the --stderr option added, though.

As for processing within Emacs, the current internal API format-all--buffer-hard does not provide a way to process the output of a command, so I chose to do that with shell pipe. I also thought it'd be more performant when it's very common Rubocop emits a huge amount of warnings that is often longer than the formatted source code.

And yeah, I'm also the one with a BSD background who hates Bash-ism, but in reality, most popular ruby installation managers like rbenv and rvm already depend on Bash and I don't think it would be a big problem.

[lassik]

The addition of --stderr is very good news - thanks for talking to upstream. If that feature is already out in a published version, we should go with it and leave out the hacks. If people encounter problems, could we just tell them to upgrade rubocop? format-all has no rubocop support so far, so it's not like we'll be breaking people's current workflows if we require the latest versio of rubocop.

[knu]

Yes, v1.4.0, the first release with the --stderr support seems to be rolled out today. Looks like they are preparing for v1.4.1 and I suspect v1.4.0 has a problem, though.

In any case, removing the hack too soon will make developers' lives hard until their projects get to upgrade Rubocop. I guess it'll be OK to force an upgrade in a couple of months from now.

[lassik]

I'd prefer to avoid putting hacks into format-all as far as possible, since they easily get left in and it gets hard for people who didn't to write them to understand what they do and whether they're still relevant.

Since format-all currently has no Rubocop support, could we wait until 1.4.1 is published and working normally before adding Rubocop to format-all? If it only takes a month and we can avoid hacks, we can wait. If you need rubocop today, you can always use a private branch of format-all until then.

[lassik]

(#42 is an earlier example where I opted not to merge a formatter since its interface was difficult to use reliably. One of the PHP formatters was another. These are pretty much the only ones; most formatter authors are happy to listen to feedback and provide a reliable interface in the next version.)

[lassik]

@knu RuboCop is already at 1.6.1; it's 18 days since the release 1.4.0 that added the --stderr flag. Do you think we could rely on that flag?

[lassik]

@knu Can you push a version of this patch that assumes RuboCop has --stderr support? We can probably rely on it by now.

[lassik]

Sorry, I hadn't noticed you had updated the patch. Thanks for your work! Now in master; can you check that it works?