Hi Eric, Do this to see which line-endings the buffer is associated with...
:set ff? Do this to change them... :set ff=unix :wq For info... :help 'fileformat On WinXP, I strictly use the unix (0A) line endings, I do not use mac (0D) or dos (0D 0A). I wish Vim internally supported nul (00) line endings, but alas. Note: if you transfer files to/fro Unix and Windows with FTP, you can transfer text files as ASCII to do the end-of-line conversion for you. Note, mac (0D) line endings are found on Apple DOS, ProDOS, GS/OS, and System 9 and earlier OS's. OS X is unix (0A) line endings, mostly, these days. Note, dos (0D 0A) line endings are CP/M, QDOS, PC-DOS, MS-DOS, DR-DOS, Win16, Win32, WinNT (3.1, 3.5, 4.0, 2000, XP), WinNT64, OS/2 1.x (16-bit), OS/2 2.x (32-bit) and later. (There were some feeble, short-lived, unviable attempts by IBM to make OS/2 use unix line endings. Likewise, there were some feeble, short-lived, unviable attempts by Microsoft to make WinNT use unix line endings.) Note, unix (0A) line endings are on Unix and Unix-like OS's (including OS X), Amiga OS, and are an option as default for the Cygwin environment on Windows. Vim doesn't internally support "backwards" lf+cr (0A 0D), which was sometime seen back in the 70's on teletype machines and preferentially used by some printers and as the communication protocol by some dial-up BBS's. I don't know of any OS that utilizes lf+cr as the convention for end-of-line marker. Vim doesn't internally support nel (85) "next line", from ECMA-048 (approved as ISO 6429). I don't know of anyone that uses nel for encoding end-of-line. Even the Amiga OS, which supported nel (85), did not use it for end-of-line in files, and only rarely seen as an operational control character in certain data streams. Besides, since Windows code pages have usurped this (80 - 9F) range of encoding code points, and MacRoman puts glyphs there too, I don't expect there will be much of a revival for them. HTH, --Eljay
