Error on typing

[Avi-D-coder]

Brand new reinstall
vim version: NVIM v0.5.0-322-g270cd623e
term: xterm-256color
platform: linux

Plug 'euclio/vim-markdown-composer', { 'do': function('BuildComposer') }

Error detected while processing function <SNR>111_sendBuffer: 
line    4:
E475: Invalid argument: Channel doesn't exist

2020-01-27T23:06:32.470110061-05:00 [ERROR] log_panics:thread 'main' panicked at 'invalid type: integer `0`, expected a string': src/main.rs:93
stack backtrace:
   0: log_panics::init::{{closure}}
   1: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:468
   2: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:373
   3: std::panicking::begin_panic_fmt
             at src/libstd/panicking.rs:328
   4: markdown_composer::main
   5: std::rt::lang_start::{{closure}}
   6: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:48
      std::panicking::try::do_call
             at src/libstd/panicking.rs:287
   7: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:78
   8: std::panicking::try
             at src/libstd/panicking.rs:265
      std::panic::catch_unwind
             at src/libstd/panic.rs:396
      std::rt::lang_start_internal
             at src/libstd/rt.rs:47
   9: main
  10: __libc_start_main
  11: _start

[euclio]

Can you share your BuildComposer function? I'm not able to reproduce on my Mac using nightly nvim.

[Avi-D-coder]

function! BuildComposer(info)
  if a:info.status != 'unchanged' || a:info.force
    if has('nvim')
      !cargo build --release
    else
      !cargo build --release --no-default-features --features json-rpc
    endif
  endif
endfunction

[djromero]

Exact same error in Ubuntu. Editing a markdown file will launch the browser with the preview but it's just a blank page. The error message is the one above.
It started after updating the plugin yesterday (initially installed like 1 month ago).

[euclio]

Does it still happen if vim-markdown-composer is the only active plugin? Or with no other vimrc configuration? I'm still unable to reproduce using NVIM v0.5.0-346-g406464fa6 on my Linux box.

[djromero]

It happens with a minimal vimrc running NVIM v0.5.0-343-ge956ea767:

set nocompatible
syntax enable

call plug#begin(stdpath('data') . '/plugged')

function! BuildComposer(info)
  if a:info.status != 'unchanged' || a:info.force
    if has('nvim')
      !cargo build --release --locked
    else
      !cargo build --release --locked --no-default-features --features json-rpc
    endif
  endif
endfunction

Plug 'euclio/vim-markdown-composer', { 'do': function('BuildComposer') }

call plug#end()

This is logged in ~/.local/share/nvim/log:

ERROR 2020-01-31T09:17:50.127 20637 call_set_error:623: RPC: ch 3 sent an invalid message, closed.

Is there any other log I can check?

The plugin is master at 724c8eb.
Building it in the command line makes no difference.

[euclio]

I just added some additional logging and error handling, which will hopefully help expose the issue.

[dimbleby]

You've put the trace where it doesn't help, because the deserializing has already failed by then.

I used sysdig to monitor stdin on the markdown-composer process, and it looks as though it is receiving the text "Message is not an array". Any idea where that comes from?!

$ sudo sysdig -s4096 -A -c stdin "proc.exe contains mark"
Message is not an array

[euclio]

Interesting. Looks like nvim will send that message over the channel if it receives non-msgpack data. Can you check what vim-markdown-composer and/or cargo is sending on stdout?

[dimbleby]

cargo?!

I'm not seeing anything at all from either neovim or markdown-composer - which doesn't seem like it can be right to me, but I'm not sure what I'm doing wrong...

[euclio]

Anything on stderr from the markdown composer process?

[dimbleby]

Hmm, just running markdown-composer directly gives some output:

$ ./target/release/markdown-composer
START /usr/bin/exo-open --launch WebBrowser "http://[::1]:46318"
Running without a11y support!

I guess this comes from xdg-open, not sure if stdout from a child ought to be an issue here...

[dimbleby]

Yeah, std::process::Command says that it inherits stdin, stdout and stderr from the parent by default, so I bet this is the problem.

Probably wants a .stdout(Stdio::null()) somewhere?

[euclio]

Yep, that's almost certainly the issue. I'll send a patch to aurelius at some point today. Thank you for the debugging help!

[dimbleby]

Can confirm that hacking this locally does indeed fix the issue for me.