sphinx-doc / sphinx

The Sphinx documentation generator
https://www.sphinx-doc.org/
Other
6.5k stars 2.11k forks source link

parsed-literal output #2167

Open andreacassioli opened 8 years ago

andreacassioli commented 8 years ago

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 commented 8 years ago

Am I the only one experiencing this?

pburdine commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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.

ghost commented 7 years ago

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 commented 7 years ago

@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.

nedbat commented 4 years ago

This issue is old, and one of lots of open issues, but I'll add my voice: it doesn't make sense that the output styling depends on whether substitutions occurred in the text.

tk0miya commented 4 years ago

I marked this as "help wanted". I feel this is tough task to implement. So we're welcome to your contribution. Thanks,