gardner said:
>   I know your bent is to prefer a
>   non-standard lightweight markup

by "lightweight", gardner, i hope you don't mean to imply
"deficient in capability", so i'd hope no one will infer that...      :+)

as for the term "non-standard", i suppose some people
have a knee-jerk positive reaction to a "standard", but
i'm here with the guy who said that standards are nice
"because there are so many to choose from..."

someday someone will make z.m.l. a "standard",
i suppose.  in the meantime, it's just a nifty trick.


>   I know your bent is to prefer a
>   non-standard lightweight markup
>   for texts, but for those of us
>   considering adding full-on markup,
>   what's the simplest way to handle this?

well, gee, my first recommendation
would be to _keep_on_considering_
the adding of full-on markup until
you figure out why it is a bad idea...           :+)

but that's probably not what you
thought your question was asking...


>   The idea of grovelling through the text
>   in vi and adding tags all over doesn't appeal.

it certainly doesn't appeal to me either.
fortunately, that shouldn't be necessary.

the answer:  write a program to apply tags.

if the underlying text is consistent enough,
it is relatively simply to write routines that
can recognize its structure and then tag it.

indeed, that's the whole foundation of z.m.l.

and it is precisely because the p.g. e-texts
are _not_ consistent enough, at their base,
to allow this auto-tagging that i've been a
constant critic here of e-text inconsistency,
even while i love the p.g. library as a whole...

but you should take heart when i tell you that
-- even despite their danged inconsistency --
it _is_ possible to write routines that decode it,
and _could_ tag p.g. e-texts with heavy markup.

of course, once you understand on a deep level
that it's fully possible for a computer program to
ascertain the structure of a text well enough that
it can apply markup to permit good presentation
by another computer program (e.g., a browser),
you will also come to understand on a deep level
that there is absolutely no need for the markup,
since the structure-ascertaining routines can be
included in the browser itself, and thereby avoid
the markup middleman.  ergo, _zen_markup_...

future generations will laugh at us for believing
that markup was even necessary in the first place,
let alone that we'd codify it into "a standard", and
waste our time, money, and energy to "apply" it...

-bowerbird