[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: text/enriched comments
rhys@cs.uq.oz.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@thumper.bellcore.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+@CMU.EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up