bug#36655: Document how CRLF file with none at the end is interpreted as

bug#36655: Document how CRLF file with none at the end is interpreted as

[積丹尼 Dan Jacobson]

(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"

bug#36655: Document how CRLF file with none at the end is interpreted as

[Eli Zaretskii]

> From: 積丹尼 Dan Jacobson
>  <jidanni@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.