Hi!
Larry is right in that there is (already, also under Unix)
other ways of separating lines: namely form feed, but also vertical
tab. I must admit that I have never used vertical tab, and very
rarely form feed... Anyway C9x says: "\v (vertical tab) Moves the
active position to the initial position of the next vertical tab
position." And there is a similar statement about form feed. I
assume that is not too far off from what other standards might say.
So, the interoperable line (or 'stronger') separators in
"plain text" are:
\X{2028}|\X{2029}|\r\n|\n|\r|\f|\v|\X{85}
(I'm probably mixing Perl and C (and flex) syntax here.) Some
of them are "stronger" in some senses than line separation,
but for the purposes of counting logical lines, and deciding
logical line begin and logical line end, there should be no
difference. A single logical line may be *dynamically* wrapped
into several displayed lines, but that is a different matter.
Note that there are some "legacy" encodings which do not
have any or all of \f|\v|\X{85}.
(I still think the idea of having two different kinds
of "plain text" is a bad idea. I haven't heard anyone else
entertain it either.)
Kind regards
/Kent K
Larry Wall wrote:
...
The only problem I see offhand with allowing both styles in the same
file is that different tools might count lines differently. If Perl
says there's a syntax error at line 582, it might mean it has seen 581
instances of /\012 | \015\012 | \015 | \X{2028} | \X{2029}/x
before the
error. (For folks listening in, that works out to Unix
newline, Windows
newline, Mac newline (!), Unicode line separator and Unicode paragraph
separator.) If your "normal plain text" editor then counts only \012
(Unix newline), the programmer isn't going to be able to find
the error.
On the other hand, maybe Perl would just count newlines, and your
editor counts it the other way. More likely, some editors count one
way, and other editors count another. Maybe they count LS but not PS,
just as Perl currently counts \n but not \f as a line transition.
There are many possiblities.
All I'm really arguing here is that it would be good to establish a
line counting convention. But if that convention pretends there won't
be files mixing the two line delimitation styles, that will have other
ramifications, including possibly an adverse impact on portability.
Counting line numbers right is already pretty complicated
when you have
NFS mounts from foreign systems. Adding in Unicode will only make
things more complicated. There will be some pressure to use Unicode
LS/PS in portable code, and I'm not sure you want to spend the rest of
your life resisting that pressure. A lot of the "fixes" in Perl are
only there because we got tired of people asking the same questions
over and over.
I think assuming that files will only be one style or the other will
put us into that sort of a situation, and it would be nice to head it
off early, for some definition of early. Just telling people by fiat
that they can't mix the two styles is not likely to work in
the absence
of universal education. Unfortunately, the education of the
illegitimi
tends to result in carborundum.
Larry
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
