Refactoring flymake.el

[joaotavora@gmail.com (João Távora)]

Hello all,

I've been away from this list and away from hacking for a while now, but
I thought I'd return with a modest proposal for refactoring flymake.el
and making it more useful to users and also third-party extensions.

Specifically, I'm thinking of separating its UI and from its
diagnostics-generating backends. Currently the latter rely purely on
lanching external processes and examining their output, but recent
experimentations with the LSP (Language Server Protocol) showed that to
not always be the case. Another example is Elisp itself, which is
syntax-checkable without an external tool.

If you are thinking: "Hasn't flycheck.el done all those things
already", the answer is probably yes, but flycheck has been around for
some time and isn't in Emacs, whereas flymake.el is. Anyway, that is a
whole different topic. I believe flymake.el's flaws can be fixed and it
can be made as good as, if not better than, flycheck.el.

I'm also committed to maintaining backward compatibility with the many
flymake.el configurations out in the wild.

I've already done some work, but before I invest much more, i'd
like to know if there's any interest in these efforts. 

So here's what I have so far. In a newly pushed git branch:

  scratch/flymake-refactor

there are just two commits right now:

  eb34f7f5a2 Split flymake.el into flymake-proc.el and flymake-ui.el
  13993c46a2 Add flymake-backends defcustom

The first commit makes flymake.el into just a stub that `require's
flymake-ui.el and flymake-proc.el. flymake-ui.el contains the flymake
UI: the minor-mode, functions dealing with overlays, generic error
containers, etc... flymake-proc.el has all the functions dealing with
external processes, Makefiles, temporary mocks, and all that junk. This
segregation was done very roughly, it may need some fine-tuning.

The second commit adds a very simple indirection variable, a
flymake-backends defcustom, which is currently only used by flymake-proc
to add its backend.

The only testing I've given it is interactive and the Emacs suite test
case.

Going forward I'm thinking of:

1. Segregating functions flymake-proc.el into their own namespace
generously establishing obsoletion aliases for user-visible functions.
2. Adding an experimental emacs-lisp backend based on bytecomp.el
3. ...
4. Checking in again to see if it there's still interest :-)


João