2007/5/15, A.J.Mechelynck <[EMAIL PROTECTED]>:
Thomas Michael Engelke wrote: > 2007/5/15, A.J.Mechelynck <[EMAIL PROTECTED]>: >> Thomas Michael Engelke wrote: >> > 2007/5/14, Andy Wokula <[EMAIL PROTECTED]>: >> >> Thomas Michael Engelke schrieb: >> >> > :set fileformats? >> >> > >> >> > gives >> >> > >> >> > "fileformats=dos,unix", so both formats are available, yet the >> >> > detection and switching does not seem to work. >> >> >> >> Are you sure _every_ line ends in "^M"? >> > >> > Positive. Every single line shows an ^M at the end. "set fileformat" >> > gives "unix" after loading. Setting fileformat to "dos" doesn't change >> > the files interpretation in vim. Somehow I think I miss something. >> > >> >> If 'fileformats' includes "dos", then if _all_ lines end in CR+LF, the >> 'fileformat' should be set (locally) to "dos". >> >> But a single line without a CR causes 'fileformat' to be set to >> "unix", and >> all other lines show a ^M >> >> Test 1: >> >> Load the file. Then: >> >> /[^[:return:]]$ >> >> If there is a line ending in LF-without-CR, this search should find it. >> >> Test 2, variant a: To remove all carriage-returns at end-of-line: >> >> :set fileformats= >> :e ++ff=dos filename >> :setlocal ff=unix >> :w >> >> Test 2, variant b: to repair any lines where a CR is missing, (by >> adding it): >> >> same as 2a, but omit the line with ":setlocal ff=unix". >> >> >> Then exit Vim and reload the file with your usual settings to see if the >> problem has gone away. If it hasn't, do you still see it with >> >> vim -u /usr/local/share/vim/vim71/vimrc_example.vim >> >> (replace the path if necessary by wherever Vim sets $VIMRUNTIME on your >> installation: on Windows it might be >> >> vim -u "C:\Program Files\Vim\vim71\vimrc_example.vim" >> >> instead)? > > Hello Tony, and thanks for your extensive answer. Unfortunately, this > is what I can report. To make things easier, I'll attach the file I am > talking about to this message so that you can either check for > yourselves and/or see that I'm telling the truth. > > What is the current state: Of course, there's one line without 0x13 > 0x10 at the end, and that is the last line. As I checked using your > regex (I'm always forgetting the :word:-syntax is available as well, > which makes it difficult as I can never remember how to search for a > hex char), I found one single line except the last one without 0x13 > 0x10 at the end. I removed the line in joining it with the line above > (multi line command) and saved the file. I closed it, closed vim and > reopened the file again. The problem persists. Now the only line your > regex finds is the last one. "set fileformats" still evaluates to > "dos,unix". "set fileformat" after loading the file evaluates to > "unix". Setting it to "dos" via "set fileformat=dos" does not help the > issue.Apparently your last line still has a LF without CR, causing the heuristic to detect the file's 'fileformat' as "unix". Ends of lines are line ENDINGS, not line SEPARATORS: even the last line must have one, for various reasons, the most obvious of which is that, if "file1" lacks a proper end-of-file, copy file1+file2 file3 will concatenate the last line of file1 with the first line of file2, making them a single line somewhere in the middle of file3. Try, as I said in my previous post, vim :set fileformats= " cancel autodetect of fileformat :edit ++ff=dos list02.p " force 'dos' fileformat Then saving the file should add a proper CR+LF ending to the last line (and to any other line lacking a CR). > > The example file of vim (in my case, > c:\Programme\vim\vim71a\vimrc_example.vim) loads fine and gets the > fileformat "dos", as expected. With -u before it on the Vim command-line, Vim should use it instead of your vimrc, not as an editfile.
Assuming that fileformat "unix" means 0x10 means "open a new line" which seems to be the case (0x13 stays as ^M, 0x10 is interpreted as a new line), shouldn't this mean that in the last line there is a line break missing? If I would have seen a line there with no ^M at the end I would have seen the problem right away. But this way, it seems a little odd that although 0x13 0x10 gives a ^M and a new line, 0x10 alone does not give a new line. -- GPG-Key: tengelke.de/thomas_michael_engelke.asc
