Re: text/enriched

< While richtext has it's problems, it's not clear to me why it can't be
< fixed (by clarifying the ambiguity, dropping the unnecessary
< functionality, etc.) but instead has to be thrown out and redone from
< scratch.
<
< While I believe the miniscule complexity of <center> et al is adequately
< compensated for by its benefit, the ambiguity of <center> in richtext
< could have been dealt with in other ways.  <center> et al could have been
< declared illegal in the middle of a line or their semantics in the middle
< of a line could have been clarified. <Center>ing a single word could mean
< the much same thing as <indent>ing a single word.
<
< As I've mentioned before on this list, text/enriched is significantly more
< complex than text/richtext.  This is primarily caused by the <verbatim>
< command, which establishes a completely different lexical mode.  The
< effect of <verbatim> is quite noticeable in the minimal parser and it will
< similarly affect real parsers.  There is no practical benefit to
< compensate for the additional complexity.

It took me about 1 day to convert the metamail richtext program to handle
text/enriched as well as text/richtext. (Yes, Nat has the changes.) The code
to handle <verbatim> is tiny (~20 lines of code). Even then, there are
probably other ways of coding it which would be shorter. The so-called
complexity of <verbatim> is a red herring.

					Tony Hansen
			    hansen <at> pegasus.att.com, tony <at> attmail.com
				att!pegasus!hansen, attmail!tony