bug#28808: [PATCH] Implement Python backend for Flymake

[João Távora]

Hi Lele,

Lele Gaifax <lele@metapensiero.it> writes:

>> A common trick here that old flymake (and also compile.el) use is to
>> define the variable's value as list (REGEXP LINE COLUMN TYPE
>> MESSAGE).
>
> I will try to better understand this, as I failed to see the benefit of adding
> that indirection... maybe the compile.el functionality is older than the
> ability to use explicit group numbers in the regexp?

The benefit is that if I switch to a checker that doesn't provide
COLUMN, for example, I won't be locked out with your
expression. Likewise if I do switch to a checker that emits errors where
I can clearly identify a TYPE.

> I'm curious here: why the need of autoload cookie, if the (only?) caller site
> lives in the very same source file? And if that's not only caller, why marking
> it private with the double dash?

Sorry for the noise. There is no need for the autoload cookie. I thought
you were changing a different file than flymake.

Don't use the cookie, use the double dash.
>
> More importantly: if we unconditionally activate the Flymake feature, instead
> of being an user's choice, then the python--flymake-setup function may go
> away, and the add-hook moved inside the python-mode function, it already
> contains lot of those...

That makes sense. But we don't (yet) "unconditionally activate" Flymake, we
simply set up the buffer so that a later activation of Flymake will be
met with agreeable conditions.

> See http://endlessparentheses.com/get-in-the-habit-of-using-sharp-quote.html
> for what I considered a "sound reason" :)

Obviously, I use sharp quote myself, just not in add-hook, as that is
the style I am familiar with. But if that is the style of python.el,
that's a good reason. It's not in the rest of emacs.

But I can explain what it bothered me: As you know, in the specific
Flymake-case, backends are functions. You might be tempted to put a
closure, like a (lambda (report-fn) ...) in
flymake-diagnostic-functions.

If you do that everything will work, except for the interactive messages
that mention names of backends, where intead of the name of the symbol
you see something very ugly like

#f(compiled-function (report-fn) #<bytecode 0x1d84599>)

So, for now, as a good practice, I thought it better to use just ' so as
not to encourage others to put closures there. 

Eventually, once function-put starts working for non-symbol functions
and I can set a name property there, closures will probably not only be
accepted but encouraged.