unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Sebastian Wiesner <lunaryorn@gmail.com>
To: "Jan Djärv" <jan.h.d@swipnet.se>
Cc: emacs-devel <emacs-devel@gnu.org>
Subject: Re: maintain flymake.el
Date: Mon, 16 Dec 2013 20:03:44 +0100	[thread overview]
Message-ID: <CALf2awStyBXhoeSqpYoK6S-H0zjKu5rbub0GUX0aVEQX12ebrg@mail.gmail.com> (raw)
In-Reply-To: <C0D98F22-A6D5-4104-ACBD-E7ECD206A27F@swipnet.se>

2013/12/16 Jan Djärv <jan.h.d@swipnet.se>:
> Hello.
>
> 16 dec 2013 kl. 17:48 skrev Sebastian Wiesner <lunaryorn@gmail.com>:
>
>> 2013/12/16 Jan Djärv <jan.h.d@swipnet.se>:
>>> Hello.
>>>
>>> 16 dec 2013 kl. 15:32 skrev Ted Zlatanov <tzz@lifelogs.com>:
>>>
>>>> On Sun, 15 Dec 2013 19:31:46 +0100 Sebastian Wiesner <lunaryorn@gmail.com> wrote:
>>>>
>>>> SW> 2013/12/14 Sebastian Wiesner <lunaryorn@gmail.com>:
>>>>>> 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.



  reply	other threads:[~2013-12-16 19:03 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-06 17:01 maintain flymake.el Leo Liu
2013-12-06 17:38 ` Stefan Monnier
2013-12-06 17:50 ` Ted Zlatanov
2013-12-07  2:21   ` Leo Liu
2013-12-14 21:23   ` Sebastian Wiesner
2013-12-15 18:31     ` Sebastian Wiesner
2013-12-16 14:32       ` Ted Zlatanov
2013-12-16 16:06         ` Jan Djärv
2013-12-16 16:48           ` Sebastian Wiesner
2013-12-16 18:30             ` Jan Djärv
2013-12-16 19:03               ` Sebastian Wiesner [this message]
2013-12-16 16:57         ` Sebastian Wiesner
2013-12-16 17:26           ` Glenn Morris
2013-12-16 18:24             ` Sebastian Wiesner
2013-12-16 20:55               ` Glenn Morris
2013-12-16 21:00                 ` Sebastian Wiesner
2013-12-16 21:30               ` Lennart Borgman
2013-12-16 21:52                 ` Glenn Morris
2013-12-16 17:28           ` Ted Zlatanov
2013-12-17  0:12             ` Leo Liu
2013-12-17  0:02         ` Leo Liu
2013-12-17  6:37 ` Arne Jørgensen
2013-12-17 15:45   ` Leo Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALf2awStyBXhoeSqpYoK6S-H0zjKu5rbub0GUX0aVEQX12ebrg@mail.gmail.com \
    --to=lunaryorn@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=jan.h.d@swipnet.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).