Ale: E631: write_buf_line()(): write failed

[junkblocker]

While using ale in MacVim GUI this message appears in the command line very very frequently. There are also some others I am seeing with a simple .vimrc

set nocompatible
set nu
set runtimepath+=~/.vim.old/neobundles/ale

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 25042 dead
E15: Invalid expression: s:job_info_map[a:job].linter
line   15:
E716: Key not present in Dictionary: process 25042 dead
line   16:
E121: Undefined variable: linter
E116: Invalid arguments for function remove
line    1:
E716: Key not present in Dictionary: process 25043 dead
E15: Invalid expression: s:job_info_map[a:job].linter
line   15:
E716: Key not present in Dictionary: process 25043 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
E631: write_buf_line()(): write failed
E631: write_buf_line()(): write failed 

Vim Version is 8.0.020 and there is no .vim/ for this test (as seen above only ale is being added manually).

[prashcr]

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

[w0rp]

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.

[w0rp]

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

[prashcr]

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.

[junkblocker]

@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.

[junkblocker]

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.

[junkblocker]

And it doesn't happen with nvim.

[junkblocker]

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

[w0rp]

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?

[junkblocker]

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

[w0rp]

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

[bimlas]

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.

[w0rp]

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.

[regedarek]

I have this the same on my vim.

[w0rp]

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

[bimlas]

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

[w0rp]

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.

[bimlas]

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.

[w0rp]

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.

[bimlas]

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.

[jwilliams108]

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.

[bimlas]

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

[bimlas]

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!

[bimlas]

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

[junkblocker]

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

sudo npm install -g jshint

Nothing else. No special configuration etc.

[bimlas]

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.

[w0rp]

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

[bimlas]

$ 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...

[w0rp]

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?

[bimlas]

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}

[bimlas]

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.

[bimlas]

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}

[w0rp]

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.

[w0rp]

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.

[w0rp]

@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.

[w0rp]

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.

[bimlas]

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.

[w0rp]

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?

[bimlas]

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

[bimlas]

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

[w0rp]

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.

[bimlas]

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

[w0rp]

@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.

[bimlas]

Everything works fine for me. Good job!

[w0rp]

Nice. :+1:

@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.

[junkblocker]

The problem is still present on MacVim.

[w0rp]

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.

[w0rp]

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

[junkblocker]

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

[w0rp]

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.

[junkblocker]

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 

[w0rp]

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.

[junkblocker]

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',
 \})

[w0rp]

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.

[w0rp]

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

[w0rp]

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.

[cwonrails]

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

[w0rp]

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.

[cwonrails]

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

[john-kurkowski]

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

[w0rp]

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.

[ts826848]

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

[w0rp]

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.

[ts826848]

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.

[ts826848]

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

[w0rp]

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

[ts826848]

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.

[squm]

why issue is closed? How to fix it?

[w0rp]

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

[squm]

how to turn off ALE for a file?

[w0rp]

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

[squm]

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

[w0rp]

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.

[squm]

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

[w0rp]

Remove the plugin then.

[squm]

how about fix

[w0rp]

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.

[w0rp]

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.

[squm]

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

[sublee]

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.

[w0rp]

@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.

[sublee]

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

[w0rp]

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

[w0rp]

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.

[sublee]

Awesome.

[junkblocker]

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.

[w0rp]

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