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