Re: RFC: line endings and specs parser

[craig@jcb-sc.com]

>I'm coming into the discussion late, but any rewriting of the specs parser
>needs to fix the bug that trips up anybody who edits specs files by hand,
>namely requiring an extra blank line at the end file.  Also, it *MUST* handle
>lines of any length, since specs tend to get rather large.

Indeed.  Any design for something that appears to be a plaintext file
is best done such that an ordinary printout or dumb-tty display of the
file contains all the information a reader needs to determine the
semantic content of that file.

While that doesn't "solve" the problems surrounding very long lines by
itself (though simple tools to at least mark where they occur in a
printout might alleviate those), it does solve many other problems.

For example, this design guideline forbids distinguishing spaces from
tabs (assuming TAB always means tab to next eighth column, a la the
default behavior of `expand'), as well as distinguishing formfeeds
from blank lines.

It also forbids assigning semantic value to trailing spaces or blank lines.
And it pretty much mandates rejecting characters that aren't ordinary
ASCII printing characters, except for space, tab, and newline.

Ideally, it would also forbid assigning semantic value to the number of
contiguous blank lines; to leading blank lines; to any given number of leading
spaces (preceding the first printing character on a line) throughout the
file, perhaps to leading spaces at all; and, most strictly, to blank lines
entirely, since when they appear at the tops or bottoms of pages in printouts
or on displays, readers are unlikely to notice them.

While "perfect" conformance to these guidelines might be difficult or
impossible in some cases (because of collision with other usability
rules, e.g. users will clearly expect an embedded blank line to have
the significance it has vis-a-vis HTML and GNU texinfo, or similar,
formats), I suggest they be followed as scrupulously as possible.

Underlying all of the above is a simple principle: the burden of making
the meanings of plaintext files clear rests first and foremost on the
designers (writers) of the plaintext file format and of the plaintext files
themselves, *not* on the readers of those files.

So if anyone has to use "special" tools to cope with files you design,
make sure it's the authors of those files, not the readers.  Let the readers
use the ordinary tools existing systems already provide, and get clear,
understandable, and (most importantly) hard-to-misunderstand, results
from their decoding of such files.  Leave it up to the writers to use
whatever tools make authoring those files easier for them.

        tq vm, (burley)