[Top] [All Lists]

Re: text/enriched comments

1993-06-29 06:46:34
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

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:


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

<Prev in Thread] Current Thread [Next in Thread>