GNU bug report logs - #36655
Document how CRLF file with none at the end is interpreted as

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36655 in the body.
You can then email your comments to 36655 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Document how CRLF file with none at the end is interpreted as
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.

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  |  </trk>..</gpx>|
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"

Message #10 received at 36655-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: 36655-done <at> debbugs.gnu.org
Subject: Re: bug#36655: Document how CRLF file with none at the end is
 interpreted as
Date: Thu, 18 Jul 2019 08:58:09 +0300

> From: 積丹尼 Dan Jacobson
>  <jidanni <at> jidanni.org>
> 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  |  </trk>..</gpx>|
> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.