Module: Flycheck

[jorgenschaefer]

flycheck has been requested as a feature a few times, so it would be good to have a way to use flycheck when available, otherwise flymake.

[wyuenho]

+1 for flycheck

[jrbalderrama]

Any news about flycheck support?

[jorgenschaefer]

One of the plans for elpy is to get it into GNU ELPA. From talking with the GNU folks, it seems that flycheck's author is one of the few people who refuse copyright assignment to the FSF to protect the code, so it is not going to be included in GNU ELPA, which makes it tricky to depend on. That moved this quite a bit down on the priority list for me.

[jrbalderrama]

I understand your point. In that case is it possible to provide an option disable completely flymake from elpy? Or removing flymake from 'elpy-default-minor-modes' is enough?

[stsquad]

This does seem to do what you expect

(when (require 'flycheck nil t)
  (setq elpy-default-minor-modes (delete 'flymake-mode elpy-default-minor-modes))
  (add-to-list 'elpy-default-minor-modes 'flycheck-mode))

[wyuenho]

Ideology impeding technological progress once again.

I'm going back to Jedi + EPC.

[vkurup]

Well, that sounds like an ideological choice too :) (Just joking!!!)

I use flycheck with elpy... it's as simple as @stsquad says.

[jorgenschaefer]

Ideology impeding technological progress once again.

I wouldn't be so fast to judge the author of flycheck. They might have non-ideological reasons for refusing the copyright assignment (although that's unlikely).

On a more serious note: The FSF requires copyright assignment to be able to enforce license claims. That's an annoying but sadly important legal consideration. Which is why copyright assignment is rather common for larger projects (like node.js and Ubuntu, and others). Refusing copyright assignment usually is based on a lot more ideological reasons than this.

Not that "ideological reasons" are bad in themselves. For example, the reason I wrote Elpy and am not using PyCharm is almost entirely ideological.

Now, instead of contributing to this project and providing, say, a patch to add flycheck support to elpy, or even just using the (trivial) workaround provided above (thank you!), you chose to come here and make an idiotic comment. Do you really feel so entitled to the work of others?

I'm going back to Jedi + EPC.

I am sorry to hear so. The Emacs Jedi people deserve better users than you.

[jorgenschaefer]

To get back to the technical points: I'm not using flycheck, so I'd be rather curious in what features flycheck provides that flymake doesn't. The main reason I have heard so far has been that flycheck has much cleaner code, but I haven't heard of any things that flycheck can do that flymake can't, or bugs in flymake that flycheck hasn't. I'd be very interested in those!

[gccinac]

I am exeriencing one problem with flymake that I am not having with flycheck. The problem occurs when I do a narrowing (C- n d). When this is done, then, all the texts around dissapears and only the function definition appears. In this case, with flymake, if there was an error in line 4 in the general file, for example, when doing the narrowing the same error will appear in line 4 (althougth this line is perfectly fine). I don't know if this was solved in a newer flymake version or not, as I'm using a little bit old flymake (0.3)

[jorgenschaefer]

This bug is still present in the flymake shipped with current Emacs (which seems to be 0.3), so at least it is annoying. Thank you!

[swsnr]

@jorgenschaefer Flycheck's documentation contains a comprehensive list of differences between Flycheck and Flymake. This document should answer your questions. Notable features in Flycheck which Flymake lacks are the error list, the ability to use multiple syntax checkers per buffer, manual syntax checker selection, customizable error message display and customizable syntax checker options.

As for copyright assignments, the question is not why I refuse to sign it. Rather, the question is why I should bother to sign it.

Copyright assignments do not come for free. They impose additional bureaucracy onto projects, present a barrier to external contributions, and imply a certain risk of being forced to reject valuable contributions due to unclear CA status. For a project that is as dependent on external contributions as Flycheck—more than half of the current syntax checkers were contributed—that is quite high a price, and I see not what a CA could offer to me or Flycheck's users to justify that price.

In other words, why should I impose additional bureaucracy onto Flycheck, put off potential contributors, and take the risk of rejecting valuable contributions, thus effectively decreasing the overall quality and coverage of language support on Flycheck? Merely for being able to put Flycheck into GNU ELPA or into GNU Emacs itself? That is a questionable benefit.

What could GNU ELPA or GNU Emacs offer to Flycheck, that the current combination of Github, Travis CI, Readthedocs, MELPA and Marmalade cannot?

And, asking you directly, what is so great about GNU ELPA that you take the effort of putting your project into it, as opposed to MELPA, MELPA Stable or Marmalade?

As for “ideological reasons”: It's not me that brought ideology into this. The FSF started the whole business of “free software ideology”, so I have a hard time to buy their claim that copyright assignments are a purely legal necessity. If that was true, how could big projects like Gnome, KDE, Linux get along without these? The FSF claims the copyright for purely ideological reasons, namely to violently propagate and defend their own ideology of free software, as manifested in the GPL, which as long gone beyond being a simple license and has become a political manifesto.

[jorgenschaefer]

@jorgenschaefer Flycheck's documentation contains a comprehensive list of differences between Flycheck and Flymake. This document should answer your questions. Notable features in Flycheck which Flymake lacks are the error list, the ability to use multiple syntax checkers per buffer, manual syntax checker selection, customizable error message display and customizable syntax checker options.

I am aware of that document, but I have not found something flycheck supports that flymake doesn't that is relevant to elpy. All these features are nice, but none of them make me go "elpy is worse off by sticking to flymake."

The "error list" is trivial to replicate by running the checker again (C-c C-v in elpy), multiple syntax checkers and checker selection are not relevant to elpy (minor feature that some users might want, so a small plus point), and the default display of flymake is quite sufficient.

Elpy would gain minor points by switching to flycheck, at the expense of another dependency and shutting itself out of GNU ELPA. This is a simple matter of weighing up benefits and drawbacks, and right now, the drawbacks for flycheck are outweighing its advantages for elpy.

There is a snippet of code above that enables flycheck in elpy. It's trivial to do. I'm not making it impossible for users to use flycheck, I just do not support it by default.

And, asking you directly, what is so great about GNU ELPA that you take the effort of putting your project into it, as opposed to MELPA, MELPA Stable or Marmalade?

Being available in a default installation of Emacs without the need to configure anything, for one.

Not having to suffer from the deficiencies of the other archives, too.

MELPA stable is a good idea but pretty much unusable, as it lacks a lot of packages and can not be combined with MELPA unstable as the latter overrides the former. It also does not solve the problem of vendor lock-in version numbers in MELPA unstable. Marmalade package upload has been broken for months (though nic is about to fix it I hear).

You will notice that elpy uses its own ELPA at the moment. This is not because I think it's so much fun to run my own archive.

As for “ideological reasons”: It's not me that brought ideology into this.

Indeed, it was some rude user who brought ideology into this. I picked it up in an attempt at a humorous statement. I did not intend to slight you; apologies for that. For all I care, this whole "you are ideological! NO YOU!" nonsense can stay out of this.

I'm quite fine with whatever reasons you have to keep flycheck out of GNU ELPA. I do not mind, and I do not think worse of you because of it. It's just one additional point of consideration for me.

[swsnr]

@jorgenschaefer It might be relevant to Elpy, though, that Flymake consumes more resources and is more fragile than Flycheck.

Besides, C-c C-v does not replicate the error list in Flycheck. It does not update automatically as the corresponding buffer is edited, or when another window is selected, and it does not highlight errors on the current line in the corresponding buffer.

---

Is being available in a standard Emacs installation by default a benefit that you'd just like to have personally, or because Stefan asked, or is it something that some of your users actually requested?

I am curious, for I did not yet receive an reports that adding an additional package archive presents a considerable barrier to installing Flycheck.

---

You claim that MELPA Stable was inferior to GNU ELPA, citing many missing packages and the conflict with MELPA Stable as reasons. With respect, I find these reasons very poor:

GNU ELPA cannot be combined with MELPA as well, for exactly the same reasons, and it contains even less packages than MELPA Stable, by an order of magnitude. MELPA Stable hosts over 550 packages, including almost all most downloaded packages from MELPA, whereas GNU ELPA provides only about 80 packages.

I understand and share your concerns about the sorry state of Marmalade (though it wasn't as broken as you suggest), but I fail to understand why you'd need to host your own archive for Elpy, instead of relying on MELPA Stable.

I presume you have dependencies that are not yet on MELPA Stable. In that case, however, what makes you sure that you could get these packages into GNU ELPA easily? Or in other words, why do you think it's easier to get your package into GNU ELPA instead of extending MELPA Stable to include the required packages?

[swsnr]

@jorgenschaefer By the way, I do not think that any participant of this discussion was rude. Specifically, I do not think that your reply to @wyuenho was any less rude than his original comment, by any scale and measure. I am inclined to think the opposite, actually, since your reply was very hard on the brink of being a personal insult. No offense meant.

[jorgenschaefer]

Is being available in a standard Emacs installation by default a benefit that you'd just like to have personally, or because Stefan asked, or is it something that some of your users actually requested?

Purely something I would like to have personally. Like most of the rest of Elpy.

You claim that MELPA Stable was inferior to GNU ELPA, citing many missing packages and the conflict with MELPA Stable as reasons. With respect, I find these reasons very poor:

These were not the reasons I cited. The only reason I cited in favor of GNU ELPA is the default configured repository.

I fail to understand why you'd need to host your own archive for Elpy, instead of relying on MELPA Stable.

I can not add packages that Elpy relies on to MELPA stable because MELPA stable only uses tags in repositories I can not control. So if I want to have users install a package that is not in MELPA stable, I have to ask them to add some other repository. If that other repository is MELPA unstable, then MELPA stable is useless because MELPA unstable includes all packages of MELPA stable, just with vendor lock-in version numbers.

I presume you have dependencies that are not yet on MELPA Stable. In that case, however, what makes you sure that you could get these packages into GNU ELPA easily?

Nothing.

I think there is a major misunderstanding here.

I get the impression that you think I say "I will get Elpy into GNU ELPA, flycheck is preventing that, hence I refuse to support flycheck". That's not what I am saying, nor what I have said in this discussion.

Elpy currently has Flymake support. That's good. I created this issue because I was asked about Flycheck. I do not use Flycheck myself, but hey, if someone's using it, happy with it, and Elpy can support it, cool with me. I just need to find the time to add support for it, which includes figuring out how the package works and stuff. The question is when I will make that time. Which is purely a question of priorities.

That is: When I have time to work on one of my projects in my spare time (I do other stuff), what do I work on? Elpy has a on-the-fly source checker which works. The benefits Flycheck offers are small. So it's not exactly high on my priority list. I might want to get Elpy into GNU ELPA at some point, and Flycheck would not be able to be there. Which reduces the priority even further. So, I will not, right now, put in the time to make flycheck work with Elpy.

As you notice, nothing there says "I refuse to support flycheck". All it says is "I will, for now, work on other stuff". If someone makes a pull request for flycheck support (that does not break flymake support), I'm more than happy to apply that. So far, no one did that. All I have so far is people complaining about how I spend my time. Which is fine, but it does not exactly make me interested in spending time on their preferences.

And that is also why wyuenho's comment was incredibly rude (and so were the other responses that I deleted). Instead of doing some work and bring a feature they want into the project, they went for emotional blackmail ("because you do not do what I want, I will not use your program, so THERE!" – as if I write my software to get users :-D). Oh, and also an attempted insult with implying that I somehow stand in the way of technological progress because any disagreement with their objective and eternally true technical assessment must be purely ideological, which of course is entirely bad. If you feel that's not rude, that's ok. We can disagree on that. :-)

None of this is making it more likely for me to work on Flycheck support in Elpy, by the way.

[swsnr]

@jorgenschaefer Indeed, we have a misunderstanding here. I should like to emphasize that I do not care for whether you support Flycheck or not, or whether you move Elpy into GNU ELPA or not.

I am aware that you don't want to support Flycheck simply because you have satisfactory Flymake support, and see no benefit in Flycheck. That is totally fine as far as I am concerned, and I have no interest to convince you otherwise.

I linked the article simply because you asked for the differences between Flymake and Flycheck, and I thought you were not aware of it. I highlighted what I considered important points to spare you the effort to read it entirely, since it's quite long and much of it is really not at all relevant to Elpy.

Initially, I joined this discussion simply to refute what I considered wild speculations of yours concerning my reasons to not sign an agreement (“unlikely”, “more ideological reasons […]”), which were quite far from my real reasons, but I saw immediately that I had misunderstood you, so I let the matter rest.

I noticed, though, that you seemed to really want to move Elpy into GNU ELPA, and became interested in your reasons for this. Again, not because I intended to talk you out of it. I'm sorry if my comments sent the wrong message.

It's just that Emacs developers and contributors (but never any user of Flycheck, by the way) have asked to move Flycheck into GNU ELPA before, but none ever gave me a convincing reason for GNU ELPA, that could overcome my reservations against the FSF and their leaders, and sell copyright assignments to me. Hence, I declined so far.

You are the first person to ever give me any real reasons at all, beyond just “hey, it's going to be part of Emacs then”. I asked because I thought that I might have overlooked something, a unique selling point of GNU ELPA, that probably had escaped me.

I see now that there is none. We are working from the same facts, but reach quite different conclusions. That's totally fine with me and I'd like to thank you for this valuable discussion, for I learned to understand the diversity of the Emacs Lisp community slightly better.

As for rudeness, I should probably have felt that his comment was rude as well, had I been in your place and received the entire feedback about your decision as you did. You deleted comments, after all, which is something I was never forced to do in all my time on Github. I had similar discussions about Flycheck, though, about things of much less significance than this, so I can absolutely understand you.

Still, as you said yourself, his “insult” was an attempt at best, and even then it was merely implied and not explicitly expressed. Your reply, by contrast, was pretty straight in his face, on the personal level.

This imbalance struck me. But then, had I just seen his comment, but not your reply, I would have come to a different conclusion, probably. Just my 2 cents.

[jorgenschaefer]

I see now that there is none. We are working from the same facts, but reach quite different conclusions.

This is likely in no small parts because I am very positively inclined towards the FSF and GNU, being a former GNU volunteer coordinator (though I think my fencepost account isn't there anymore). I have copyright assigned for all future contributions to Emacs, etc. So very different prior attitude there.

Your reply, by contrast, was pretty straight in his face, on the personal level.

I am often told that I am frank to the level of pretty harsh bluntness. I try to avoid that, but I don't always succeed. Especially when I get grumpy. :-D

Thank you for this discussion, by the way. It's always good to see that people can have a sensible exchange of ideas, even if the starting point is a feeling of slight mutual hostility (even if based on a misunderstanding/poor humor), and the resulting conclusions are different.

[swsnr]

@jorgenschaefer Thank you, too. Even though we end up in different conclusions, and probably mutual and respectful disagreement, I enjoyed this discussion, and I am grateful to have been shown quite a different point of view and approach to topics that are of great relevance to my own Emacs projects as well.

Many thanks.

[alf]

It seems this code to use flycheck instead of flymake above no longer works. The following seems to work however:

(when (require 'flycheck nil t)
  (setq elpy-default-minor-modes (delete 'flymake-mode elpy-modules))
  (add-to-list 'elpy-modules 'flycheck-mode))

[jorgenschaefer]

Probably something more like this:

(when (require 'flycheck nil t)
  (setq elpy-modules (delq 'elpy-module-flymake elpy-modules))
  (add-hook 'elpy-mode-hook 'flycheck-mode))

[alf]

Indeed, mine didn't work at least. :)

[xiaoxinghu]

It seems both flycheck and flymake are on for me. It does not delete flymake for me. How can I disable flymake entirely?

Probably something more like this:

(when (require 'flycheck nil t)
  (setq elpy-modules (delq 'elpy-module-flymake elpy-modules))
  (add-hook 'elpy-mode 'flycheck-mode))

[jorgenschaefer]

Add the code above to your .emacs. Restart Emacs. Check that elpy-modules does not contain elpy-module-flymake. Open a Python file. Is Flymake mode is active (C-h v flymake-mode)?

PS. Updated the code snippet, should have been elpy-mode-hook, not elpy-mode.

[ajschumacher]

Wow! Working much better for me since using your 2014-09-12 snippet, @jorgenschaefer - thanks! :+1:

[djrobust]

@jorgenschaefer I still have trouble simply disabling flymake (without replacing it). My .emacs.el contains

(elpy-enable)
(elpy-use-ipython)
(setq python-shell-interpreter "ipython3")
(setq python-shell-interpreter-args "--pylab --nosep --pprint")
(add-hook 'before-save-hook 'whitespace-cleanup nil t)
(setq elpy-modules (delq 'elpy-module-highlight-indentation elpy-modules))
(setq elpy-modules (delq 'elpy-module-yasnippet elpy-modules))
(setq elpy-modules (delq 'elpy-module-flymake elpy-modules))

But even after restarting Emacs, when I open a Python file flymake-mode's value is still t.

Can you help me with that?

[jorgenschaefer]

@djrobust, start Emacs with emacs -q, evaluate the code you pasted in the *scratch* buffer, and open a Python file. If flymake is not active, something else in your configuration is responsible.

If it is active even in that case, make sure elpy-module-flymake is indeed not in elpy-modules (C-h v elpy-modules), and that you are using Elpy 1.5 or later (M-x elpy-config).

[djrobust]

@jorgenschaefer If I follow the emacs -q procedure, then indeed flymake is not active. It seems the relevant region in emacs.el that sets flymake-mode to t is (commenting that region out solves the problem):

(desktop-save-mode t)
(setq desktop-restore-eager 3)
(setq desktop-files-not-to-save ".*\.org")
(setq desktop-load-locked-desktop t)
(setq desktop-dirname user-emacs-directory)
(convert-standard-filename (format ".emacs.desktop.lock-%d" (emacs-pid)))

(if (file-exists-p (concat desktop-dirname desktop-base-file-name))
    (desktop-read desktop-dirname))

;; Add a hook when emacs is closed to we reset the desktop
;; modification time (in this way the user does not get a warning
;; message about desktop modifications)
(add-hook 'kill-emacs-hook
      (lambda ()
        ;; Reset desktop modification time so the user is not bothered
        (setq desktop-file-modtime (nth 5 (file-attributes (desktop-full-file-name))))))

(add-to-list 'desktop-modes-not-to-save 'dired-mode)
(add-to-list 'desktop-modes-not-to-save 'Info-mode)
(add-to-list 'desktop-modes-not-to-save 'info-lookup-mode)
(add-to-list 'desktop-modes-not-to-save 'fundamental-mode)

So I looked into .emacs.desktop and found the following entry for my python file.

(desktop-create-buffer 206
  "/home/problem_set_b_1.py"
  "problem_set_b_1.py"
  'python-mode
  '(auto-complete-mode elpy-mode company-mode eldoc-mode)
  1
  '(nil nil)
  nil
  nil
  '((tab-width . 8) (indent-tabs-mode) (buffer-file-coding-system . undecided-unix)))

If I now start emacs with such an entry in .emacs.desktop, flymake-mode (as well as highlight-indentation-mode and yas-minor-mode) will be enabled in the problem_set_b_1.py buffer.

Do you have any ideas on what could be happening here?

[jorgenschaefer]

No idea, sorry. Does not seem to be Elpy-related, so maybe try asking in the #emacs channel on Freenode or emacs.stackexchange.com ?

[SoftwareMaven]

So this came in a while ago, but I'm going to resurrect it. I tend to run with a lot of buffers open (179 python buffers at the moment). I was having pretty much non-stop problems with emacs cpu usage sitting at 50-60% constantly. If I had the same buffer open in two windows, emacs cpu usage would jump to 100+%.

After profiling, I found that it was spending a ton of time in timer-event-handler. A little more digging showed that I had three timer entries for each Python buffer:

[nil 22028 33837 119863 1 flymake-on-timer-event (#<buffer yaml.py>) nil 384000]

When I used flycheck with this code:

(when (require 'flycheck nil t)
  (setq elpy-modules (delq 'elpy-module-flymake elpy-modules))
  (add-hook 'elpy-mode-hook 'flycheck-mode))

I see that number go down to a single timer per buffer, which is explained by looking through my desktop file. Once I cleaned those out, timer-list was also cleaned out and emac's cpu utilization is trivially low. Even having two windows open to the same buffer is fine.

I recognize this is almost certainly a problem with flymake's timer . However, it was ugly enough that it is probably worth mentioning somewhere and having a trivial way to switch. (Maybe something like "(setq elpy-disable-flymake t)")

[JonyEpsilon]

Would you be open to adding the snippet to disable flymake and enable flycheck to the wiki's FAQ page? I'd be happy to write the entry if so :-)

[galaunay]

I think it is a valuable piece of information indeed, thanks.

You can fork the wiki (repo url), make your modifications and post your branch link here, I'll be happy to merge it.

Or it may be more simple to just post the entry here, and I'll add it. It's up to you :)

[RobinTournemenne]

I am using spacemacs and the following piece of code makes me able to use flycheck instead of flymake at the startup:

(when (require 'flycheck nil t)
  (setq elpy-default-minor-modes (delete 'flymake-mode elpy-default-minor-modes))
  (add-to-list 'elpy-default-minor-modes 'flycheck-mode))

But as soons as I reload the init file (in spacemacs with the combination M-m f e R) elpy bugs stating that my virtualenv does not have ipython, which is obviously false:

Elpy Configuration

Virtualenv........: testMKL3 (/Users/robintournemenne/.virtualenvs/testMKL3)
RPC Python........: 2.7.15 (/usr/local/bin/python)
Interactive Python: ipython (/usr/local/bin/ipython)
Emacs.............: 26.1
Elpy..............: 1.28.0
Jedi..............: 0.10.2
Rope..............: Not found
Autopep8..........: Not found
Yapf..............: Not found
Black.............: Not found
Syntax checker....: flake8 (/usr/local/bin/flake8)

The python interactive interpreter (ipython) is not installed on the current
virtualenv (/Users/robintournemenne/.virtualenvs/testMKL3/). The system binary
(/usr/local/bin/ipython) will be used instead.

Any idea?

Thank you!

[galaunay]

I am a bit confused, because elpy-default-minor-mode has been made obsolete in the version 0.8 of Elpy. It should not do anything anymore. Did you meant:

(when (load "flycheck" t t)
  (setq elpy-modules (delq 'elpy-module-flymake elpy-modules))
  (add-hook 'elpy-mode-hook 'flycheck-mode))

This is very weird that the statement you added breaks the virtualenv support... Could you evaluate the following statements when the issue happens and post the result ? It would help me narrow down the issue cause.

(executable-find python-shell-interpreter)

(expand-file-name pyvenv-virtual-env)

(expand-file-name (getenv "VIRTUAL_ENV"))

[RobinTournemenne]

My bad I copied the wrong piece of code... I indeed wanted to write that my .spacemacs contains under the dotspacemacs/user-config function:

  (elpy-enable)
  (setq python-shell-interpreter "ipython"
        python-shell-interpreter-args "-i --simple-prompt")
  (when (require 'flycheck nil t)
    (setq elpy-modules (delq 'elpy-module-flymake elpy-modules))
    (add-hook 'elpy-mode-hook 'flycheck-mode))

Here are the three results you asked me yesterday: python-shell-interpreter: /usr/local/bin/ipython pyvenv-virtual-env Users/robintournemenne/.virtualenvs/testMKL3 getenv "VIRTUAL_ENV" Users/robintournemenne/.virtualenvs/testMKL3

Thanks a lot for your help!

[galaunay]

There is indeed something wrong,

(executable-find python-shell-interpreter)

should return something like Users/robintournemenne/.virtualenvs/testMKL3/bin/ipython

I see two possibilities here:

1. The ipython binaries is not present in your virtualenv (you can check if ipython is present in /Users/robintournemenne/.virtualenvs/testMKL3/bin).
2. The virtualenv path has not been properly added to your PATH (which you can check with (get-env "PATH") in emacs).