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

[Eli Zaretskii <eliz@gnu.org>]

> From: Thomas Ross <thomasross@thomasross.io>
> Date: Wed, 4 Aug 2021 21:46:02 -0400
> Cc: APEL Martin <Martin.APEL@3ds.com>,
>  "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> > (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.

Is this in "emacs -Q"?  If so, such conversion should not happen, on
any OS.  Emacs converts CR on input, not on output, and
process-send-string does the latter.

> > Content-Length: 2134<CR><LF>
> > <CR><LF>
> > {<...JSON here...>}<LF>
> 
> Emacs replaces the CRs with LFs, which confuses clangd:

Again, this conversion can only happen on input, but you seem to be
talking about output.

It is possible that some Tramp magic causes this bytestream to be
input into Emacs at some point, as some temporary measure; in that
case, you should look for the problem at that point, where Emacs reads
these bytes, and disable decoding there.