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/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. >You would have seen a line with no ^M at the end? But your last line indeed has no ^M at the end, how come you didn't see it? 0x10 alone gives an *end* of line, not necessarily a *begin* of line. Any character after that, if there is one, goes on a new line. If the last line lacks an end-of-line it is *B* *R* *O* *K* *E* *N*, OK? Presence of an end-of-line character at the end of the last line doesn't mean an empty line, it means that the file is correctly formatted. If there isn't one, Vim will say [noeol] when reading and add an EOL when writing. Since there originally was a line lacking a CR somewhere in the middle of your file, Vim detected "unix" fileformat, showed ^M everywhere except on that line and the last one, and, on writing, added a Unix-style end-of-line (if not aleady present) at the end of the file. When you repaired the error in the middle but left the error at the end unchanged, this lone LF at the end caused the error to persist. If you had, as I already told you twice (this is the third one) done :set fileformats= :e ++ff=dos list02.p :w your file would have been repaired immediately. SO WHY DIDN'T YOU?
Because I'm trying to fight stupidity. In this case, mine. It's like with rebooting windows: Yes, it fixes the problem, but I prefer to know what caused it in the first place. As long as there was something mysterious about this problem, I keep asking. As you so elaborately explained everything now, including shouting, now everything is clear, I can sleep well knowing that even if I kindly ask and try to get as much information as possible, there will still be someone shouting at me. Thanks for your help. And this is not meant sarcastically. Thomas -- GPG-Key: tengelke.de/thomas_michael_engelke.asc
