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
