[The branch failed PQM due to a test in test_help that tests for the exact
output for get_help_text(plain=False)]
Vincent Ladeuil wrote:
> Doing HTML specific stuff is the doc is the wrong path.
>
> It won't work with texinfo.
>
> I don't know how to address it (yet), but please consider the above.
Well, what we're doing atm doesn't work with ReST at all.
Isn't the texinfo generated by sphinx too? If so I think this is still a
reasonable approach. Sphinx presumably knows how to turn 'describe' elements
into appropriate texinfo, and ditto for 'cssclass' (probably by ignoring them).
I think the 'cssclass' sphinx directive is actually just 'class' in plain ReST,
renamed because sphinx uses 'class' for documenting classes in code. (And I
think it may be renamed again to 'rst-class' in newer versions of sphinx?) So in
concept (if not spelling) it's fairly standard ReST, and I'd hope our texinfo
tool chain is able to cope with it without too much effort. If not we can
always write another optparse formatter that generates something
texinfo-friendly.
The only other cheap route I see is to give up and make the whole options
description be preformatted text, which will give equally dissatisfying results
in all outputs.
[The branch failed PQM due to a test in test_help that tests for the exact text(plain= False)]
output for get_help_
Vincent Ladeuil wrote:
> Doing HTML specific stuff is the doc is the wrong path.
>
> It won't work with texinfo.
>
> I don't know how to address it (yet), but please consider the above.
Well, what we're doing atm doesn't work with ReST at all.
Isn't the texinfo generated by sphinx too? If so I think this is still a
reasonable approach. Sphinx presumably knows how to turn 'describe' elements
into appropriate texinfo, and ditto for 'cssclass' (probably by ignoring them).
I think the 'cssclass' sphinx directive is actually just 'class' in plain ReST,
renamed because sphinx uses 'class' for documenting classes in code. (And I
think it may be renamed again to 'rst-class' in newer versions of sphinx?) So in
concept (if not spelling) it's fairly standard ReST, and I'd hope our texinfo
tool chain is able to cope with it without too much effort. If not we can
always write another optparse formatter that generates something
texinfo-friendly.
The only other cheap route I see is to give up and make the whole options
description be preformatted text, which will give equally dissatisfying results
in all outputs.