rhys(_at_)cs(_dot_)uq(_dot_)oz(_dot_)au writes:
Keep in mind that the parser is meant to be the "minimum amount of effort
required". Any "real" text/enriched system is much bigger, and the code
to format the output, perform justification, font changes, etc totally
dwarfs the front-end parser for recognising verbatim in the input stream.
The complexity of the simple parser is a good indication of what the
complexity of a full-blown parser is going to be. text/enriched has
two entirely different lexical modes and some ugly interactions
between param and verbatim, which are going to be real pains to deal
with.
The sample sample text/richtext parser has a simple, straightforward
control flow. The control flow of the sample text/enriched parser is
so convoluted that Nataniel botched it and apparently still doesn't
know why.
My point is that all this complexity doesn't buy you anything. What's
so bad about:
<indent><nofill>
int fact (int n)
{
if (n <<= 0)
return 1;
else
return (n * fact (n - 1));
}
</nofill></indent>
You don't save anything in the composer--quoting "<" and dealing with
the newline convention is certainly simpler than looking for any
substring that matches "</verbatim>" in a case-insensitive manner.
Nathaniel Borenstein <nsb(_at_)thumper(_dot_)bellcore(_dot_)com> writes:
3. I think we can handle the close-verbatim/open-verbatim problem with
some advice to implementors, which I'll go ahead and add; basically, it
never had occurred to me that someone would split a line there, and I'll
just add a recommendation against it. Sound OK?
The problem with this is that it is a special case layered on top of a
special case. Whatever happened to simple, general Internet standards?
I suppose anyone objecting to the complexity of comments during the
development of RFC 822 would have gotten a similar reaction.
--
_.John G. Myers Internet: jgm+(_at_)CMU(_dot_)EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up