From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Thomas Ross Newsgroups: gmane.emacs.devel Subject: Re: Tramp and conversion of \r\n into \n Date: Wed, 4 Aug 2021 21:46:02 -0400 Message-ID: <3474731f-eada-8185-1a21-f337fd55b38b@thomasross.io> References: <193e76e900f64f01a39893b12cf7c4ff@3ds.com> <871rfw900w.fsf@gmx.de> <87sg8c7i5w.fsf@gmx.de> <4f2b42e36d924f83883e120e601d40f7@3ds.com> <87tuslzrw1.fsf@gmx.de> <7135a39a200c4f8397c8bddb9da8d3fc@3ds.com> <8736014u95.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27715"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 Cc: APEL Martin , "emacs-devel@gnu.org" To: Michael Albinus , yyoncho Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 05 07:41:33 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mBW8L-00075V-5N for ged-emacs-devel@m.gmane-mx.org; Thu, 05 Aug 2021 07:41:33 +0200 Original-Received: from localhost ([::1]:44688 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mBW8J-0000JG-O4 for ged-emacs-devel@m.gmane-mx.org; Thu, 05 Aug 2021 01:41:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38956) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mBSSY-00041q-23 for emacs-devel@gnu.org; Wed, 04 Aug 2021 21:46:10 -0400 Original-Received: from smtp124.iad3a.emailsrvr.com ([173.203.187.124]:40329) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mBSSS-0006WP-SX for emacs-devel@gnu.org; Wed, 04 Aug 2021 21:46:09 -0400 X-Auth-ID: thomasross@thomasross.io Original-Received: by smtp24.relay.iad3a.emailsrvr.com (Authenticated sender: thomasross-AT-thomasross.io) with ESMTPSA id C93B623ACE; Wed, 4 Aug 2021 21:46:02 -0400 (EDT) In-Reply-To: <8736014u95.fsf@gmx.de> Content-Language: en-US X-Classification-ID: 4ada6f6a-aa69-4fe4-a1cd-24af450dcd07-1-1 Received-SPF: pass client-ip=173.203.187.124; envelope-from=thomasross@thomasross.io; helo=smtp124.iad3a.emailsrvr.com X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.132, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 05 Aug 2021 01:40:39 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:272070 Archived-At: 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 > > {<...JSON here...>} Emacs replaces the CRs with LFs, which confuses clangd: > Content-Length: 2134 > > {<...JSON here...>} 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.