headers
Martin Geisler | 1 Mar 2008 11:28
Picon
Picon
Favicon
Gravatar

Re: Include python code block into rst?

"G. Milde" <milde <at> users.berlios.de> writes:

>> * Pass it to Pygments for HTML output. Pygments seems to handle most
>> languages and does so with a good parser architecture.
>
> From a practical point of view, yes. However, the clean solution
> (which hopefully will be in standard docutils some day) is to use
> pygments (if available) to parse the content of a code block and
> create a "rich" doctree node which is then is processed by the
> writers...

I can see how it might be easier to get uniform output in different
formats if Docutils parses the code itself using Pygments, but on the
other hand, then I would actually expect the LaTeX output to look
different from the HTML output (e.g., only highlight with bold/italic
instead of the full multi-color "fruit-salad" treatment by Pygments.)

So I am very happy if the code is passed verbatim to the writer, which
can then decide to include it as a literal block (I assume every writer
knows about those) or highlight it in an appropriate way.

> [...]
>
> There is, however an experimental latex writer with listings support
> available:
> http://docutils.sourceforge.net/sandbox/latex-variants/latex2e_listings/

Good to know, thanks for the link!

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
grubert | 1 Mar 2008 14:48
Picon
Gravatar

Re: \usepackage?

On Fri, 29 Feb 2008, Alan G Isaac wrote:

>> On Fri, 29 Feb 2008, Alan G Isaac wrote:
>>> But do you like the ``--literal-block-env`` idea?
>
> On Fri, 29 Feb 2008, (CET) grubert <at> users.sourceforge.net wrote:
>> from what i can remember i could not see the solution.
>> i will try to look it up again (else nag me , please)
>
> Sure, I will.
> Just to recall the issue and the idea.
>
> Issue: literal blocks are often code,
> and when they are, the best environment
> (now at least) is lstlisting.
>
> Currently there is an option ::
>
>        --use-verbatim-when-possible
>
> that switches from the mbox to the verbatim environment for
> literal blocks.  The request is to allow specifying the
> environment for literal blocks.  That is, replace the above
> option with ::
>
>        --literal-block-env=verbatim
>
> and allow
>
>        --literal-block-env=lstlisting
(Continue reading)

Permalink | Reply | 12 comments |
headers
Alan G Isaac | 1 Mar 2008 17:00
Picon
Favicon

Re: \usepackage?

On Sat, 1 Mar 2008, (CET) grubert <at> users.sourceforge.net wrote:
> currently verbatim would be used otherwise mbox (i did not look at the 
> code, so this is from faint memory) now when this is replaced 
> where is the "when-possible"

> keep ::

>    --use-verbatim-when-possible

> add ::

>    --verbatim-env=

> to specify the environment that is used when it is possible . 

> would this work ? 

Yes, but it seems redundant to me.
Why cannot

        --verbatim-env=mbox

be an option (possibly default), and if set to anything
else, it would mean to use that something else (verbatim,
or lstlisting) when possible.  The docs could explain this.

But whatever: I care about the functionality much more than
the interface.

Thanks!
(Continue reading)

Permalink | Reply | 7 comments |
headers
grubert | 1 Mar 2008 20:58
Picon
Gravatar

Re: \usepackage?

On Sat, 1 Mar 2008, Alan G Isaac wrote:

> On Sat, 1 Mar 2008, (CET) grubert <at> users.sourceforge.net wrote:
>> currently verbatim would be used otherwise mbox (i did not look at the
>> code, so this is from faint memory) now when this is replaced
>> where is the "when-possible"
>
>> keep ::
>
>>    --use-verbatim-when-possible
>
>> add ::
>
>>    --verbatim-env=
>
>> to specify the environment that is used when it is possible .
>
>> would this work ?
>
>
> Yes, but it seems redundant to me.
> Why cannot
>
>        --verbatim-env=mbox
>
> be an option (possibly default), and if set to anything
> else, it would mean to use that something else (verbatim,
> or lstlisting) when possible.  The docs could explain this.

yes this could possibly work.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Alan G Isaac | 1 Mar 2008 22:11
Picon
Favicon

Re: \usepackage?

On Sat, 1 Mar 2008, (CET) grubert <at> users.sourceforge.net apparently wrote:
> the question is if we should could drop the when possible.  
> AFAIR the problem is that the writer can not distinguish 
> between literal and parsed-literal. 

I meant only that that point could be made in the 
documentation of the  ``--verbatim-env`` option,
since it is *always* a constraint (if i understand).

> inside verbatim bold does not work inside lstlisting it 
> does not make much sense , am i correct ? 

Yes.  Verbatim is verbatim.
AFAIK, the same restricting applied to listings.

Cheers,
Alan

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Permalink | Reply | 4 comments |
headers
Zajcev Evgeny | 2 Mar 2008 01:44
X-Face
Picon

odtwriter problem with utf-8 in literal_block


Hello.  I've got problem converting reST file into ODT using rst2odt.py.

If i put some russian text in UTF-8 into literal block i next error:

  [1][T03:35][~/devel/py/rest]$ rst2odt.py --output-encoding-error-handler=replace test.rest test.odt
  UnicodeEncodeError: 'ascii' codec can't encode characters in position 118-123: ordinal not in range(128)

  The specified output encoding (utf-8) cannot
  handle all of the output.
  Try setting "--output-encoding-error-handler" to

  * "xmlcharrefreplace" (for HTML & XML output);
    the output will contain "&#1055;&#1088;&#1080;&#1074;&#1077;&#1090;" and should be usable.
  * "backslashreplace" (for other output formats, Python 2.3+);
    look for "\u041f\u0440\u0438\u0432\u0435\u0442" in the output.
  * "replace"; look for "?" in the output.

  "--output-encoding-error-handler" is currently set to "replace".

  Exiting due to error.  Use "--traceback" to diagnose.
  If the advice above doesn't eliminate the error,
  please report it to <docutils-users <at> lists.sf.net>.
  Include "--traceback" output, Docutils version (0.4),
  Python version (2.5.1), your OS type & version, and the
  command line used.

I tried all those (proposed) values for
--output-encoding-error-handler, but got the same error.
(Continue reading)

Permalink | Reply | 0 comments |
headers
grubert | 2 Mar 2008 03:44
Picon
Gravatar

Re: \usepackage?

On Sat, 1 Mar 2008, Alan G Isaac wrote:

> On Sat, 1 Mar 2008, (CET) grubert <at> users.sourceforge.net apparently wrote:
>> the question is if we should could drop the when possible.
>> AFAIR the problem is that the writer can not distinguish
>> between literal and parsed-literal.
>
> I meant only that that point could be made in the
> documentation of the  ``--verbatim-env`` option,
> since it is *always* a constraint (if i understand).
>
>> inside verbatim bold does not work inside lstlisting it
>> does not make much sense , am i correct ?
>
> Yes.  Verbatim is verbatim.
> AFAIK, the same restricting applied to listings.

now ``--literal-block-env``

also with options

could you try it out

--

-- 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
(Continue reading)

Permalink | Reply | 3 comments |
headers
G. Milde | 3 Mar 2008 16:13
Picon

Re: \usepackage?

On  1.03.08, grubert <at> users.sourceforge.net wrote:
> On Fri, 29 Feb 2008, Alan G Isaac wrote:

> >  As an extra treat, it would be nice to be able to
> > say ::
> >
> >        --literal-block-env=lstlisting[language=Python]
> >
> > to get literal blocks inside of ::
> >
> >        \begin{lstlisting}{language=Python]
> >        \end{lstlisting}

I don't think this is necessary. You can set a default language for listings
in a stylesheet (and you will use a stylesheet anyway to format the listings
output, don't you?).

However, it would be nice if the class argument "Python" would translate to

> >        \begin{lstlisting}{language=Python]

and similar for all languages recognized by listings
so that you can write

.. class:: Python

::

   print "hello world"
(Continue reading)

Permalink | Reply | 3 comments |
headers
grubert | 3 Mar 2008 16:25
Picon
Gravatar

Re: \usepackage?

On Mon, 3 Mar 2008, G. Milde wrote:

> On  1.03.08, grubert <at> users.sourceforge.net wrote:
>> On Fri, 29 Feb 2008, Alan G Isaac wrote:
>
>>>  As an extra treat, it would be nice to be able to
>>> say ::
>>>
>>>        --literal-block-env=lstlisting[language=Python]
>>>
>>> to get literal blocks inside of ::
>>>
>>>        \begin{lstlisting}{language=Python]
>>>        \end{lstlisting}
>
> I don't think this is necessary. You can set a default language for listings
> in a stylesheet (and you will use a stylesheet anyway to format the listings
> output, don't you?).
>
> However, it would be nice if the class argument "Python" would translate to
>
>>>        \begin{lstlisting}{language=Python]
>
> and similar for all languages recognized by listings
> so that you can write

I can see the worms all over (who did open this can ?-)

currently the latex-writer does not know anything about
lstlisting this is just another text instead of verbatim
(Continue reading)

Permalink | Reply | 1 comment |
headers
G. Milde | 3 Mar 2008 16:37
Picon

Re: \usepackage?

On  1.03.08, grubert <at> users.sourceforge.net wrote:
> On Sat, 1 Mar 2008, Alan G Isaac wrote:
> > On Sat, 1 Mar 2008, (CET) grubert <at> users.sourceforge.net wrote:

> > Why cannot
> >        --verbatim-env=mbox
> > be an option (possibly default), and if set to anything
> > else, it would mean to use that something else (verbatim,
> > or lstlisting) when possible.  The docs could explain this.

> the question is if we should could drop the when possible.

I hope we can agree to drop it from the option name (to reduce typing)
and use ``--verbatim-env`` instead of ``--verbatim-env-if-possible``.

> AFAIR the problem is that the writer can not distinguish between
> literal and parsed-literal.

AFAIR, the problem is

1. The docutils documenttree definition, allows a "rich" literate block.

2. The implementation must consider that "verbatim"-like environments
   clash with literal-blocks containing inline elements and 

   a) use a fall-back non-verbatim environment (e.g. `alltt`), or

   b) 'flatten' the literal-block doctree node

   in this case.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane