Re: vim 7.1 and cr/lf interpretation
Gene Kwiecinski wrote: 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. Uhhh, don't think it *should* automagically delete the ^Ms. I'm always running into that, and in addition to an almost reflexive alt-EIFD to go dos-mode, I *still* always have to ':s/^V^M' to get rid of 'em, and I'm using version 6.4, not even 7.x, so it's definitely been around for a while. Setting ff=dos after the file is loaded changes nothing to the contents of the file data in memory, it only changes how the ends-of-lines will be represented on output. So if you have a file with mixed ends-of-lines and 'fileformat' detected as unix, using :setlocal ff=dos will result in some lines having CR+LF (where there was only LF before) and others (which already had CR+LF shown as ^M at end of line) will get CR+CR+LF. So this is not the way to go. To detect a file with mixed ends-of-lines as dos-format, we must first disable automatic unix filetype detection. One way to do this is to set the 'fileformats' (plural) option to the empty string: :set fileformats= Now we can manually detect the file's format (see :help ++opt): :e ++ff=dos filename which will interpret CR+LF as an end-of-line, and LF-without-CR also as an end-of-line. So now all lines (in memory) are as they should be, with no spurious end-of-line ^M showing. ^M will only appear if there is a CR not immediately followed by a LF (either a lone CR in the middle, or more than one CR before a LF). We must now save this file-in-memory to disk, to make the repairs permanent. Here we have the choice of how we want to save it: - To save the file with CR+LF at the end of every line, leave 'fileformat' at its current value (dos) and just write the file: :w - To save the file with LF-only: :setlocal ff=unix :w - To save the file with CR-only: :setlocal ff=mac :w After that, we may want to re-enable automatic fileformat detection: either set it back to its default: :set fileformats or set the value explicitly, for example: :set ffs=dos,unix,mac Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 238. You think faxes are old-fashioned.
Re: vim 7.1 and cr/lf interpretation
2007/5/15, Micah Cowan [EMAIL PROTECTED]: Please note that he had already given you this exact same answer already in his last message, including and especially the bit that \n is an end-of-line (line terminator), not a open-new-line (line separator). This is generally true for all operating systems, not just Unix (substituting \r or \r\n as necessary). This is the part that he shouted, since apparently he thought you'd notice it more this time around if he did. While I don't approve of shouting, I do understand his frustration: asking questions to learn about mysteries is definitely a good thing, and to be encouraged; but please do take the time to thoroughly read the answers that people spend time writing. I think my problem stems from the fact that I usually do not hold this true: 0x10 alone gives an *end* of line, not necessarily a *begin* of line. In the programming language I currently write, using the seperator string somewhere in the string I'm parsing gives a new entry. So a string containing only a line seperator char/pattern would have 2 entries, which in this case would mean 2 lines. As I see now, this is handled differently in vim. IIRC, even a java string tokenizer would work the same way, and by the original name, line feed in fact /does/ mean a new line on a serialized terminal. But that's arguing semantics when the core of the problem is known now. I apologize for having a different set of mind and not understanding the problem instantly. Thomas -- GPG-Key: tengelke.de/thomas_michael_engelke.asc
Re: vim 7.1 and cr/lf interpretation
2007/5/15, Micah Cowan [EMAIL PROTECTED]: Thomas Michael Engelke wrote: But that's arguing semantics when the core of the problem is known now. I apologize for having a different set of mind and not understanding the problem instantly. This is not a fair remark, considering I pointed out to you, privately, that he made the statement fairly clearly before his last post, which is why he said it all-caps/bold the second time around. It's not that you didn't understand the problem instantly: the problem was explained fairly clearly; it's that you made him repeat his answers, indicating that you hadn't read them. Damn. I apologize again, this time for replying your mail on the list. Now I know why there was no Reply to all, which I thought to be a glitch in GMail. And yes, you are right about the other thing, too. I did understand what he wrote but discarded it as not possible. I think I fell into that pattern when I read the first reply to my problem which was bollocks, obviously by someone who did not read what I wrote as he suggested something I already did and described. I promise to read the replies I will be given better from now on and not discard them so easily. Thomas -- GPG-Key: tengelke.de/thomas_michael_engelke.asc
Re: vim 7.1 and cr/lf interpretation
Thomas Michael Engelke wrote: In the programming language I currently write, using the seperator string somewhere in the string I'm parsing gives a new entry. So a string containing only a line seperator char/pattern would have 2 entries, which in this case would mean 2 lines. As I see now, this is handled differently in vim. Sorry to beat this really dead horse, but it's not Vim which handles this differently! End-of-line has always been a terminator, not a separator (as Tony explained earlier). I've had a closer look at the file you attached: - All lines end with CR LF, except for three lines. - Two lines end with CR only. - One line (the last) ends with LF only. John
Re: vim 7.1 and cr/lf interpretation
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. -- GPG-Key: tengelke.de/thomas_michael_engelke.asc
Re: vim 7.1 and cr/lf interpretation
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)? Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 236. You start saving URL's in your digital watch.
Re: vim 7.1 and cr/lf interpretation
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. The example file of vim (in my case, c:\Programme\vim\vim71a\vimrc_example.vim) loads fine and gets the fileformat dos, as expected. Thank you for your help, guys. Thomas -- GPG-Key: tengelke.de/thomas_michael_engelke.asc list02.p Description: Binary data
Re: vim 7.1 and cr/lf interpretation
Thomas Michael Engelke wrote: 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. It doesn't matter whether it's the very last line or not: if a single line (even at the end) ends in \n without \r, it is unix-format (note that if it the final line had not ended at all, it would have been dos). -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: vim 7.1 and cr/lf interpretation
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.pforce '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. Thank you for your help, guys. Thomas Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 237. You tattoo your email address on your forehead.
Re: vim 7.1 and cr/lf interpretation
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.pforce '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
Re: vim 7.1 and cr/lf interpretation
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.pforce '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
Re: vim 7.1 and cr/lf interpretation
Thomas Michael Engelke wrote: 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? It's not important here, but for the record, 0x10 means hex 10, which is decimal 16. That's not what you have. The correct story is: ^M = Ctrl-M = 13 = 0x0d = CR = carriage return ^J = Ctrl-J = 10 = 0x0a = LF = line feed A Unix format file has LF at the end of each line. A DOS format file has CR LF at the end of each line. Some stupid systems put nothing at the end of the last line. That is what we see in your sample file (your last line has no terminator). John
Re: vim 7.1 and cr/lf interpretation
* A.J.Mechelynck [2007.05.15 08:01]: 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? Or equivalently: :e list02.p GAC-VC-MESC add ^M at the end of the last line :w :e -- JR
Re: vim 7.1 and cr/lf interpretation
Thomas Michael Engelke wrote: But that's arguing semantics when the core of the problem is known now. I apologize for having a different set of mind and not understanding the problem instantly. This is not a fair remark, considering I pointed out to you, privately, that he made the statement fairly clearly before his last post, which is why he said it all-caps/bold the second time around. It's not that you didn't understand the problem instantly: the problem was explained fairly clearly; it's that you made him repeat his answers, indicating that you hadn't read them. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: vim 7.1 and cr/lf interpretation
Thomas Michael Engelke wrote: 2007/5/15, Micah Cowan [EMAIL PROTECTED]: Thomas Michael Engelke wrote: But that's arguing semantics when the core of the problem is known now. I apologize for having a different set of mind and not understanding the problem instantly. This is not a fair remark, considering I pointed out to you, privately, that he made the statement fairly clearly before his last post, which is why he said it all-caps/bold the second time around. It's not that you didn't understand the problem instantly: the problem was explained fairly clearly; it's that you made him repeat his answers, indicating that you hadn't read them. Damn. I apologize again, this time for replying your mail on the list. Now I know why there was no Reply to all, which I thought to be a glitch in GMail. Oh. Well, I actually hadn't noticed you'd done that, believe it or not. And I don't mind. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
RE: vim 7.1 and cr/lf interpretation
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. Uhhh, don't think it *should* automagically delete the ^Ms. I'm always running into that, and in addition to an almost reflexive alt-EIFD to go dos-mode, I *still* always have to ':s/^V^M' to get rid of 'em, and I'm using version 6.4, not even 7.x, so it's definitely been around for a while.
RE: vim 7.1 and cr/lf interpretation
Uhhh, don't think it *should* automagically delete the ^Ms. I'm always running into that, and in addition to an almost reflexive alt-EIFD to go dos-mode, I *still* always have to ':s/^V^M' to get rid of 'em, and I'm wak, wak, wak I sit corrected, so before anyone yells at me :D I should point out that most if not all times I encounter that is when pigging webpages, so it's likely a bastardised version of dos/unix snippets of text, headers, inline css, js code, etc., all thrown together by the server and vomited up into my browser. So there's likely to be at least 1 line w/o a '^M', hence my having to manually kill 'em off.
Re: vim 7.1 and cr/lf interpretation
Gene Kwiecinski wrote: 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. Uhhh, don't think it *should* automagically delete the ^Ms. I'm always running into that, and in addition to an almost reflexive alt-EIFD to go dos-mode, I *still* always have to ':s/^V^M' to get rid of 'em, and I'm using version 6.4, not even 7.x, so it's definitely been around for a while. If vim opens a file that truly has ^M^J at the end of every line, and fileformats contains dos, then it will automatically convert ^M^J to line ending. If you then set ff=unix, and save the file, it will write those endings out as just ^J. I've used this a few times (also in reverse, when I want to write an SMTP transcript for netcat, but forgot to save with CRLFs the first time :) ). -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: vim 7.1 and cr/lf interpretation
Hi Thomas, On 14/05/07, Thomas Michael Engelke [EMAIL PROTECTED] wrote: Hello! I just opened one of the files we develop, written by another programmer. I can see a ^M at the end of every line. I quickly check the mailing list archive and find out, that this mainly depends on the setting of fileformat. I check fileformat and find out that it's unix. Ah, the problem. I set it to dos. But nothing changes. How does vim determine what fileformat a file should have? I mean, a 0x13 before every linebreaking 0x10 should give at least some hint that this might not be a unix file. Maybe the file contains something that makes vim think this is a unix fileformat file? And why doesn't the interpretation change when I change fileformat? binary is set to nobinary, as I read in the help that this might cause problems. Try: :set fileformats? :help fileformats -- Wu Yongwei URL: http://wyw.dcweb.cn/
Re: vim 7.1 and cr/lf interpretation
:set fileformats? gives fileformats=dos,unix, so both formats are available, yet the detection and switching does not seem to work. 2007/5/14, Yongwei Wu [EMAIL PROTECTED]: Hi Thomas, On 14/05/07, Thomas Michael Engelke [EMAIL PROTECTED] wrote: Hello! I just opened one of the files we develop, written by another programmer. I can see a ^M at the end of every line. I quickly check the mailing list archive and find out, that this mainly depends on the setting of fileformat. I check fileformat and find out that it's unix. Ah, the problem. I set it to dos. But nothing changes. How does vim determine what fileformat a file should have? I mean, a 0x13 before every linebreaking 0x10 should give at least some hint that this might not be a unix file. Maybe the file contains something that makes vim think this is a unix fileformat file? And why doesn't the interpretation change when I change fileformat? binary is set to nobinary, as I read in the help that this might cause problems. Try: :set fileformats? :help fileformats -- Wu Yongwei URL: http://wyw.dcweb.cn/ -- GPG-Key: tengelke.de/thomas_michael_engelke.asc
Re: vim 7.1 and cr/lf interpretation
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? -- Regards, Andy EOM
