-
-
Notifications
You must be signed in to change notification settings - Fork 449
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
flycheck hangs with eslint #794
Comments
Please tell us your Flycheck version ( Please note that we do not support Windows. I'm closing this issue as |
Flycheck version: 0.25snapshot (package: 20151113.858) I can't reproduce with |
In other words, if you start |
Sorry I didn't realise you wanted me to load flycheck manually. emacs hangs when I visit the affected file after loading flycheck manually like this : (add-to-list 'load-path "~/.emacs.d/elpa/dash-20151021.113")
(add-to-list 'load-path "~/.emacs.d/elpa/flycheck-20151113.858")
(require 'flycheck)
(global-flycheck-mode) |
@BrunoQC Uhm, yes, I wanted you to actually try and see whether Flycheck works in Can you given me the file which shows this issue? I'd like to try myself. Alternatively, can you try to reproduce the problem on a Unix system? That's somewhat crucial, for otherwise I'm unable to debug and fix the issue. If it's a Windows-only problem, you'll have to debug that yourself. Besides, you're not using the latest Flycheck build from MELPA, please consider updating. |
I have the problem with https://ajax.googleapis.com/ajax/libs/angularjs/1.4.7/angular.js . I also tested with an up-to-date flycheck. I wasn't able to reproduce on Debian.
I'll test at home later today on a faster and better Windows machine. |
I also have the problem at home. |
Also on a Windows machine? I'm inclined to believe that it's s Windows specific issue. Then you're on your own. I'm sorry but I can't and don't want to fix Windows issues. I don't have access to a Windows development machine and it's too alien to me to spend a lot of time with. Sorry. |
@BrunoQC I'm also unable to reproduce this issue on a Linux system. I'm sorry. |
Yes.
No problem. I checked around a bit even if I don't know lisp (or is it elisp?) and I have a workaround that work for me in case anyone else has the same problem. It works if flycheck call this Go program which only call eslint. It's weird that it doesn't work with I'll check again another day. :command ("my.exe" "eslint" "--format=checkstyle" package main
import (
"io"
"os"
"os/exec"
)
func runCMD() error {
cmd := exec.Command(os.Args[1], os.Args[2:]...)
// cmd.Stdin = os.Stdin // doesn't work
cmd.Stdout = os.Stdout
pipe, errPipe := cmd.StdinPipe()
if errPipe != nil {
return errPipe
}
if err := cmd.Start(); err != nil {
return err
}
if _, err := io.Copy(pipe, os.Stdin); err != nil {
return err
}
if err := pipe.Close(); err != nil {
return err
}
cmd.Wait() // ignore the return code
return nil
}
func main() {
err := runCMD()
if err != nil {
panic(err)
}
} |
@BrunoQC You're not using cygwin, are you? |
I have it installed but I don't use it. It's not in my path. I may have some gnu .exe like sh.exe in my path. |
I'm at a loss then. I've no clue what could possibly cause this issue. My Windows foo is pretty bad, though. Out of curiosity: Could you try another Javascript checker, e.g. |
|
Well, that's smells like a Node on Windows issue then. Is there a known issue about standard input on Windows or something like that? |
I have no idea. |
@BrunoQC, I would try using an older version of flycheck, I also encountered the same problem but my old version |
I am on windows 10 and emacs 24.4 |
Windows 10 |
I'm having the same issue.
I used Oct 25 - 6088731 - Use standard input for javascript checkers.I'm a newbie when it comes to elisp, so I'm afraid I won't be of much use to actually suggest a fix... but at the very least, we've narrowed it down to a few small changes made in a single commit. Hopefully there haven't been too many changes since then that rely on this commit, and fixing it will be easy. In the mean time, anyone else having this problem can checkout c2e413a. That's the latest commit that should be working correctly on Windows. |
Hi Xeveo, Thanks for bisecting; I haven't gotten around testing this yet. I think @lunaryorn identified this problem in a previous message, mentioning stdin checkers. A fix will certainly not be very easy, depending on the extent of the problem. As a workaround, you could just copy the checker definition from that commit, instead of reverting to a previous commit. The issue seems to be with the way the checkers in question deal with being fed input on standard input instead of as a separate file. |
Thank you for the quick response. As you and @lunaryorn suggested, the issue seems to be a problem with standard-input. Reverting the relevant changes from the commit I mentioned fixes the issue. I don't want to create a pull request, because I'm really not familiar with the code, and as I said in my previous comment, I'm very new to the language. Besides, the changes in 6088731 were made for a reason. If it works on Unix/Linux systems, then there's probably an alternate solution that would be more appropriate than reverting (probably not worth your time to investigate, as it seems to be an emacs bug). |
Just wanted to comment that I had the same issue on my windows machine (working fine on my linux systems) and the patch by Xeveo seems to have solved my issue. |
@BrunoQC I had the same problem, but with jshint.cmd. And I found that if the length of buffer/file less than or equals to 4096 bytes, jshint works fine, otherwise jshint hangs emacs... I guess this may caused by write() in mingw-msys that build emacs or the stream impl(using windows pipe) of nodejs. |
I started investigating this because I didn't know the cause, and when I found the issue occurred at 4096, I was able to find this issue. The link provided by @Xeveo has resolved the issue. Having found what will cause the problem, but not what actually causes the problem, and a valid workaround, I will live with the workaround. If its possible to include this problem in the documentation that would be helpful. |
Add flycheck-pos-top, use elisp xml-parse. Check on save only (hack until fix for 4096 eshint hanging issue resolved flycheck/flycheck#794)
Thank you all very much for your help with tracking down the cause, and for your thorough testing of the fix. We appreciate your help, and a very happy to work with such great people! Thank you very much. I'd like to inform you that following @cpitclaudel's bug report to Emacs upstream a potential fix for this issue was committed to the If you have some time to spare, and would like to help Emacs and Flycheck, it would be awesome if you could compile the latest Thank you very much. |
I can no longer reproduce the hang using a build that includes 58a622d, so it looks to me that the issue is fixed. Thanks |
@bschwehn Do you have instructions how to build emacs on Windows or did you use a snapshot from somewhere? |
@BrunoQC I used the instructions from here: http://sourceforge.net/p/emacsbinw64/wiki/Build%20guideline%20for%20MSYS2-MinGW-w64%20system/ Also in the source tree, the nt folder has some instructions. I had no issues (but make sure to have autocrlf turned off when checking out emacs, not working otherwise). Just to make clear: I have so far not actually tried flycheck, just the hang repro steps in the bug report. I was able to repro the hang using the steps that Clément described in the emacs bug report and can no longer repro using my latest build. I will try with flycheck tomorrow. |
Also, if it helps anyone, I can put the build up somewhere. Let me know. |
I can also confirm that the issue seems to be fixed by the |
@Xeveo: did you try with actually using flycheck in a scenario where it hanged before (undoing any workarounds you have applied)? I didn't have time to look at it further yet, but noticed that with the workarounds still in place (i.e. jshint is passed a file, not via stdin), flycheck still works, but I get a new warning message like:
Which I did not get before. Did you notice anything like this also? I don't think it is related to the 58a622d commit. |
@bschwehn: I checked out the lastest master content for flycheck, and opened a file that had previously caused emacs to hang (20,480 bytes in size). The file was linted correctly, and I did not get any warnings or errors from emacs. I've tested with both javascript-jshint, and javascript-eslint. |
@bschwehn It seems I still have the problem even with the 58a622d473112f8ff5b4bdb3e49bc6573dfd3404 commit. I'm leaving work for today. I'll test again tomorrow. |
I've had a bit of time to recompile Emacs on Wdinows. The results of my tests were that a plain build (according to the instructions in nt/INSTALL) of the master branch does fail (as expected), but a build of the emacs-25 branch seems to work as expected. |
Thank you all for your time spent on testing the fix. You're awesome people, the lot of you 😍 👏 I'll commit the workaround for Emacs 24 as soon as possible. In order to correctly enable the workaround for all affected versions of Emacs and operating systems, I'd like to ask one final question, though: Did any of you observe the issue on cygwin? Or could anyone test whether cygwin is also affected? |
Disregard my last comment. I was on the wrong branch. Sorry about that. The |
I'm trying to test with cygwin but flycheck doesn't show the eslint errors.
I wonder if it's because I'm using a non-cygwin node.js. eslint seems to work in the Cygwin64 Terminal. node.js doesn't seem to be available as a cygwin package. |
Indeed, I had trouble trying this with Cygwin as well; node.js was confused by the path format for the config file ( I opened an issue with the Node.js people, to get their input. We'll push the temporary fix to Flycheck soon, and the problem will be definitively fixed with the next release of Emacs. Phew. |
This is an Emacs bug: process-send-region just hangs when given more than 4096 characters to process. See the Emacs bug report at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22344 for a more complete description. The issue is fixed in Emacs 25.1, but we’ll add and keep this workaround while we support Emacs 24. Fixes GH-794 and closes GH-850.
I merged @cpitclaudel's fix into |
I have 80 errors in my file if I run eslint from the command line. I tested with a smaller file (with less errors) and it was fine. Emacs has 0% cpu usage and I don't see eslint in the process manager. I think it's related to eslint since the file opens if I remove eslint from my PATH.
There's nothing in the message buffer.
GNU Emacs 24.5.1 (x86_64-w64-mingw32) of 2015-05-16 on KAEL
The text was updated successfully, but these errors were encountered: