From: David G. <go...@py...> - 2003-05-13 02:29:43
|
Paul Tremblay wrote: > Yes, with this particular example my suggestion > results in duplicate code. But as you have conceded, > there is an example that needs inline nesting: > > [:comment: This text is taken from a story. It has > *italics* in it.] There are lots of such examples. That's not the issue; duplication is. It may be an unavoidable issue, since the parsing of nested `backquotes` is problematic, whereas [brackets] are much easier. As I said before, I don't have a better idea. > You have objected to this syntax because it is ugly. I > personally feel that some of the current markup: > > :emphasized-index:`The Great Gatsby` > > seems as verbose and hard or easy to read as my > suggestion. It is a subjective issue. There are simply more pixels in "[]" than in "``", therefore brackets are more obtrusive than backquotes. But that's minor. > My argument is, if you think the example > with empahiszed-index is suitable, why not my > suggestion with brackets? I don't follow. > You have made several criticisms that my suggestions > propose way too much. > > To be clear, I am suggsting this, and *only* this: > > reStructuredText include markup that allows inline > nesting. Good. It's best to deal with issues separately. > An example in reStructuredText would be: > > [:comment: This is a comment with *italics*] > > After running the above text through docutils, one > would see: > > <inline argument="comment">This is a comment with > <emphasis>italics</emphasis></inline> > > This means that only one element (inline) would have > to be added to the DTD. This element would have only > one attribute (argument). Issues: 1. I had already settled on "phrase" as the generic inline element, but perhaps "inline" is more direct and expressive. Opinions? 2. The existing "class" attribute is perfectly suitable to this task. There's no need for a new "argument" attribute. 3. As I pointed out before, the syntax as presented is confusing when compared to existing interpreted text inside brackets:: [:role: text] vs [:role:`text`] For this reason, and to follow the existing syntax pattern, the syntax should be:: :role:[text] 4. The syntax will not be used to enable arbitrary inline text. You cannot simply write:: Here's some :arbitrary:[inline text]. However, there is another proposal in the to-do list that would allow arbitrary inline text with a small amount of work by the author:: .. :arbitrary: class:: arbitrary Here's some :arbitrary:[inline text]. (See <http://docutils.sf.net/spec/notes.html#role-bindings>.) The explicit role assignment is necessary to prevent spelling errors in roles from going unnoticed ("Errors should never pass silently"). Without it, you could write ":abritarry:[inline text]" and end up with incorrect output. I will add it to the to-do list (just did). I'm in no hurry to implement it though; contributions are welcome. -- David Goodger http://starship.python.net/~goodger Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv |