A couple of typos crept into the newly added document
about the seq_file interface. This patch corrects those
typos and simultaneously deletes a few superfluous blanks.

Signed-off-by: Dmitri Vorobiev <dmitri.vorobiev@gmail.com>
---
 Documentation/filesystems/seq_file.txt |   18 +++++++++---------
 1 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/Documentation/filesystems/seq_file.txt b/Documentation/filesystems/seq_file.txt
index cc6cdb9..2b6aba6 100644
--- a/Documentation/filesystems/seq_file.txt
+++ b/Documentation/filesystems/seq_file.txt
@@ -6,7 +6,7 @@ The seq_file interface
 
 
 There are numerous ways for a device driver (or other kernel component) to
-provide information to the user or system administrator.  One useful
+provide information to the user or system administrator. One useful
 technique is the creation of virtual files, in debugfs, /proc or elsewhere.
 Virtual files can provide human-readable output that is easy to get at
 without any special utility programs; they can also make life easier for
@@ -16,7 +16,7 @@ grown over the years.
 Creating those files correctly has always been a bit of a challenge,
 however. It is not that hard to make a virtual file which returns a
 string. But life gets trickier if the output is long - anything greater
-than an application is likely to read in a single operation.  Handling
+than an application is likely to read in a single operation. Handling
 multiple reads (and seeks) requires careful attention to the reader's
 position within the virtual file - that position is, likely as not, in the
 middle of a line of output. The kernel has traditionally had a number of
@@ -50,7 +50,7 @@ following:
 
 Then concatenate the output files out1 and out2 and get the right
 result. Yes, it is a thoroughly useless module, but the point is to show
-how the mechanism works without getting lost in other details.  (Those
+how the mechanism works without getting lost in other details. (Those
 wanting to see the full source ...
[ message continues ]

The "2 spaces after a period at the end of a sentence" was done
on purpose, I feel sure.  It's not a mistake.

The other typo corrections & elimination of trailing whitespace

---
~Randy
--

[ message continues ]

OK, I'll redo the changes.

Actually, I was doubting whether the "2 spaces" thing was
intentional or not. The overwhelming majority of the sentences in
this document use only one space after a period, however, and this
made me decide that the "2 spaces" thing had not been deliberate
but just a typo.

Are there any rules about using spaces after a period at the end
of a sentence?

Thanks,
Dmitri
--

[ message continues ]

See Knuth (TeXbook) for the story on that...
--

[ message continues ]

Thanks, Al.

Dmitri
--

[ message continues ]

I googled that but I don't see the history there.

AFAIK, 2 spaces at the end of sentences is a typewriter-ism, for easier
visual separation of sentences.
Probably (just guessing here) has to do with monospace fonts vs.
(not having) proportional ones there (usually).

---
~Randy
[Yes, I learned to type on a manual typewriter.]
--

[ message continues ]

The following Wikipedia article is the most complete and exhaustive source
I could find while researching the double spacing rules:

http://en.wikipedia.org/wiki/French_spacing

To put it briefly, there are three main conventions about inter-sentence
spacing:

o English spacing a.k.a. American typewriter spacing: two spaces after full stop;

o French spacing, i.e. one space;

o traditional typography, which uses proportional fonts and is therefore not
very much interesting here.

Offhand, it seems that the double spacing convention is being currently used
in a more or less consistent manner throughout Linux docs. It also seems to
me that this can be made a requirement and documented somewhere.

Thanks,

--

[ message continues ]

Double spacing is my preference, and I appreciate your sending a new
patch which doesn't take that out.

But *please* let's not try to make "requirements" along those lines.  If
somebody's going to go to the trouble to write some documentation, I
don't think we really want people bouncing it back to them with 100
"single space after period" errors from checkpatch.pl...

Thanks,

jon
--

[ message continues ]

OK, clear enough. Thanks.


--

[ message continues ]

Big Ack on that.

-- 
~Randy
--

[ message continues ]

French spacing has even weirder inter-word/operator spacing,

I object. No matter how many (unescaped) spaces you cram in after a sentence
stop, HTML engines will happily squash it when displayed [in text/html
mode of course], like <p>do as much english spacing.       as you want,
it's still correctly fixed by the display :-)</p>.

--

[ message continues ]

In a sense...  Basically, the real rules are
	* inter-sentence space is naturally wider than inter-word one
	* if you need to stretch line, inter-sentence spaces get
proportionally more than inter-word ones.
	* if you need to shrink line, they get proportionally less.
	* there are fun extra considerations for quoted sentences and
friends.

For monospace almost nothing of that can be applied, but the first part
(wider inter-sentence spaces) is more painful to ignore.  The ratio for
normally typeset text is going to be less than 2, but it's easier on
eyes to approximate it with 2 than with 1...
--

[ message continues ]

The 2-spaces ones were probably reformatted using 'fmt'. If fmt joins
a line ending in a period, it will use 2 spaces. It does not change the
spacing in non-joined lines, despite what the manpage says.

Nick.
--

[