E631: write_buf_line()(): write failed about ale HOT 87 CLOSED

I finally have a solution for this now.

Vim 8+ lets you send Vim buffer data to a program in two ways. You can use the in_io option, or you can use ch_sendraw. Both are blocking. Neither work for some people. So now I use neither.

Now ALE writes the Vim buffer to a temporary file, and pipes the data with < filename in whatever shell you're using. It works on every version of Vim I have at hand, so that should be that.

from ale.

Oh, I should have made it clearer; I'm running a regular terminal install of vim.

from ale.

Aha! Great. I thought that might be the problem.

from ale.

What does ale do when a call to the linter doesn't return a useful message, e.g. "/bin/bash: gfortran: command not found"? I'm still curious why the error occurs with a bad "linter" but doesn't with a good one.

from ale.

It shouldn't. You can use that dictionary to configure the linters used for a particular filetype. If you want to turn everything off, consult the online documentation with :help ale. There are a few options for disabling linting on typing, on save, on enter, etc.

from ale.

Can you confirm that this occurs only in MacVim and not vim?

from ale.

From the output above, it looks like it's maybe failing to create new jobs for some reason, or maybe it's failing to pipe output to a process in MacVim? I'm not quite sure. Let me know if this problem exists in versions of Vim other than MacVim. If anyone has MacVim and feels like debugging this, let me know. I might be able to get a hold of a Mac myself to test it at some point, if the issue is specific to Macs.

from ale.

What type of file were you editing at the time? That might help.

from ale.

It's working fine for me in MacVim, at least in javascript with eslint.

As far as I remember, MacVim is just a GUI similar to a terminal emulator. It should still use the regular vim underneath.

from ale.

@w0rp , the long backtrace seems like it was a one time fluke but the write_buf_line is persistant in both MacVim an vim. I was editing a JavaScript file. The write_buf_line error happens with a sh file too. I didn't test more than this.

from ale.

The message seems to happen only on Entering/Leaving insert mode.

BTW, @prashcr , I recall seeing some bug where MacVim had some issues with job/channel support while Vim didn't in the past. However, it doesn't seem relevant here as it is happening in both.

from ale.

And it doesn't happen with nvim.

from ale.

Here are some more traces in MacVim on a javascript file while trying to edit it. So I guess it's not too hard to reproduce.

Error detected while processing function <SNR>134_HandleExitVim[1]..<SNR>134_HandleExit[36]..ale#sign#SetSigns:
line   36:
E885: Not possible to change sign ALEErrorSign
E631: write_buf_line()(): write failed
Error detected while processing function <SNR>134_HandleExitVim[1]..<SNR>134_HandleExit[36]..ale#sign#SetSigns:
line   36:
E885: Not possible to change sign ALEErrorSign
1 line less
1 line less
E631: write_buf_line()(): write failed
Error detected while processing function <SNR>134_HandleExitVim[1]..<SNR>134_HandleExit[36]..ale#sign#SetSigns:
line   36:
E885: Not possible to change sign ALEErrorSign
1 more line; before #408  3 seconds ago
Error detected while processing function <SNR>134_TimerHandler[22]..<SNR>134_ApplyLinter[3]..<SNR>134_ClearJob:
line    1:
E716: Key not present in Dictionary: process 84884 dead
E15: Invalid expression: s:job_info_map[a:job].linter
line   15:
E716: Key not present in Dictionary: process 84884 dead
line   16:
E121: Undefined variable: linter
E116: Invalid arguments for function remove
E631: write_buf_line()(): write failed
Error detected while processing function <SNR>134_HandleExitVim[1]..<SNR>134_HandleExit[36]..ale#sign#SetSigns:
line   36:
E885: Not possible to change sign ALEErrorSign
E631: write_buf_line()(): write failed
Error detected while processing function <SNR>134_HandleExitVim[1]..<SNR>134_HandleExit[36]..ale#sign#SetSigns:
line   36:
E885: Not possible to change sign ALEErrorSign

E631: write_buf_line()(): write failed
Error detected while processing function <SNR>134_HandleExitVim[1]..<SNR>134_HandleExit[36]..ale#sign#SetSigns:
line   36:
E885: Not possible to change sign ALEErrorSign
1 line less
E631: write_buf_line()(): write failed
Error detected while processing function <SNR>134_HandleExitVim[1]..<SNR>134_HandleExit[36]..ale#sign#SetSigns:
line   36:
E885: Not possible to change sign ALEErrorSign

from ale.

Thank you for all of the information above. Could you share the file you were editing, or something like it?

It looks like one of the errors is setting some bad signs. What happens if you set let g:ale_set_signs = 0? That should disable the signs for now. If the errors stop then, then the problem lies in the signs feature.

The error might be tied to closing the input stream too quickly or something, which could be hard to detect. What happens if you increase g:ale_lint_delay to some higher number in your vimrc file, say 500?

from ale.

Here's a sample file I can reproduce errors with. I think without the jshint directive header up top the error is not happening:

https://gist.github.com/junkblocker/8ecf9fc7940a8e42802f241cdf4fcedc

Setting g:ale_set_signs = 0 makes the ALEErrorSign error disappear but the following is still seen in messages. g:ale_lint_delay = 500 didn't seem to matter.

"/tmp/foo" 2018L, 93661C
E631: write_buf_line()(): write failed
E631: write_buf_line()(): write failed
E631: write_buf_line()(): write failed
E631: write_buf_line()(): write failed
E492: Not an editor command: W
"/private/tmp/foo" 2019L, 93662C written
E631: write_buf_line()(): write failed
E631: write_buf_line()(): write failed
"/private/tmp/foo" 2019L, 93662C written
E631: write_buf_line()(): write failed
E631: write_buf_line()(): write failed
Error detected while processing function <SNR>20_TimerHandler[22]..<SNR>20_ApplyLinter[3]..<SNR>20_ClearJob:
line    1:
E716: Key not present in Dictionary: process 5766 dead
E15: Invalid expression: s:job_info_map[a:job].linter
line   15:
E716: Key not present in Dictionary: process 5766 dead
line   16:
E121: Undefined variable: linter
E116: Invalid arguments for function remove
line    1:
E716: Key not present in Dictionary: process 5768 dead
E15: Invalid expression: s:job_info_map[a:job].linter
line   15:
E716: Key not present in Dictionary: process 5768 dead
line   16:
E121: Undefined variable: linter
E116: Invalid arguments for function remove
E631: write_buf_line()(): write failed
E631: write_buf_line()(): write failed
1 more line; before #12  2 seconds ago
1 line less; before #11  4 seconds ago
1 line less; before #10  5 seconds ago
1 line less; before #9  5 seconds ago
1 line less; before #8  6 seconds ago
1 line less; before #7  7 seconds ago
1 line less; before #6  9 seconds ago
E631: write_buf_line()(): write failed

from ale.

I'll ask for some assistance with this issue. I have limited access to Mac computers myself.

from ale.

Similiar on Windows 7: when I opening a PHP buffer, it says

Error detected while processing function <SNR>79_TimerHandler[22]..<SNR>79_ApplyLinter:
line   49:
E631: write_buf_line()(): write failed

The file is 500 lines long, but on the line 104 there is a sign (the only one): syntax error, unexpected end of file in -

First time when I switch buffer it says:

Error detected while processing function <SNR>79_TimerHandler[22]..<SNR>79_ApplyLinter[3]..<SNR>79_ClearJob:
line    1:
E716: Key not present in Dictionary: process 2812 dead
E15: Invalid expression: s:job_info_map[a:job].linter
line   15:
E716: Key not present in Dictionary: process 2812 dead
line   16:
E121: Undefined variable: linter
E116: Invalid arguments for function remove
Error detected while processing function <SNR>79_TimerHandler[22]..<SNR>79_ApplyLinter:
line   49:
E631: write_buf_line()(): write failed

Most of the bugs coming random (expect the E631: write_buf_line()(): write failed) - sometimes there's no warnings on the same file. It's weird... (o_O')

Versions

Vim: 8.0.21
PHP: 5.6.24 (via XAMPP)

Ps.: Sorry for my Englisch.

from ale.

I tried to repeat this with Vim 8 on Linux with the JS file above and a very large PHP file, but I haven't been able to repeat the bug yet. If anyone can repeat the bug and wants to have a go at fixing it, go for it. I'll be working on some Windows support now.

from ale.

I have this the same on my vim.

from ale.

Could you let me know which OS and which version of Vim you are using, etc?

from ale.

Here's a sample which produces the bug: https://gist.github.com/BimbaLaszlo/2e664f9da38197c687605cfcdac648f9

from ale.

I can't repeat the issue using that file on my machine. Are you running Mac OSX or Windows? I'm wondering if someone who can repeat the issue can have a look at this. I haven't been able to find out what the problem is yet.

from ale.

Using Windows. The file is truncated to the size where the bug just appears - removing a character will make it disappear. I will make another one to compare. The content not matters, but the number of characters maybe.

from ale.

Hmm, maybe the issue only happens on Windows or Mac? That seems to be what I'm seeing above. I'm working on some Windows support at the moment, so maybe I'll come across it eventually.

from ale.

https://gist.github.com/BimbaLaszlo/cfc87d01fbacac320576f2d9620c88a7

Delete some char in the middle of the file and the bug still alive, but deleting the last line makes it disappear.

from ale.

I've tried out both the JS and PHP samples in my Macvim 8.0-110 (vim 8.0.0003) and vim 8.0.0019 and do not see the errors, if that is helpful.

from ale.

Tried out the JS sample and do not see the errors.

from ale.

OMG! (o_O) I just forgot to install JS linter... (-_-') Will be back with the results... If anybody tries out the samples, be sure to install the linter of that first!

from ale.

@junkblocker Please explain me how can I set up a JS linter - never used it.

from ale.

@BimbaLaszlo , I just installed jshint binary globally per http://jshint.com/install/

sudo npm install -g jshint

Nothing else. No special configuration etc.

from ale.

I have another issue: JSHint is installed and works fine (type .\foo.js | jshint --reporter unix - prints the warnings) but Ale does not shows any sign or messages, nor bugs.

from ale.

Could you paste the output of jshint, like your command from above?

from ale.

$ type .\foo.js | jshint --reporter unix -
stdin:6:23: Missing semicolon.
stdin:7:27: Missing semicolon.
stdin:8:27: Missing semicolon.
stdin:9:27: Missing semicolon.
stdin:10:27: Missing semicolon.
...etc...

from ale.

Can you run the same from inside of Vim with :!? It looks like the regex parses those lines. If you place echo a:lines inside of the handler function in ale_linters/javascript/jshint.vim, does it receive any of the error lines?

from ale.

It works from Vim too. Didn't caught a:lines and function! ale_linters#javascript#jshint#Handle(buffer, lines) never called (wrote echo "OK" to the first line of it, but it didn't appeared). More over I put echo job_info(a:linter.job) after this line https://github.com/w0rp/ale/blob/d97e25a2601d58a1d7e8ae72fb787210f2588a69/plugin/ale/zmain.vim#L220 - the output is allways:

{'status': 'fail', 'stoponexit': 'term', 'exitval': 0, 'exit_cb': 0, 'channel': channel fail, 'process': 0}

from ale.

The output of the job_info() on the PHP samples is:

{'status': 'dead', 'stoponexit': 'term', 'exitval': -1, 'exit_cb': 0, 'channel': channel 2 open, 'process': 3952}

The channel number is increasing after every run.

from ale.

The output on a "working" PHP file (no bugs appearing) is:

{'status': 'run', 'stoponexit': 'term', 'exitval': 0, 'exit_cb': 0, 'channel': channel 2 open, 'process': 3380}

from ale.

It looks like it's failing to start a job for you, for some reason. Which OS were you testing that on? I could try running jshint on the same OS myself. So far, I have been unable to repeat the bugs mentioned in this issue.

from ale.

I have discovered some very odd behaviour for Windows, which I guess is a bug with job_start()? If you run system('jshint'), it will execute just fine. You'll get some output. If you run job_start('jshint'), it will fail. If you run job_start('jshint.cmd') it will succeed. It looks like job_start doesn't respect PATHEXT, where system does.

I'll see if I can write a workaround for that.

from ale.

@BimbaLaszlo I just pushed a command which I believe should fix this issue on Windows now. Take a look. Someone in the #vim channel suggested trying cmd /c, and that does seem to work.

from ale.

I think I finally see where the original errors came from. It was failing to write to a program which couldn't be run, and then failing to get the job out of the dictionary again because it didn't succeed. I'll see If I can change the key used for the dictionaries and handle that better.

from ale.

The cmd /c solved to lint Javascript, it works fine - there is no E631: write_buf_line()(): write failed bugs in it, but in PHP files still there.

from ale.

I pushed a commit which fixes how jobs are stored in the map. That should hopefully fix some of the errors. I tested editing a PHP file on Windows 7 with php.exe in my PATH, and I can see the linter errors. Would you like to try again?

from ale.

Linting works, but E361 still exists, plus I got a new error on the second PHP sample:

Error detected while processing function <SNR>83_HandleExitVim[1]..<SNR>83_HandleExit[1]..<SNR>83_GetJobID:
line    8:
E916: not a valid job
E475: Invalid argument: 0
E121: Undefined variable: id
E15: Invalid expression: ch_info(job_getchannel(a:job)).id

The latter can be fixed by adding before this line:

    if a:job == 'no process'
      return
    endif

from ale.

Fix works, only E361 exists now, so we came back to the original problem.

from ale.

I can finally see the error on Windows. I'm having a look now. It looks like maybe Vim isn't sending the buffer data to the process on Windows, while it works on other machines, which is odd.

from ale.

Don't forget that (in my case) depends on some properties of the file - some files don't dropping bugs, others do that.

from ale.

@BimbaLaszlo I just pushed a commit for sending the buffer lines to the job by reading them with getbufline() instead. For some reason the job options for sending the buffer via internal Vim mechanisms to the program work very well on Linux, but not very well on Windows with large files. This processing is slower, so I have only enabled this for Windows for now. I may do this in MacVim also if it experiences the same issues.

Take a look and let me know what output you get now.

from ale.

Everything works fine for me. Good job!

from ale.

Nice. 👍

@junkblocker Do you want to check this in MacVim again? The error may be present there, and if it is, I will push a commit to make MacVim do the same as Windows.

from ale.

The problem is still present on MacVim.

from ale.

Okay, thanks for letting me know. I have a copy of MacVim on another computer, and I believe I should be able to fix this tomorrow. It'll probably the same issue as on Windows.

from ale.

@junkblocker I just pushed a commit to apply the fix in MacVim GUI too. Check it out.

from ale.

The error has changed to something new.

Error detected while processing function <SNR>135_TimerHandler[22]..<SNR>135_ApplyLinter:
line   98:
E631: ch_sendraw(): write failed
E631: ch_sendraw(): write failed
4 lines yanked
E631: ch_sendraw(): write failed

E631: ch_sendraw(): write failed
1 line less
E631: ch_sendraw(): write failed
E631: ch_sendraw(): write failed

1 line less
E631: ch_sendraw(): write failed
"foo.js" 1989L, 91683C
Messages maintainer: Bram Moolenaar <[email protected]>
startuptime:   1.219377
"foo.js" 1989L, 91683C
Error detected while processing function <SNR>135_TimerHandler[22]..<SNR>135_ApplyLinter:
line   98:
E631: ch_sendraw(): write failed

from ale.

That... is also strange. That means that neither option for sending data to a job is working. Have you tried updating MacVim? It sounds like a bug in your version of MacVim. I tried running ALE with the examples attached to this issue with the latest MacVim on Mac OSX, and I can't see any errors.

from ale.

Yes, I am running the HEAD version (8.0.027).

VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Oct 10 2016 09:52:19)
MacOS X (unix) version
Included patches: 1-27
Compiled by [email protected]
Huge version with MacVim GUI.  Features included (+) or not (-):
+acl             +diff            +jumplist        +mouse_urxvt     +scrollbind      +virtualedit
+arabic          +digraphs        +keymap          +mouse_xterm     +signs           +visual
+autocmd         +dnd             +lambda          +multi_byte      +smartindent     +visualextra
+balloon_eval    -ebcdic          +langmap         +multi_lang      +startuptime     +viminfo
+browse          +emacs_tags      +libcall         -mzscheme        +statusline      +vreplace
++builtin_terms  +eval            +linebreak       +netbeans_intg   -sun_workshop    +wildignore
+byte_offset     +ex_extra        +lispindent      +num64           +syntax          +wildmenu
+channel         +extra_search    +listcmds        +odbeditor       +tag_binary      +windows
+cindent         +farsi           +localmap        +packages        +tag_old_static  +writebackup
+clientserver    +file_in_path    +lua/dyn         +path_extra      -tag_any_white   -X11
+clipboard       +find_in_path    +menu            +perl/dyn        -tcl             -xfontset
+cmdline_compl   +float           +mksession       +persistent_undo +termguicolors   +xim
+cmdline_hist    +folding         +modify_fname    +postscript      +terminfo        -xpm
+cmdline_info    -footer          +mouse           +printer         +termresponse    -xsmp
+comments        +fork()          +mouseshape      +profile         +textobjects     -xterm_clipboard
+conceal         +fullscreen      +mouse_dec       +python/dyn      +timers          +xterm_save
+cryptv          -gettext         -mouse_gpm       -python3         +title           
+cscope          -hangul_input    -mouse_jsbterm   +quickfix        +toolbar         
+cursorbind      +iconv           +mouse_netterm   +reltime         +transparency    
+cursorshape     +insert_expand   +mouse_sgr       +rightleft       +user_commands   
+dialog_con_gui  +job             -mouse_sysmouse  +ruby/dyn        +vertsplit       
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "$VIM/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/Users/xxxx/Applications/MacVim.app/Contents/Resources/vim"
Compilation: clang -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe  -DMACOS_X_UNIX  -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1      
Linking: clang   -L. -L/usr/local/lib -L. -L/usr/local/lib  -L/usr/local/lib -o Vim -framework Cocoa -framework Carbon       -lm -lncurses  -liconv -framework Cocoa   -fstack-protector  -L/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE 

from ale.

It have no idea why the plugin doesn't work for you. If anyone else running MacVim wants to have a look, go for it. I have tried to repeat the bug in MacVim, and I have been unable to do so.

from ale.

Some new observations.

• The error is not happening for a sh file I had.
• For JavaScript, the error is happening if jscs is included in linters (e.g. by default) and does not have a proper .jscsrc.

% jscs 
No configuration found. Add a .jscsrc file to your project root or use the -c option.

To prove if I either exclude jscs via

let g:ale_linters = {'javascript': ['eslint', 'jshint']}

or if I create a dummy .jscsrc file

% echo '{}' > ~/.jscsrc

the error does not happen.

Also unrelated, the code in jshint.vim is not really using the executable variable

diff --git a/ale_linters/javascript/jshint.vim b/ale_linters/javascript/jshint.vim
index 577e5c1..a020ca0 100644
--- a/ale_linters/javascript/jshint.vim
+++ b/ale_linters/javascript/jshint.vim
@@ -7,6 +7,9 @@ endif

 let g:loaded_ale_linters_javascript_jshint = 1

+let g:ale_javascript_jshint_executable =
+\   get(g:, 'ale_javascript_jshint_executable', 'jshint')
+
 function! ale_linters#javascript#jshint#GetCommand(buffer)
     " Set this to the location of the jshint configuration file to
     " use a fixed location for .jshintrc
@@ -17,7 +20,7 @@ function! ale_linters#javascript#jshint#GetCommand(buffer)
         let jshint_config = ale#util#FindNearestFile(a:buffer, '.jshintrc')
     endif

-    let command = 'jshint --reporter unix'
+    let command = g:ale_javascript_jshint_executable . ' --reporter unix'

     if !empty(jshint_config)
         let command .= ' --config ' . fnameescape(jshint_config)
@@ -69,14 +72,14 @@ endfunction

 call ALEAddLinter('javascript', {
 \   'name': 'jshint',
-\   'executable': 'jshint',
+\   'executable': g:ale_javascript_jshint_executable,
 \   'command_callback': 'ale_linters#javascript#jshint#GetCommand',
 \   'callback': 'ale_linters#javascript#jshint#Handle',
 \})

 call ALEAddLinter('javascript.jsx', {
 \   'name': 'jshint',
-\   'executable': 'jshint',
+\   'executable': g:ale_javascript_jshint_executable,
 \   'command_callback': 'ale_linters#javascript#jshint#GetCommand',
 \   'callback': 'ale_linters#javascript#jshint#Handle',
 \})

from ale.

I reverted my attempt at fixing the issue from before, as it didn't fix the issue, and might make matters worse.

Maybe the issue is caused by the jscs linter then. I'll try installing that and seeing if I can repeat the bug.

I'll apply your patch for the jshint linter. Sounds good to me.

from ale.

Oh, it's not using the executable variable, because there never was one. That was never implemented. I'll add that anyway.

from ale.

I haven't had the time to repeat this bug with jscs and solve it yet, but I'll roll the bug fix into another version if it is pretty simple.

from ale.

I just experienced this in terminal vim on Mac as well (oddly, with css instead of other filetypes.)

from ale.

If you have any luck with isolating the cause, let me know. My best guess is that there's something wrong with Vim in Mac terminals being able to process stdin data for jobs.

from ale.

Absolutely. I'll try it on my Ubuntu laptop later to see if I can reproduce the issue.

from ale.

Started seeing this today with flake8, on any edit to my .py file.

from ale.

I don't have much access to Macs, so if anyone who has a Mac who wants to see if they can find out what the problem is and how to fix it, let me know.

from ale.

I just encountered the same with a Fortran file. I'm running vim 8.0 on macOS.

In any case, with the default Ale settings, the error appears to only occur when the Fortran file goes above a certain length, even if the syntax is garbage.

For example, these files (each named test.f) show the error on my machine, but removing a line causes the error to vanish:

• 313 lines of 50 A each, 15936 characters
• 197 lines of 80 A each, 15957 characters
• 80 lines of 200 A each, 16080 characters

In each of those cases, the output that Ale sees (I think) is something along the lines of "warning: unused compilation option -ffree-format" and "error: invalid value f95 in -x f95", since gcc is symlinked to clang on macOS, and Clang doesn't (yet) know how to process Fortran files.

Changing the linter to gfortran (installed through Homebrew) results in no error occurring, although I don't get any warnings/errors. Changing the linter to a nonexistent command (e.g. aksdjgh) yields the original error.

This doesn't appear to happen on Git Bash in Windows, although I'm not sure anything is even running in the first place. It doesn't happen in Neovim either.

Based on a quick glance at the vim source, it looks like that error occurs when trying to write to a channel, but not all the text is written despite the fact there is no channel error. Maybe a buffer somewhere is getting filled too early?

vim --version outputs this:

VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Nov  8 2016 15:11:16)
MacOS X (unix) version
Included patches: 1-71
Compiled by Homebrew
Huge version without GUI.  Features included (+) or not (-):
+acl             +file_in_path    +mouse_sgr       +tag_old_static
+arabic          +find_in_path    -mouse_sysmouse  -tag_any_white
+autocmd         +float           +mouse_urxvt     +tcl
-balloon_eval    +folding         +mouse_xterm     +termguicolors
-browse          -footer          +multi_byte      +terminfo
++builtin_terms  +fork()          +multi_lang      +termresponse
+byte_offset     -gettext         -mzscheme        +textobjects
+channel         -hangul_input    +netbeans_intg   +timers
+cindent         +iconv           +num64           +title
-clientserver    +insert_expand   +packages        -toolbar
+clipboard       +job             +path_extra      +user_commands
+cmdline_compl   +jumplist        +perl            +vertsplit
+cmdline_hist    +keymap          +persistent_undo +virtualedit
+cmdline_info    +lambda          +postscript      +visual
+comments        +langmap         +printer         +visualextra
+conceal         +libcall         +profile         +viminfo
+cryptv          +linebreak       -python          +vreplace
+cscope          +lispindent      +python3         +wildignore
+cursorbind      +listcmds        +quickfix        +wildmenu
+cursorshape     +localmap        +reltime         +windows
+dialog_con      +lua             +rightleft       +writebackup
+diff            +menu            +ruby            -X11
+digraphs        +mksession       +scrollbind      -xfontset
-dnd             +modify_fname    +signs           -xim
-ebcdic          +mouse           +smartindent     -xpm
+emacs_tags      -mouseshape      +startuptime     -xsmp
+eval            +mouse_dec       +statusline      -xterm_clipboard
+ex_extra        -mouse_gpm       -sun_workshop    -xterm_save
+extra_search    -mouse_jsbterm   +syntax
+farsi           +mouse_netterm   +tag_binary
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
  fall-back for $VIM: "/usr/local/share/vim"
Compilation: clang -c -I. -Iproto -DHAVE_CONFIG_H   -DMACOS_X_UNIX  -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: clang   -L. -fstack-protector -L/usr/local/lib -L/opt/X11/lib -L/usr/local/opt/libyaml/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/gdbm/lib -L/usr/local/opt/gmp/lib -L/usr/local/opt/libffi/lib  -L/usr/local/lib -o vim        -lncurses -liconv -framework Cocoa  -pagezero_size 10000 -image_base 100000000 -L/usr/local/lib -lluajit-5.1 -mmacosx-version-min=10.12 -fstack-protector-strong -L/usr/local/lib  -L/usr/local/Cellar/perl/5.24.0_1/lib/perl5/5.24.0/darwin-thread-multi-2level/CORE -lperl -lm -lutil -lc  -L/usr/local/opt/python3/Frameworks/Python.framework/Versions/3.5/lib/python3.5/config-3.5m -lpython3.5m -framework CoreFoundation -F/System/Library/Frameworks -framework Tcl -framework CoreFoundation -lruby.2.3.0 -lgmp -lobjc -L/usr/local/Cellar/ruby/2.3.1_2/lib

from ale.

I wonder if the bug should be reported in MacVim. As near as I can tell, I'm doing everything I should be doing in VimL, and MacVim is barfing.

from ale.

I mangled a copy of vim to get more information about what is going on. It appears that the write fails due to a broken pipe. I have no idea what exactly that means.

from ale.

I opened an issue on the MacVim repo for this. Maybe some answers will come from there.

from ale.

why issue is closed? How to fix it?

from ale.

This issue is still open. No one has a solution at the moment.

from ale.

how to turn off ALE for a file?

from ale.

https://github.com/w0rp/ale#faq-disable-linters See here. You can specify an empty List of linters for a given filetype.

from ale.

let g:ale_linters = {} does not turn ALE off

from ale.

it continues spamming write_buf_line after disabling linting on typing, on save, on enter, etc.

from ale.

Remove the plugin then.

from ale.

how about fix

from ale.

This is a long running problem, and I don't have a solution for it. If anyone knows how to fix this problem once and for all, please do so.

from ale.

This problem isn't purely the fault of this plugin. There is something wrong with certain versions of Vim on certain terminals which causes weird error output for something that the documentation says should work, but clearly doesn't. I have never been able to figure out exactly why this bug happens with some versions of Vim, and I've never seen anyone propose a workable solution.

from ale.

add command to disable ALE
test it with file of type .pl (perl), size about 5k lines, latest vim

from ale.

I just updated ALE then I got the same error message on Ubuntu. It appears only at the first to open Vim process with a Python file. After a second, it disappears automatically.

This bug has been since a3b7056.

from ale.

@sublee I think you saw the same error message, but with a different cause.

The error describes a failure to write to a channel for a job, such as when a command doesn't read stdin. I realised that not only was the last command in a chain of commands, such as with flake8, reading stdin, but every command in the chain was reading the Vim buffer, for no good reason. I have pushed a commit now which will make it so only the last command in the chain reads the Vim buffer, which should work better, and was what I originally intended anyway.

I suppose having a command in the middle of the chain read the Vim buffer could be useful in future. I'll open an issue for an enhancement to add this option.

Try pulling again, and see if this fixes your issues.

I still don't know why the problem for this GitHub issue persists for some MacVim users. I suspect it has something to do with commands not being able to read from stdin, when they should be able to do so.

from ale.

@w0rp Your patch fixed my problem. Thank you. 😄

from ale.

Awesome.

from ale.

Sweet, confirmed that it is fixed. But the description of fix has me concerned for another issue. For golang, linters like gometalinter expect the source to stay in certain directories (on $GOPATH) for linting to work. Sounds like this new behavior won't work with such linting.

from ale.

That'll be okay, in a sense. The Go linters are being worked on, and they will work completely differently.

Some of them might end up being tools which only run on the files on disk, versus most other things which can be checked as you're typing changes. Go tools seem so amazingly stubborn as to prevent you doing pretty much anything but compiling Go with a very specific set of directories. See issue #333

from ale.