From: Felix W. <Fel...@gm...> - 2004-10-20 22:52:20
|
$ rst2pseudoxml.py --report=1 2> /dev/null .. class:: fancy 2. foo 3. bar <document source="<stdin>"> <system_message class="fancy" level="1" line="3" source="<stdin>" type="INFO"> <paragraph> Enumerated list start value not ordinal-1: "2" (ordinal 2) <enumerated_list enumtype="arabic" prefix="" start="2" suffix="."> <list_item> <paragraph> foo <list_item> <paragraph> bar The class isn't applied to the enumerated list, because the list issues an informational system message to which the class gets applied. (It also happens when omitting --report=1, except that the system message doesn't appear anymore. But the enumerated_list doesn't get the class attribute.) Solution: The class directive function has to skip nodes which the class is presumable not intended to be applied to, because they are *auto-generated*. Which are: system_directive, pending, Decorative, generated (and some table things like colspec or tgroup). I suggest adding a base class AutoGenerated and subclassing these four classes from AutoGenerated (colspec and tgroup too?). Then the class transform can simply skip AutoGenerated nodes. (There are other nodes where adding a class attribute doesn't make much sense, e.g. all Special nodes, but I think it's too difficult to determine all these cases and after all it's not Docutils' job to prevent the user from doing nonsensical things.) -- When replying to my email address, please ensure that the mail header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: David G. <go...@py...> - 2004-10-21 13:51:54
Attachments:
signature.asc
|
[Felix Wiemann] > $ rst2pseudoxml.py --report=1 2> /dev/null > .. class:: fancy > > 2. foo > 3. bar > <document source="<stdin>"> > <system_message class="fancy" level="1" line="3" source="<stdin>" type="INFO"> > <paragraph> > Enumerated list start value not ordinal-1: "2" (ordinal 2) > <enumerated_list enumtype="arabic" prefix="" start="2" suffix="."> > <list_item> > <paragraph> > foo > <list_item> > <paragraph> > bar > > The class isn't applied to the enumerated list, because the list > issues an informational system message to which the class gets > applied. Interesting :-) This is a perfect example of how test-driven development shines. When we discover an edge case like that, we should add a test case to catch it. > Solution: > > The class directive function has to skip nodes which the class is > presumable not intended to be applied to, because they are > *auto-generated*. Alternative solution: Change all system messages so they occur *after* the element to which they refer. It's simpler, easier to implement, and makes the Docutils output more consistent. > Which are: system_directive, pending, Decorative, generated (and > some table things like colspec or tgroup). Most of those aren't relevant; that situation ("class" attribute applied via "class" directive) either couldn't happen, or wouldn't make sense in the source text. -- David Goodger <http://python.net/~goodger> |
From: Felix W. <Fel...@gm...> - 2004-10-21 22:20:05
|
David Goodger wrote: > Felix Wiemann wrote: > >> The class directive function has to skip nodes which the class is >> presumable not intended to be applied to, because they are >> *auto-generated*. > > Alternative solution: > > Change all system messages so they occur *after* the element to which > they refer. > > It's simpler, easier to implement, Really, is it? It sounds like it requires quite some work, whereas skipping system_messages takes exactly one line, IIRC. (Actually, we don't even need an ``AutoGenerated`` base class.) -- When replying to my email address, please ensure that the mail header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: David G. <go...@py...> - 2004-10-22 01:53:06
Attachments:
signature.asc
|
[Felix Wiemann] >>> The class directive function has to skip nodes which the class is >>> presumable not intended to be applied to, because they are >>> *auto-generated*. [David Goodger] >> Alternative solution: >> >> Change all system messages so they occur *after* the element to >> which they refer. >> >> It's simpler, easier to implement, [Felix Wiemann] > Really, is it? IMO it's a simpler and better solution, and correct in this case. > It sounds like it requires quite some work, whereas > skipping system_messages takes exactly one line, IIRC. It took about 5 minutes to implement, and no new lines (just moved 2); maybe not easier than skipping nodes, but easy enough. If we find that the problem is more widespread than just enumerated lists, we may have to implement the skipping technique later. -- David Goodger <http://python.net/~goodger> |
From: Felix W. <Fel...@gm...> - 2004-10-23 12:50:07
|
David Goodger wrote: >>> Change all system messages so they occur *after* the element to >>> which they refer. > > IMO it's a simpler and better solution, and correct in this case. Nonetheless there may be more cases where a class gets applied to a system message. E.g., when there were no translations for "compound", using the compound directive caused an informational system message which appeared *before* the compound block. > If we find that the problem is more widespread than just enumerated > lists, we may have to implement the skipping technique later. I guess I could find more examples. Trying to fix them all takes too much time. So would you object to skipping system_messages when applying classes? Or are there any disadvantages of doing so? -- When replying to my email address, please ensure that the mail header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: David G. <go...@py...> - 2004-10-24 14:13:29
Attachments:
signature.asc
|
[Felix Wiemann] > Nonetheless there may be more cases where a class gets applied to a > system message. True. > So would you object to skipping system_messages when applying > classes? No. > Or are there any disadvantages of doing so? No. There was simply an *advantage* in moving the enumerated list start value system message to after the list: standardization. Making that change made the "class" problem disappear in that particular case. As I said before, >> If we find that the problem is more widespread than just enumerated >> lists, we may have to implement the skipping technique later. So please go ahead. But for the sake of standardization, other such cases (where a system message is inserted before the offending element) ought to be fixed if possible. -- David Goodger <http://python.net/~goodger> |
From: Felix W. <Fel...@gm...> - 2004-10-24 19:54:59
Attachments:
states.patch
|
David Goodger wrote: > Felix Wiemann wrote: > >> So would you object to skipping system_messages when applying >> classes? Or are there any disadvantages of doing so? > > No. There was simply an *advantage* in moving the enumerated list > start value system message to after the list: standardization. Sure. >>> If we find that the problem is more widespread than just enumerated >>> lists, we may have to implement the skipping technique later. > > So please go ahead. Done. > But for the sake of standardization, other such cases (where a system > message is inserted before the offending element) ought to be fixed if > possible. If I find one, I'll try to fix it. Two things I know about are left: * Some system messages are inserted before transitions (with and without my patch), in order to avoid invalid constructs. Example:: $ rst2pseudoxml.py ---------- A paragraph. <stdin>:1: (ERROR/3) Document or section may not begin with a transition. <document source="<stdin>"> <system_message level="3" line="1" source="<stdin>" type="ERROR"> <paragraph> Document or section may not begin with a transition. <transition> <paragraph> A paragraph. So the system_message is remedying what it's complaining about. Same for adjacent transitions and transitions at the end of a document. I think this is good and should not be changed. * The Body.directive method in parsers/rst/states.py inserts its own messages in front. I have a patch which changes this, but I'm not sure anymore if it's really a good idea to change it, because I find it somewhat more logical to have messages about looking up the directive name (and falling back to the canonical name) in front of the actual directive content, because that's the order in which it's actually happening (and in which the user would expect it to happen). Attached for completeness. If you think it should be applied nonetheless, feel free to check it in. |
From: David G. <go...@py...> - 2004-10-26 21:53:48
Attachments:
signature.asc
|
[Felix Wiemann] > Attached for completeness. If you think it should be applied > nonetheless, feel free to check it in. I agree; I think it's best not to make this change. -- David Goodger <http://python.net/~goodger> |