Bug 1496890 - File with DOS line breaks shows no empty line at end of files, while Windows editors do
Summary: File with DOS line breaks shows no empty line at end of files, while Windows ...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: vim
Version: 27
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Karsten Hopp
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-28 17:47 UTC by ell1e
Modified: 2017-10-03 15:25 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-10-02 13:05:17 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
How the file looks like in Vim (15.63 KB, image/png)
2017-09-28 17:47 UTC, ell1e
no flags Details
How the file looks like in Notepad (2.63 KB, image/png)
2017-09-28 17:47 UTC, ell1e
no flags Details

Description ell1e 2017-09-28 17:47:17 UTC
Created attachment 1332070 [details]
How the file looks like in Vim

Description of problem:

A file with DOS line breaks shows no empty line at end of files, while Windows editors do.

Here is the file in exact byte contents:

jonas@cyberman:~$ hexdump test.txt
0000000 6261 0d63 640a 6665 0a0d               
000000a
jonas@cyberman:~$

This shows up as attached in the notepad.png image on Windows (with a single line break).

However, in vim as attached in vim.png, while the file is clearly indicated to have dos line breaks, will show up with no empty line at the end.


Version-Release number of selected component (if applicable):


How reproducible:
100%

Steps to Reproduce:
1. Create the above file e.g. with hex dump
2. Send yourself via e-mail or usb stick to a windows machine and open in Windows Notepad
3. Open it in vim

Actual results:
inconsistent rendering of Windows line breaks compared to actual Windows editors (which should IMHO be considered canonical source of how Windows line breaks behave)

Expected results:
consistent result with Windows editor of rendering and handling Windows line breaks

Additional info:

Comment 1 ell1e 2017-09-28 17:47:47 UTC
Created attachment 1332071 [details]
How the file looks like in Notepad

Comment 2 ell1e 2017-09-28 19:29:42 UTC
Sorry, the default format of hex dump doesn't show the \r\n sequences clearly. Here is a better format that shows the separate bytes:

jonas@cyberman:~$ hexdump -b test.txt
0000000 141 142 143 015 012 144 145 146 015 012                        
000000a

Comment 3 Zdenek Dohnal 2017-10-02 13:05:17 UTC
Hi Jonas,

IMHO it is not a bug - displaying of files is AFAIK non-standardized (the fact Notepad does it in certain way it doesn't make it standard IMO) and it is in application's competency, how file will be displayed. IMO it would be bug if file in one format will be showed differently than in other format in same application (which I confirmed it is not the case - VIm behaves same for dos file or unix file) - user shouldn't notice that opened file is f.e. in dos file format (it is not relevant fact for user to see it is dos file or unix file).
VIm cursor seems to stay on last line (line with last CR+LF/CR/LF). Situation, which happens in Notepad, happens in VIm when you explicitly enter new line. If you really consider this issue as bug, contact VIm upstream on its github.

Comment 4 ell1e 2017-10-03 15:21:01 UTC
> displaying of files is AFAIK non-standardized

Actually in POSIX it is in regards to line breaks, which is why VIM displays it that way - however, applying POSIX interpretation to DOS line breaks is IMHO nonsensical.

I filed an upstream bug report here: https://github.com/vim/vim/issues/2179

Comment 5 ell1e 2017-10-03 15:23:32 UTC
Another small remark:

> user shouldn't notice that opened file is f.e. in dos file format (it is not relevant fact for user to see it is dos file or unix file).

The problem is that they will if they look close enough, since such a file will have an unexplained display difference to Microsoft Windows. Clearly goal of supporting DOS line breaks should be to get the same behavior as on the system where they originate from, shouldn't it?

Anyway, I suggest we wait to see what the upstream developers think of this

Comment 6 ell1e 2017-10-03 15:25:04 UTC
Sorry for the comment spam, but I linked the wrong upstream issue. Here is the correct link: https://github.com/vim/vim/issues/2183


Note You need to log in before you can comment on or make changes to this bug.