bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: 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@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]