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

[Michael Albinus]

>> I guess if we wanted to more faithfully simulate a pipe, we'd have to
>> send the process input via something like a base64 decoder and get the
>> output via a base64 encoder: this way not only stdin/stdout is a pipe but
>> we can protect ourselves from the way ttys can mess with some bytes (as
>> seen in this thread) and also overcome some of the limits of some ttys
>> when sending "large" amounts of data at a time (IIRC on some systems
>> this can either freeze the tty or the tty may insert extra chars like
>> ^A or some such; my memory says the macOS kernel was such a culprits
>> some years ago).
>>
>> The cure way be worse than the disease, tho.
>
> Yes.
>
> Maybe we could play with "stty raw", when
> (tramp-)process-connection-type is nil or 'pipe.

It looks like "stty -icrnl" suppresses the \r\n conversion in a shell. I
have adapted Tramp to send this command to a remote async process, when
connection type is nil or 'pipe. The Tramp documentation has a new
subsection now:

--8<---------------cut here---------------start------------->8---
6.5.7 Remote process connection type

Asynchronous processes differ in the way, whether they use a pseudo tty,
or not.  This is controlled by the variable ‘process-connection-type’,
which can be ‘t’ or ‘pty’ (use a pseudo tty), or ‘nil’ or ‘pipe’ (don’t
use it).  TRAMP is based on running shells on the remote host, which
require a pseudo tty.  Therefore, it declares the variable
‘tramp-process-connection-type’, which carries this information for
remote processes.  Per default, its value is ‘t’.  The name of the
remote pseudo tty is returned by the function ‘process-tty-name’.

   If a remote process, started by ‘start-file-process’, shouldn’t use a
pseudo tty, this is emulated by let-binding this variable to ‘nil’ or
‘pipe’.  There is still a pseudo tty for the started process, but some
terminal properties are changed, like suppressing translation of
carriage return characters into newline.

   The function ‘make-process’ allows an explicit setting by the
‘:connection-type’ keyword.  If this keyword is not used, the value of
‘tramp-process-connection-type’ is applied instead.
--8<---------------cut here---------------end--------------->8---

The Tramp test suite has been extended in order to test this, see
tramp-test30-make-process. Committed to Emacs master, and will also be
available with next Tramp 2.5.1.2 on GNU ELPA.

Thomas, could you test this, again? I guess the following patch is all
what's needed in lsp-mode:

*** /home/albinus/.emacs.d/elpa/lsp-mode-20210802.619/lsp-mode.el.~1~   
2021-08-05 17:13:45.133161987 +0200
--- /home/albinus/.emacs.d/elpa/lsp-mode-20210802.619/lsp-mode.el       
2021-08-12 20:41:28.232443184 +0200
***************
*** 6956,6962 ****
                                                                   (format 
"/tmp/%s-%s-stderr" name
                                                                           
(cl-incf lsp--stderr-index))))))))
                            (process-environment
!                            (lsp--compute-process-environment environment-fn)))
                       (let ((proc (start-file-process-shell-command 
process-name
                                                                     (format 
"*%s*" process-name)
                                                                     
wrapped-command)))
--- 6956,6963 ----
                                                                   (format 
"/tmp/%s-%s-stderr" name
                                                                           
(cl-incf lsp--stderr-index))))))))
                            (process-environment
!                            (lsp--compute-process-environment environment-fn))
!                         (tramp-process-connection-type 'pipe))
                       (let ((proc (start-file-process-shell-command 
process-name
                                                                     (format 
"*%s*" process-name)
                                                                     
wrapped-command)))

Best regards, Michael.