parsed-literal output

[andreacassioli]

Hi,

I have realized that the html output of parsed-literal depends on whether links are included or not. For instance:

.. parsed-literal::

   public int64  size()

will generate a single line with highlighted code

but

.. parsed-literal::

   public :ref:`fusion.flatexpr`  eval()

will yield a single line but with not highlight. Note that the link is valid and it will work nicely.

My point is: there should be a consistent behaviour. Of course would be nice to have always highlight (or an option to have it).

[andreacassioli]

Am I the only one experiencing this?

[andreacassioli]

Am I the only one experiencing this?

[pburdine]

I see the same thing.

For example:

.. parsed-literal::

    # cd *someDirectory*

In other places I used rst replacements like:

.. parsed-literal::

    # cd |directory|

In the first example, in the PDF output it shows up like a normal code block (black border, syntax highlighting, etc), but the second example doesn't

In the .tex file for the marked up parsed-literal it looks like:

\begin{Verbatim}[commandchars=\\\{\}]
...content here...
\end{Verbatim}

But in the parsed-literal with the substitution, it renders like:

\begin{alltt}
...content here...
\end{alltt}

The same thing happens in HTML output (though not as noticible). The marked up parsed-literal gets rendered with 'default-highlight' but the one with the replacement gets rendered with 'literal-block'.

[pburdine]

I see the same thing.

For example:

.. parsed-literal::

    # cd *someDirectory*

In other places I used rst replacements like:

.. parsed-literal::

    # cd |directory|

In the first example, in the PDF output it shows up like a normal code block (black border, syntax highlighting, etc), but the second example doesn't

In the .tex file for the marked up parsed-literal it looks like:

\begin{Verbatim}[commandchars=\\\{\}]
...content here...
\end{Verbatim}

But in the parsed-literal with the substitution, it renders like:

\begin{alltt}
...content here...
\end{alltt}

The same thing happens in HTML output (though not as noticible). The marked up parsed-literal gets rendered with 'default-highlight' but the one with the replacement gets rendered with 'literal-block'.

[pburdine]

It looks like this is related to the following code in the latex writer:

    def visit_literal_block(self, node):
        if self.in_footnote:
            raise UnsupportedError('%s:%s: literal blocks in footnotes are '
                                   'not supported by LaTeX' %
                                   (self.curfilestack[-1], node.line))
        if node.rawsource != node.astext():
            # most probably a parsed-literal block -- don't highlight
            self.body.append('\\begin{alltt}\n')
        else:
            ids = ''
            for id in self.pop_hyperlink_ids('code-block'):
                ids += self.hypertarget(id, anchor=False)
            if node['ids']:
                # suppress with anchor=False \phantomsection insertion
                ids += self.hypertarget(node['ids'][0], anchor=False)

The same if statement can be seen in the html writer:

    def visit_literal_block(self, node):
        if node.rawsource != node.astext():
            # most probably a parsed-literal block -- don't highlight
            return BaseTranslator.visit_literal_block(self, node)
        ...

I don't know enough about the code to determine what triggers:
if node.rawsource != node.astext()
Maybe someone who knows this better can comment on this.

[pburdine]

It looks like this is related to the following code in the latex writer:

    def visit_literal_block(self, node):
        if self.in_footnote:
            raise UnsupportedError('%s:%s: literal blocks in footnotes are '
                                   'not supported by LaTeX' %
                                   (self.curfilestack[-1], node.line))
        if node.rawsource != node.astext():
            # most probably a parsed-literal block -- don't highlight
            self.body.append('\\begin{alltt}\n')
        else:
            ids = ''
            for id in self.pop_hyperlink_ids('code-block'):
                ids += self.hypertarget(id, anchor=False)
            if node['ids']:
                # suppress with anchor=False \phantomsection insertion
                ids += self.hypertarget(node['ids'][0], anchor=False)

The same if statement can be seen in the html writer:

    def visit_literal_block(self, node):
        if node.rawsource != node.astext():
            # most probably a parsed-literal block -- don't highlight
            return BaseTranslator.visit_literal_block(self, node)
        ...

I don't know enough about the code to determine what triggers:
if node.rawsource != node.astext()
Maybe someone who knows this better can comment on this.

[tk0miya]

Indeed, it is strange for me that parsed-liateral block having substituion is not highlighted.

BTW, I prefer to highlight parsed-literal as far as possible.

[tk0miya]

Indeed, it is strange for me that parsed-liateral block having substituion is not highlighted.

BTW, I prefer to highlight parsed-literal as far as possible.

[andreacassioli]

Guys thank you for your effort.
I remember there was a discussion on the G group (I cannot find it anymore...) about this: If I am not wrong some of the Sphinx team said that it was hard to decide how to pygmentize the parsed text. It seems that now if there is some transformation in place the text is not highlighted. Is this correct?

That sounds very limiting....

[andreacassioli]

Guys thank you for your effort.
I remember there was a discussion on the G group (I cannot find it anymore...) about this: If I am not wrong some of the Sphinx team said that it was hard to decide how to pygmentize the parsed text. It seems that now if there is some transformation in place the text is not highlighted. Is this correct?

That sounds very limiting....

[pburdine]

In #2173 @lehmannro said:

(DefaultSubstitutions won't help, since these are used as Text nodes as well.)

This explains what I am seeing, not sure if this is the cause of what @andreacassioli sees.

[pburdine]

In #2173 @lehmannro said:

(DefaultSubstitutions won't help, since these are used as Text nodes as well.)

This explains what I am seeing, not sure if this is the cause of what @andreacassioli sees.

[paulanthonyjacobs]

I noticed some other inconsistencies using embedded replacements inside parsed-literal (but haven't delved into why). For e.g.
|token|-|token|
blah/|token|
expand ok, but
|token|.|token|
|token||token|
don't. Anyone know why or offer some work-arounds?

[paulanthonyjacobs]

I noticed some other inconsistencies using embedded replacements inside parsed-literal (but haven't delved into why). For e.g.
|token|-|token|
blah/|token|
expand ok, but
|token|.|token|
|token||token|
don't. Anyone know why or offer some work-arounds?

[jfbu]

@paulanthonyjacobs in my brief testing

   |token|\ .\ |token|
   |token|\ |token|

works for me. I actually trust the syntax coloring of my Emacs reST mode and 1, 3, 4 in

   |token|-|token| (1)
   blah/|token|      (2)
   |token|.|token|  (3)
   |token||token|   (4)

seem faulty for this point of view, although indeed only on the two latest have seemingly rendering problem (tested in html) and the last one actually raises an error

index.rst:15: ERROR: Undefined substitution referenced: "token||token".

hence I tried

  |token|\ -|token|
   blah/|token|
   expand ok, but
   |token|.\ |token|
   |token|\ |token|

because syntax coloring is fine and indeed it seems ok for make html.

[jfbu]

@paulanthonyjacobs in my brief testing

   |token|\ .\ |token|
   |token|\ |token|

works for me. I actually trust the syntax coloring of my Emacs reST mode and 1, 3, 4 in

   |token|-|token| (1)
   blah/|token|      (2)
   |token|.|token|  (3)
   |token||token|   (4)

seem faulty for this point of view, although indeed only on the two latest have seemingly rendering problem (tested in html) and the last one actually raises an error

index.rst:15: ERROR: Undefined substitution referenced: "token||token".

hence I tried

  |token|\ -|token|
   blah/|token|
   expand ok, but
   |token|.\ |token|
   |token|\ |token|

because syntax coloring is fine and indeed it seems ok for make html.