From: David G. <go...@py...> - 2003-05-01 23:40:46
|
[David Goodger] >> In other words, <keyword> etc. were just placeholders. Here's the >> example rewritten using the generic "phrase": >> >> <literal_block xml:space="preserve" class="python"> >> <phrase class="keyword">print</> <phrase >> class="string">'This is Python code.'</> >> <phrase class="keyword">for</> <phrase >> class="identifier">i</> <phrase class="keyword">in</> <phrase >> class="expression">range(10)</>: >> <phrase class="keyword">print</> <phrase >> class="expression">i</> >> </literal_block> >> >> It's more verbose but more easily extensible and more appropriate >> for the case at hand. [Stefan Merten] > That means: Exchange the new element tags for new values of the > ``class`` attribute. I can't see where this is *really* much > better... It's better because an unknown attribute can easily be ignored, whereas an unknown element will cause an exception (by design). A new "class" attribute value can be introduced without any need for Docutils code change. In the majority case all that's needed is a stylesheet change, which is much easier. > The underlying problem seems to be, that > > * you want to introduce some flexibility so people can add their own > stuff easily, > > * but every flexibility must be reflected by the code somehow and thus > flexibility is reduced because it is to tedious to implement. <phrase class="whatever"> represents flexibility that can be implemented once only, and ignored otherwise. > This is a contradiction which can't be really solved. Instead a good > work-around is needed. If you have a better suggestion, I'm all ears. >> My idea is that the "directive" (if that's what it should be) >> should be able to carry explicit instructions on how to render >> output on specific backends if the writer doesn't know this on its >> own. > > This I find an interesting idea. I find its complexity mildly horrifying. ;-) > However, perhaps I can suggest another approach somewhere halfway > between "the driver has to know" (i.e. it must be written in some > programming language) and "the directive has to know" (i.e. is fixed > and the directive has to deal with styles). > > How about introducing an (optional) mapping which maps the new > concepts to ones which are known by the driver. From <http://docutils.sf.net/spec/notes.html#interpreted-text> (which please read): * Add a directive establishing a mapping of interpreted text role aliases? A set of default roles (index, acronym, etc.) could exist, and the directive could assign abbreviations (i, a, etc.) or other alternatives. This would only allow limited extensibility though. Basically, synonyms and abbreviations for existing roles. > For instance, let's assume one introduces the custom concepts > "keyword", "variable" and "string". If you have a table mapping > > ======== =========== > Original Replacement > -------- ----------- > keyword ** > variable * > string `` > ======== =========== To pretty-print Python code though, something has to *assign* the keyword, variable, string etc. roles/classes. The Python code has to be parsed. -- David Goodger http://starship.python.net/~goodger Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv |