From unknown Sat Aug 16 10:50:58 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#36655 <36655@debbugs.gnu.org> To: bug#36655 <36655@debbugs.gnu.org> Subject: Status: Document how CRLF file with none at the end is interpreted as Reply-To: bug#36655 <36655@debbugs.gnu.org> Date: Sat, 16 Aug 2025 17:50:58 +0000 retitle 36655 Document how CRLF file with none at the end is interpreted as reassign 36655 emacs submitter 36655 =E7=A9=8D=E4=B8=B9=E5=B0=BC Dan Jacobson severity 36655 wishlist thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 14 16:16:10 2019 Received: (at submit) by debbugs.gnu.org; 14 Jul 2019 20:16:10 +0000 Received: from localhost ([127.0.0.1]:46053 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmkun-0006pJ-SU for submit@debbugs.gnu.org; Sun, 14 Jul 2019 16:16:10 -0400 Received: from lists.gnu.org ([209.51.188.17]:38073) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmkuk-0006p1-8C for submit@debbugs.gnu.org; Sun, 14 Jul 2019 16:16:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49705) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hmkuj-0005Tc-66 for bug-gnu-emacs@gnu.org; Sun, 14 Jul 2019 16:16:06 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FROM_EXCESS_BASE64, RCVD_IN_DNSWL_NONE,URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hmkui-0004WG-37 for bug-gnu-emacs@gnu.org; Sun, 14 Jul 2019 16:16:05 -0400 Received: from brown.birch.relay.mailchannels.net ([23.83.209.23]:13337) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hmkuh-0004Sj-LV for bug-gnu-emacs@gnu.org; Sun, 14 Jul 2019 16:16:04 -0400 X-Sender-Id: dreamhost|x-authsender|jidanni@jidanni.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 8F9D034064D for ; Sun, 14 Jul 2019 20:15:59 +0000 (UTC) Received: from pdx1-sub0-mail-a88.g.dreamhost.com (100-96-11-126.trex.outbound.svc.cluster.local [100.96.11.126]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 08EA5341230 for ; Sun, 14 Jul 2019 20:15:59 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jidanni@jidanni.org Received: from pdx1-sub0-mail-a88.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.3); Sun, 14 Jul 2019 20:15:59 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jidanni@jidanni.org X-MailChannels-Auth-Id: dreamhost X-Juvenile-Abiding: 72e12ba27da542bd_1563135359306_2796193603 X-MC-Loop-Signature: 1563135359306:1852731908 X-MC-Ingress-Time: 1563135359306 Received: from pdx1-sub0-mail-a88.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a88.g.dreamhost.com (Postfix) with ESMTP id C4278804F5 for ; Sun, 14 Jul 2019 13:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=jidanni.org; h=from:to :subject:date:message-id:mime-version:content-type :content-transfer-encoding; s=jidanni.org; bh=eUefDmO6zg7o0Guu9h vBNlt1nBM=; b=LwXOporntPhno85jukGAPy3W26TBeeePHYtK9Ll9xKKFJ1Vsoe tNZufEqCIl1Lg8jtnJbp82lxgW2XfUI2fApSP7yU6Jo625Oln0V2SsFrzP8d1G6Q Ntwv/RxyQZedctK3AWkSwKFeJlXC/dJ0PUEmZ5YrqAfBETsJy38d8qeyg= Received: from jidanni.org (114-41-13-208.dynamic-ip.hinet.net [114.41.13.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jidanni@jidanni.org) by pdx1-sub0-mail-a88.g.dreamhost.com (Postfix) with ESMTPSA id 3559D80535 for ; Sun, 14 Jul 2019 13:15:53 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a88 From: =?utf-8?B?56mN5Li55bC8?= Dan Jacobson To: bug-gnu-emacs@gnu.org Subject: Document how CRLF file with none at the end is interpreted as Date: Mon, 15 Jul 2019 04:02:00 +0800 Message-ID: <87lfx0fkqv.5.fsf@jidanni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduvddrheehgdduheduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkgggtgfesthekredttddtjeenucfhrhhomhepnjjnnjcuffgrnhculfgrtghosghsohhnuceojhhiuggrnhhnihesjhhiuggrnhhnihdrohhrgheqnecukfhppeduudegrdeguddrudefrddvtdeknecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehjihgurghnnhhirdhorhhgpdhinhgvthepuddugedrgedurddufedrvddtkedprhgvthhurhhnqdhprghthheppeeruhhtfhdqkeerueerheeimhfphefnihehhegsveekreepucffrghnucflrggtohgsshhonhcuoehjihgurghnnhhisehjihgurghnnhhirdhorhhgqedpmhgrihhlfhhrohhmpehjihgurghnnhhisehjihgurghnnhhirdhorhhgpdhnrhgtphhtthhopegsuhhgqdhgnhhuqdgvmhgrtghssehgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptd Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 23.83.209.23 X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) (info "(emacs) Coding Systems") says For example, if the file appears to use the sequence carriage return a= nd linefeed to separate lines, DOS end-of-line conversion will be used. ^^^^^^^^^^^^^^ Each of the listed coding systems has three variants, which specify exactly what to do for end-of-line conversion: =E2=80=98...-unix=E2=80=99 Don=E2=80=99t do any end-of-line conversion; assume the file uses= newline to separate lines. (This is the convention normally used on Unix > > > > > ^^^^^^^^^^^^^^ and GNU systems, and macOS.) =E2=80=98...-dos=E2=80=99 Assume the file uses carriage return followed by linefeed to separate lines, and do the appropriate conversion. (This is the > > > > ^^^^^^^^^^^^^^ convention normally used on Microsoft systems.(1)) But then (info "(emacs) Recognize Coding") says Emacs recognizes which kind of end-of-line conversion to use ba= sed on the contents of the file: if it sees only carriage returns, or onl= y carriage return followed by linefeed sequences, then it chooses th= e end-of-line conversion accordingly. You can inhibit the automatic= use of end-of-line conversion by setting the variable =E2=80=98inhibit-eol-conversion=E2=80=99 to non-=E2=80=98nil=E2=80= =99. If you do that, DOS-style files will be displayed with the =E2=80=98^M=E2=80=99 characters visible= in the buffer; But wait. On the last INFO page you were taking about line separators. Now you are talking about end-of-lines. So for a file like $ tail -n 2 file.gpx | hd 00000000 20 20 3c 2f 74 72 6b 3e 0d 0a 3c 2f 67 70 78 3e | ..| which has a last line with no CR, no LF, nothing, the user does not know what will happen from just reading the manual. So the manual should say what will happen in that case. The file is not "all CR endings" nor "all CRLF endings" because the last line is lacking any ending. (Answer: indeed emacs is looking at only "separators" it turns out.) P.S., perhaps also mention require-final-newline here. emacs-version "26.1" From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 18 01:58:25 2019 Received: (at 36655-done) by debbugs.gnu.org; 18 Jul 2019 05:58:25 +0000 Received: from localhost ([127.0.0.1]:53287 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hnzQu-00062c-Re for submit@debbugs.gnu.org; Thu, 18 Jul 2019 01:58:25 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57018) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hnzQt-00062Q-EM for 36655-done@debbugs.gnu.org; Thu, 18 Jul 2019 01:58:23 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48189) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hnzQo-00033v-6D; Thu, 18 Jul 2019 01:58:18 -0400 Received: from [176.228.60.248] (port=3290 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hnzQn-0004ci-LJ; Thu, 18 Jul 2019 01:58:17 -0400 Date: Thu, 18 Jul 2019 08:58:09 +0300 Message-Id: <83zhlbyjda.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?56mN5Li55bC8?= Dan Jacobson In-reply-to: <87lfx0fkqv.5.fsf@jidanni.org> Subject: Re: bug#36655: Document how CRLF file with none at the end is interpreted as References: <87lfx0fkqv.5.fsf@jidanni.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 36655-done Cc: 36655-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: 積丹尼 Dan Jacobson > > Date: Mon, 15 Jul 2019 04:02:00 +0800 > > (info "(emacs) Coding Systems") says > > For example, if the file appears to use the sequence carriage return and > linefeed to separate lines, DOS end-of-line conversion will be used. > ^^^^^^^^^^^^^^ > Each of the listed coding systems has three variants, which specify > exactly what to do for end-of-line conversion: > > ‘...-unix’ > Don’t do any end-of-line conversion; assume the file uses newline > to separate lines. (This is the convention normally used on Unix > > > > > > ^^^^^^^^^^^^^^ > and GNU systems, and macOS.) > > ‘...-dos’ > Assume the file uses carriage return followed by linefeed to > separate lines, and do the appropriate conversion. (This is the > > > > > ^^^^^^^^^^^^^^ > convention normally used on Microsoft systems.(1)) > > But then > > (info "(emacs) Recognize Coding") says > Emacs recognizes which kind of end-of-line conversion to use based on > the contents of the file: if it sees only carriage returns, or only > carriage return followed by linefeed sequences, then it chooses the > end-of-line conversion accordingly. You can inhibit the automatic use > of end-of-line conversion by setting the variable > ‘inhibit-eol-conversion’ to non-‘nil’. If you do that, DOS-style files > will be displayed with the ‘^M’ characters visible in the buffer; > > But wait. On the last INFO page you were taking about line separators. > Now you are talking about end-of-lines. No, the text was talking about both. See above. > So for a file like > $ tail -n 2 file.gpx | hd > 00000000 20 20 3c 2f 74 72 6b 3e 0d 0a 3c 2f 67 70 78 3e | ..| > which has a last line with no CR, no LF, nothing, the user does not know > what will happen from just reading the manual. > > So the manual should say what will happen in that case. There's nothing to say, because when there's no EOL sequence at end of a line, nothing needs to be converted. So I'm closing this bug report. From unknown Sat Aug 16 10:50:58 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 15 Aug 2019 11:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator