doesn't work in neovim 2.0 on windows when shellslash is enabled

[prabirshrestha]

Enabled logging by let g:tscompletejob__debug__ = 1

This works in vim8.

In neovim 0.2 on windows.

@justinmk here is another case where the outputs are different when set shellslash is enabled. Not sure if this is the problem or something else that is actually causing tscompletejob to not work in neovim on windows. I don't think it is a bug in https://github.com/prabirshrestha/asyncomplete-tscompletejob.vim since even things like goto definition doesn't work.

[prabirshrestha]

After further digging seems like the actual bug in in stdout parsing in tscompletejob. I had to add +1 for the elseif and it worked on windows in both vim8 and neovim but it defeats the purpose of if and elseif so the bug is most likely in s:nvimOnStdout.

func! s:onOut(self, job, msg) dict
....
    if s:current_content_length > len
        return
    elseif s:current_content_length + 1 < len
        " something is wrong, so response is dropped
        call s:clearResponseCache()
        return
    endif
....

In async.vim I use split(a:data, "\n", 1) to convert vim to neovim array data and then use join(a:data, "\n") if I want to get plain string. Something similar needs to be done here. Ideally embedding async.vim like how minpac does might be better than writing own wrapper. k-takata/minpac#5

[runoshun]

Thank you your report. I fix parsing response in s:onOut.
I think, len() of nvim on windows is returning strange value compared with other platform's vim/nvim.

[prabirshrestha]

Thanks. Verified works in neovim on windows with shellslash enabled.

[justinmk]

len() of nvim on windows is returning strange value compared with other platform's vim/nvim.

@runoshun Can you give a sample of the result of :echom string(s:current_content) in the case where len() is returning the wrong result on Windows?

[runoshun]

@justinmk Sorry, my idea was wrong. It is not problem of len().

Only on nvim windows, trailing ^M exists in data which is passed to event handler(on_stdout option of jobstart()). The results of echo len(s:current_content) and echo string(s:current_content) are as follows.

# vim linux 8.0.586
77
'{"seq":0,"type":"response","command":"reload","request_seq":1,"success":true}'

## nvim linux 2.0.0
77
'{"seq":0,"type":"response","command":"reload","request_seq":1,"success":true}'

## gvim windows 8.0.3
77
'{"seq":0,"type":"response","command":"reload","request_seq":1,"success":true}'

## nvim windows v0.2.1-25-g2e3b78d1
78
'{"seq":0,"type":"response","command":"reload","request_seq":1,"success":true}^M'

Certainly, trailing ^M exists in the raw output of process on both linux and windows, but only the behavior of nvim windows is different.

You can get the raw output of tscompletejob backend as follows, if you need it.

node C:\<Path to tscompletejob>\autoload\tscompletejob\tsswrapper\tsswrapper.js < command.json > output

command.json is as follows.

{"type": "request", "command": "reload", "seq": 1, "arguments": {"file": "C:\<Path to tscompletejob>/test/sample1.ts", "tmpfile": "/tmp/nvimT2Pm4q/1"} }

[justinmk]

Certainly, trailing ^M exists in the raw output of process on both linux and windows

Why would CR exist on linux?

[runoshun]

It is my mistake. On linux, EOL of output is only LF. On windows, it is CRLF.

[prabirshrestha]

Is it that typescript is using auto EOL based on OS or is it neovim bug for sure? There is also a flag in typescript compiler. microsoft/TypeScript#2921