On 2011-11-01, Georg Brandl wrote: > On 10/29/2011 01:19 PM, Guenter Milde wrote:
... >> I am not sure "parsed-literal" content should be highlit as code. >> (But, of course a consistent behaviour is to be expected - i.e. either >> always or never highlight parsed-literal as code.) ... > you are of course right. If I had my way, I wouldn't highlight > anything in parsed-literal blocks. But the problem is that I found no > way to distinguish between normal literal blocks and parsed literal > blocks that have only "plain" (i.e. nothing that was parsed) text > inside... I remember the same problem when introducing code-highlighting via the "listings" package in the Docutils latex writer. The answer I got back then was: "There is no need for this distinction in the standard Docutils." I see two ways out here: a) Convince David that it makes sense to keep a tag of the "origin" of a literal_block doctree node. This could be either a class argument, or a "hidden attribute" as part of the "lossless rst parser" (pre-requisite to write back parsed documents as rst without loss of information). b) Accept, sanitize and document the behaviour of "parsed-literal" in Sphinx. Acutally, the documentation of the directive, http://docutils.sourceforge.net/docs/ref/rst/directives.html#parsed-literal-block says: Parsed literal blocks are useful for adding hyperlinks to code examples. Things to consider/document: * parsing order: [rst, code-highlight] vs. [code-highlight, rst] * How to represent and lay out e.g. a link that is a keyword, part of a string or comment? * Precedence for other inline markup vs. syntax highlight. For Docutils, I rather plan to go way a). The idea is to have a configurable "default-literal-block" directive (similar to "default-role") that maps the "::" syntax to, e.g., "literal", "parsed-literal", or "code". Günter -- You received this message because you are subscribed to the Google Groups "sphinx-dev" group. To post to this group, send email to sphinx-dev@googlegroups.com. To unsubscribe from this group, send email to sphinx-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sphinx-dev?hl=en.
