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: Fri, 6 Aug 2021 22:08:36 -0400 Message-ID: <7659e691-ac33-7d05-d06b-467bd0d6656c@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> <3474731f-eada-8185-1a21-f337fd55b38b@thomasross.io> <83sfzoju15.fsf@gnu.org> 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="5228"; 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: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Aug 07 07:17:51 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 1mCEiU-00019u-Pv for ged-emacs-devel@m.gmane-mx.org; Sat, 07 Aug 2021 07:17:50 +0200 Original-Received: from localhost ([::1]:35934 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mCEiT-0006zQ-Fc for ged-emacs-devel@m.gmane-mx.org; Sat, 07 Aug 2021 01:17:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48408) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mCBlP-0005B7-RE for emacs-devel@gnu.org; Fri, 06 Aug 2021 22:08:39 -0400 Original-Received: from smtp116.ord1d.emailsrvr.com ([184.106.54.116]:43607) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mCBlN-0007NK-LP for emacs-devel@gnu.org; Fri, 06 Aug 2021 22:08:39 -0400 X-Auth-ID: thomasross@thomasross.io Original-Received: by smtp23.relay.ord1d.emailsrvr.com (Authenticated sender: thomasross-AT-thomasross.io) with ESMTPSA id A2E1B20170; Fri, 6 Aug 2021 22:08:36 -0400 (EDT) In-Reply-To: <83sfzoju15.fsf@gnu.org> Content-Language: en-US X-Classification-ID: 44811e8e-207d-4815-9d3f-2612eaab5f3e-1-1 Received-SPF: pass client-ip=184.106.54.116; envelope-from=thomasross@thomasross.io; helo=smtp116.ord1d.emailsrvr.com X-Spam_score_int: -44 X-Spam_score: -4.5 X-Spam_bar: ---- X-Spam_report: (-4.5 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-2.619, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sat, 07 Aug 2021 01:16:58 -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:272154 Archived-At: > 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. Yes, it is in `emacs -Q` -- this was determined to be done by the TTY though, not Emacs. See Stefan's emails for more details. Sorry for the confusion. Thanks, Thomas. On 2021-08-05 2:16 a.m., Eli Zaretskii wrote: >> From: Thomas Ross >> Date: Wed, 4 Aug 2021 21:46:02 -0400 >> Cc: APEL Martin , >> "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 >>> >>> {<...JSON here...>} >> >> 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. >