I notice (since moving my stuff to Thunderbird two weeks back) the
double spacing you keep squawking about, but I don't find it the big
nuisance you're talking about; ok, so we have to scroll a bit further.
It's not the scrolling that interferes
with readability, it's the interruption
to the flow of text by having excess
blank lines within a paragraph of text.
I am honestly convinced that this might even be a python problem. More
likely than not, gg is written in python, and this is the goofy line-end
character problem we have to deal with when we read lines in python.
Well, that's certainly a novel idea. Why you think that Google Groups is
written in Python? Does every post from GG end with "Powered By Python"?
Why do we suck in the new-line character as though it were part of the
line?
Because it is the only sensible way to handle it. If you don't, then
there is no way to distinguish between a file that ends with a newline
and one which doesn't.
This is asinine behavior. The new-line is a "file" delimiter
character and NOT intended to be part of the line.
Line endings are terminators: they end the line. Whether you consider the
terminator part of the line or not is a matter of opinion (is the cover
of a book part of the book?) but consider this:
If you say that the end of lines are *not* part of the line, then
that implies that some parts of the file are not inside any line
at all. And that would be just weird.
Thinking this through a bit
Yes, that helps
I've noticed that a blank line comes back
with a '\n' which differentiates it from file end which comes back
"without" the new-line. So, it appears that python is using the
new-line character (or lack there-of) to have meaning which the new=line
in a unix file was never suppose to carry.
I don't understand what meaning you are referring to here. Blank lines
comes back as a \n because a blank line *is* a \n with nothing before it.
Python isn't doing anything funny here, at least not on Linux. If you
open a text editor, and type:
spam ENTER ENTER ENTER ENTER eggs ENTER
(where ENTER means to hit the Enter key, not the letters E N T E R) and
then save, your editor will show the words "spam" and "eggs" separated by
three blank lines. If you open that file in a hex editor, you will see
something like:
73 70 61 6d 0a 0a 0a 0a 65 67 67 73 0a
Notice the four 0a bytes in a row? That gives you three blank lines.
Python is no adding any extra newlines or putting them where they aren't,
so I don't really understand what point you're trying to make here.
If python would just return EOF like every other language at file end,
and a test line without '\n' tacked to the end of it, this little snag
with gg would probably go away. What say you?
There is no evidence that Google Group's difficulty is because of Python.
More likely it is related to the translation between "rich text"
formatted using HTML, and plain text.
By the way, Python *does* return EOF at the end of the file. It is just
that EOF in Python is spelled "the empty string" instead of some other
special value. Both Ruby and Lua behave like Python, returning the empty
string on end of file:
steve@orac:~$ irb
irb(main):001:0> f = File.open('/tmp/io.txt')
=> #<File:/tmp/io.txt>
irb(main):002:0> f.read()
=> "hello"
irb(main):003:0> f.read()
=> ""
[steve@ando ~]$ lua
Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
fp = io.open('/tmp/io.txt', 'r')
print(fp:read("*all")) hello
Similarly, Rust returns None:
http://static.rust-lang.org/doc/0.9/std/io/trait.Reader.html#tymethod.read
And Java's java.io.BufferedReader is also similar, returning null.
