On 6/16/18 6:32 PM, João Távora wrote:
> There was little discussion on this before 26.1 because it was all
> kinda rushed, because Dmitry is the maintainer of ruby-mode, and most
> importantly, nobody objected (much less I, who welcomed the enthusiasm
> for using the new API). So even though Emacs 26.1 is a month old, the
> conservative stance is now to keep default.
To be clear, I only did the most simple thing (and indeed, nobody
objected). So anybody who doesn't like the behavior in 26.1, you're
welcome to try out pretest versions. That's what they're for.
That said, I'm totally fine with adding a new value for
ruby-flymake-use-rubocop-if-available (like `auto'), and make it the
default. Because I personally have also been hit by it turning on in
projects where it's not exactly needed. Like Ruby Stdlib, certain gems,
etc. And older projects, yes.
I suggested the following already. Nobody responded to it so far:
"I suppose we can abort if no ruby-rubocop-config file is found."
Meaning, if there is no .rubocop.yml is any directory containing the
current file, RuboCop is not used.
The main reasons I'm putting this off is avoiding calling
locate-dominating-file twice, while keeping the simplicity of having two
different diagnostic functions available for user use, is a bit tricky.
> * On the practical front, I personally dislike defcustom and prefer
> having flymake backends separate, so instead of having
> ruby-flymake-auto checks the defcustom, I advise Petko to use a
> directory-local variable in the project configuring
> flymake-diagnostic-functions to either ruby-flymake-simple or
> ruby-flymake-rubocop, i.e. some .dir-locals.el containing this
>
> (...
> (ruby-mode . (...
> (flymake-diagnostic-functions ruby-flymake-simple)
> ...))
> ...)
>
> Won't this suffice as a per-project (almost zero) configuration?
That still leaves the question of a reasonable default. But if you ask
me, removing the custom variable a making the "auto" behavior "always
on" will also be good.