Excerpts from mail: 28-Jun-93 text/enriched comments John Gardiner
Myers(_at_)cmu(_dot_) (1061)
The document does not explictly state that formatting commands are
case-insensitive.
Good point. It should.
The fact that the "verbatim" turns off interpretation of embedded
formatting commands significantly increases the complexity of parsers.
While text/richtext has one special state (comment), text/enriched has
two, with the param state having to watch out for <verbatim>. I can
see of no benefit of the turn-off-interpretation directive, what was
the reason for it?
To make it easier to generate text/enriched data that includes things,
e.g. C programs with lots of "<" characters.
The statement about the UNIX newline convention assumption is
nonsensical--it is up to the C language's stdio library to deal with
newline conventions.
Are you claiming here that "\n" is converted to local conventions by all
the world's C compilers? That was not my understanding, but I'm
delighted to hear it if I'm wrong.
The sample parser botches the following stream:
<param><<</param>
Eek, I'll check it out.
What is the purpose of the line of code:
putc('\n', stdout);
at the end of the sample parser? It does not appear to correspond to
any part of the text/enriched specification.
No, it corresponds to a general desire to have the final line of output
show up on line-buffered terminals.
Excerpts from mail: 28-Jun-93 more text/enriched comments John Gardiner
Myers(_at_)cmu(_dot_) (771)
The specification states that including the literal string
"</verbatim>" inside of a verbatim environment may be done by breaking
up the verbatim segment into two verbatim segments. This is not
true--a reader is allowed to split the line as follows:
...slightly challenging to include the literal string "</
verbatim>" inside of a verbatim environment...
Well, I'll admit that I haven't read the spec in detail since I wrote
the last draft nearly half a year ago, but I can't find anything that
says you can split it there. This may be an ambiguity in the spec; did
you simply assume it was OK to break lines at tokens, even without white
space, or did I actually say that somewhere?
It is not possible with the supplied command set to turn off
filling, yet still retain interpretation of formatting commands.
In short, I think verbatim should just turn off filling and
justification. Readers can then treat it as any other command.
Composers can easily deal with having to double < and CRLF's.
Well, I've gone back and forth on this quite a few times. I guess I
would certainly concede that if verbatim's going to stay as it is, there
should also be a "nofill" environment. My gut feeling is that the
current version is a lot easier on composing software, though. Other
opinions? -- NB