Re: Flymake refactored

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

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Oh, I don't forsee any major difficulty in writing an nxml backend for
> flymake, *IF* we limit ourselves to the goal of making it work.  But if
> we want it to work about as well as nxml-mode itself, it'll be harder.

Maybe you're right for the bit where (from what I gather from your
comments) nxml-mode concentrates on the visible part of the buffer. Not
unrelated, that's where nxml-mode and Flymake differ in their
promise. Flymake's is to check the whole buffer, letting you know in the
mode-line how many errors you have, and quickly letting you navigate
between them. I think that, by design, that part could never be "as well
as nxml-mode". On the other hand, perhaps it would be useful to ask
backends to concentrate on this region first, then elsewhere.

>>>> Didn't do this too.  If we mark it obsolete, what's the "use instead"
>>>> message?
>>> Don't know.  flymake-diagnostic-functions?
>> Yeah, but right now that's saying "this bit is obsolete, go write a
>> replacement and then use that instead. good luck "
>
> I thought you were the one saying that flymake-proc is all legacy and
> will be replaced.  I don't think anyone has claimed that flymake-proc is
> *currently* obsolete, just that the plan is to retire it at some point
> (this point being presumably after a replacement is written).

OK then. I guess I misunderstand the graveness of a make-obsolete.

>> Regarding the merge to emacs-26, do you see anything else we need to
>> iron out before it?
>
> Maybe just this issue of letting backends tell flymake.el whey they're
> done (and letting flymake tell backends to abort the currently running
> check)?

Done, and rebuilt a prettier history in the branch
scratch/flymake-refactor-cleaner-for-emacs-26.

Will still fix some more longstanding bugs and then merge to
emacs-26. Bugs and finishing touches can still be fixed there.

João