Re: Tramp and conversion of \r\n into \n

[Thomas Ross]

Hi Michael,

> Understood. I will check, but I cannot promise anything. I still don't
> know, why the Content-Length line disappears with older Tramp. It is not
> (only) an eol conversion problem, I believe.

I looked into this a bit and it seems like this isn't a TRAMP-specific
issue.

Running this Elisp snippet (after evaling both these sexps, open the
"hexdump" buffer to see the output -- you may need to scroll up to
actually see it) shows you that the carriage return gets replaced with a
line feed by Emacs:

> (make-process :name "hexdump" :command '("hexdump" "-v" "-e" "/1 \"%02X\n\"") 
> :buffer "hexdump")
> (process-send-string "hexdump" "abc\r\n")

on my system (Linux, Emacs 27.1):

> 61
> 62
> 63
> 0A
> 0A

Note that there's 61 ("a"), 62 ("b"), 62 ("c"), and two 0As (LF). The
first 0A should really be a 0D (CR). I believe this conversion is likely
done by the call to encode_coding_object inside send_process
(process.c), but I might be wrong. I would need to sit down and step
through the code with gdb to confirm.

In a previous email in this thread (2020-12-16), you wrote:

> That is, both the Content-Length header is missing as well as the final "}".

I don't think the Content-Length header is actually missing. I think
clangd doesn't print it (even with --log=verbose). If you use the
wrapper script that Martin provided, I think you will see it in the logs
for standard input. The actual issue is that instead of sending this to
the process (all literal newlines are for display only):

> Content-Length: 2134<CR><LF>
> <CR><LF>
> {<...JSON here...>}<LF>

Emacs replaces the CRs with LFs, which confuses clangd:

> Content-Length: 2134<LF><LF>
> <LF><LF>
> {<...JSON here...>}<LF>

I verified this by looking at the hexdump of /tmp/clangd-logs (which
contains the data lsp-mode passes to clangd over stdin using the wrapper
script Martin provided).

Let me know what you think. It would be awesome if we were able to track
this issue down and have this all work without the direct async
processes (since there are a bunch of limitations there).

Thanks,
Thomas.