Re: maintain flymake.el

[Sebastian Wiesner]

2013/12/16 Jan Djärv <address@hidden>:
> Hello.
>
> 16 dec 2013 kl. 17:48 skrev Sebastian Wiesner <address@hidden>:
>
>> 2013/12/16 Jan Djärv <address@hidden>:
>>> Hello.
>>>
>>> 16 dec 2013 kl. 15:32 skrev Ted Zlatanov <address@hidden>:
>>>
>>>> On Sun, 15 Dec 2013 19:31:46 +0100 Sebastian Wiesner <address@hidden> 
>>>> wrote:
>>>>
>>>> SW> 2013/12/14 Sebastian Wiesner <address@hidden>:
>>>>>> I hope to finish the document by tomorrow evening, and will come back
>>>>>> if it's done.
>>>>
>>>> SW> I have completed the document now.  The final version is to be found
>>>> SW> at https://github.com/flycheck/flycheck/wiki/Flycheck-versus-Flymake.
>>>> SW> It's a thorough write-up of the differences and similarities between
>>>> SW> Flycheck and Flymake, and probably also a comprehensive summary of the
>>>> SW> current issues and weaknesses in Flymake.
>>>>
>>>> SW> Again, it's probably unfairly biased towards Flycheck.  I tried my
>>>> SW> best to be neutral, but I consider Flycheck superior and think that
>>>> SW> the design and implementation of Flymake are somewhat broken, so I may
>>>> SW> have failed to properly account for Flymake's features and strengths.
>>>> SW> Please excuse this, and feel free to correct any mistakes I may have
>>>> SW> made.
>>>>
>>>> SW> Please also suggest improvements, such as additional aspects which
>>>> SW> should be covered, or report issues, such as missing details in the
>>>> SW> comparsion.
>>>
>>>
>>> You are missing the big think that separates flymake and flycheck. Flymake 
>>> uses makefiles, flycheck does not.  This means to be able to use flycheck 
>>> on a large C/C++ project you have to maintain includes and defined in both 
>>> makefiles and as lisp variables for flycheck.  Flymake does not have that 
>>> problem, you just add one rule for it in the makefiles, re-using all 
>>> definitions and include paths.
>>>
>>> This is really a showstopper for flycheck, even if it has some nicer GUI 
>>> stuff.  It is really only usable for small projects.
>>
>> You can easily define your own syntax checker:
>>
>> (flycheck-define-checker 'c-makefile-checker
>>  :command ("make" "CC=clang" "build")
>>  :error-patterns
>>  ((info line-start (file-name) ":" line ":" column
>>            ": note: " (message) line-end)
>>   (warning line-start (file-name) ":" line ":" column
>>            ": warning: " (message) line-end)
>>   (error line-start (file-name) ":" line ":" column
>>          ": " (or "fatal error" "error") ": " (message) line-end))
>>  :modes (c-mode)
>>  :predicate (lambda () (not (buffer-modified-p)))
>>
>
> "Easy" is in the eye of the beholder.

It was easy enough for many people only unfamiliar with Emacs Lisp, as
the number of contributed syntax checkers demonstrates.

>> The error patterns are for Clang.  Adapt the accordingly, if you are
>> using a different compiler.  The predicate makes sure that Flycheck
>> only uses this syntax checker after the buffer was saved, because
>> calling out to the build system after every change is probably not a
>> good idea.
>>
>> Then just register the new syntax checker, and disable the built-in
>> Clang checker to avoid conflicting error messages:
>>
>> (add-to-list 'flycheck-checkers 'c-make-file-checker)
>> (setq-default flycheck-disabled-checkers '(c/c++-clang))
>>
>> Feel free to copy this to your "init.el".
>>
>> Flycheck does not include this syntax checker for two reasons:
>>
>> - No one contributed it :)
>> - It's hard, if not impossible, to get this right in a generic way.
>
> Yet that is what compile mode tries to do.  So use those.

I am aware of the huge number of compilers supported by compile mode,
but that is not what I referred to.

Compile Mode solves a difference use case, and thus is subject to
other constraints than Flycheck.  Most notably, it's whole purpose is
to call to the complete build systems, trigger its side effects and
probably wait minutes for the build to complete.  The user expects
that.

Flycheck's concern, however, is syntax-checking, on-the-fly, and in
background.  As such, I can do none of the above.   It cannot wait
minutes for a build to complete, and it cannot risk to trigger
arbitrary side effects caused by a poorly written Makefile.

>> But again, you know your projects, and nothing stops you from
>> definining your own syntax checker just for these projects.  Try it.
>> Really.  It's easy.
>
> I won't bother as you stated that Flycheck won't be part of Emacs.

I am sorry for you then, and have nothing more to say.