--- Begin Message ---
|
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"
--- End Message ---
--- Begin Message ---
|
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
> <address@hidden>
> 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.
--- End Message ---