Re: Idea: Connecting paragraphs in reStructuredText

Red Wraith <red.wraith <at> gmx.de> schrieb:
> David Goodger wrote:

> It would be very nice if reStructuredText featured an extra standard 
> element for empty lines.

Do you really need both, standard transitions and "empty lines"?
(Are these mixed in any of the examples?)

> Or maybe different *standard* types of transitions (simple empty line, 
> horizontal dash, etc.), so one can use empty lines and everybody which 
> converts the RST source file sees empty lines by default and not 
> horizontal dashs for example. 

The style of a transition is a layout feature, so it is not coded in the rst
source but the style sheet.

As you cannot specify the style sheet in the source, someone translating it
with the default settings will see the default transition.

You can, however, configure docutils in a way that all transitions will
by default be styled as vertical space (do not call it empty lines -- the
browser is not a typewriter) with a custom style-sheet specified in
~/.docutils.

> At the moment, if you use "-----------" one can't specify a type. 

You can::

  Hallo Welt

Getting error from docutils failure

Hi folks,

I'm trying to catch the docutils error within Leo (a python outlining 
editor), and I can't seem to understand how to capture the error.  
Here's what I'm trying:

               try:
                   res = pub.publish(argv=['--stylesheet=%s' % path])
               except Exception, inst:
                   print type(inst)     # the exception instance
                   print inst.args      # arguments stored in .args
                   print inst           # __str__ allows args to printed 
directly
                   raise inst

Anybody know of a way to do this?  If I run docutils from the command 
line, I get:

docutils.utils.SystemMessage: <string>:376: (SEVERE/4) Title level 
inconsistent:

I'd love a way to capture the contents of that error message and display 
it somehow.

TIA
Mike

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes

Re: Getting error from docutils failure

On Fri, Nov 7, 2008 at 11:18, Mike Crowe <drmikecrowe <at> gmail.com> wrote:
> I'm trying to catch the docutils error within Leo (a python outlining
> editor), and I can't seem to understand how to capture the error.
> Here's what I'm trying:
>
>               try:
>                   res = pub.publish(argv=['--stylesheet=%s' % path])
>               except Exception, inst:
>                   print type(inst)     # the exception instance
>                   print inst.args      # arguments stored in .args
>                   print inst           # __str__ allows args to printed
> directly
>                   raise inst
>
> Anybody know of a way to do this?

Set the "traceback" setting on
(http://docutils.sourceforge.net/docs/user/config.html#traceback).
Also potentially useful are the "report_level" and "halt_level"
settings, to control what gets reported and what triggers an
exception.

BTW, I recommend using a publisher convenience function; see
http://docutils.sourceforge.net/docs/api/publisher.html
You wouldn't have had this problem with them.

Also, it's much better to pass in settings with
settings_overrides={'stylesheet': path} (not argv=['--stylesheet=%s' %
path]). See http://docutils.sourceforge.net/docs/api/runtime-settings.html

LaTeX stylesheet survey

Dear Docutils users,

I have `plans for the latex2e writer development`__, but before changing too
much I'd like to ask users about current use, preferences and wishes.

__ http://docutils.sourceforge.net/sandbox/latex-variants/README.html

(Sourceforge does no longer list directories without index file, see the
content with SVN view under: 
http://svn.berlios.de/viewcvs/docutils/trunk/sandbox/latex-variants/)

Questionaire
============

1. Do you use custom stylesheets with Docutils-generated LaTeX files?

2. Would you prefer the stylesheet to be a 

   LaTeX package: "*.sty"
      Input with \usepackage{}.

      +2 Existing LaTeX packages can be used as --stylesheet argument.

      +1 Command names can contain the char  <at>  (no \makeatletter needed).

      -1 Warnings, if home-made stylesheets do not use the proper LaTeX
      	package commands.

      Expects the file extension ".sty":

Re: LaTeX stylesheet survey

Guenter Milde <milde <at> users.berlios.de> writes:

> Dear Docutils users,
>
> I have `plans for the latex2e writer development`__, but before changing too
> much I'd like to ask users about current use, preferences and wishes.
>
> __ http://docutils.sourceforge.net/sandbox/latex-variants/README.html
>
> (Sourceforge does no longer list directories without index file, see the
> content with SVN view under: 
> http://svn.berlios.de/viewcvs/docutils/trunk/sandbox/latex-variants/)
>
> Questionaire
> ============
>
> 1. Do you use custom stylesheets with Docutils-generated LaTeX files?

yes

> 
>  
> 2. Would you prefer the stylesheet to be a 
>  
>    LaTeX package: "*.sty"
>       Input with \usepackage{}.
>       
>

+2 Existing LaTeX packages can be used as --stylesheet argument.

Option list with multiple option arguments

I've encountered a limitation of option lists: options may only have one
option argument for the syntax requirements to be met. Something like this
doesn't work:

-r FROM TO, --replace=FROM TO
        replace "FROM" with "TO"

I've seen a question on this list posted in September, which was about a
similar issue: an option name that contains colons. The answer to that
question was to use a simple name for that option and explain its syntax,
which in the case of a path arguments sounds resonable.

However, in my case, I find it misleading to use one option name for what
is actually two option arguments, even if explained. Would it be possible
to extend the syntax to allow for multiple option arguments, each of which
might stay as simple as it is now?

I'm not sure about getopt, whose supported syntax ReST's option lists are
documented to implement, but multiple-argument options are well possible
with Python's optparse standard module, so it's at least nothing wildly
uncommon.

--

-- 
Thomas

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Option list with multiple option arguments

On Tue, Nov 11, 2008 at 12:05, Thomas Lotze <thomas <at> thomas-lotze.de> wrote:
> However, in my case, I find it misleading to use one option name for what
> is actually two option arguments, even if explained. Would it be possible
> to extend the syntax to allow for multiple option arguments, each of which
> might stay as simple as it is now?

It's possible. Patches are welcome, the more complete the better (e.g.
tests & docs).

The current implementation is just fine for me, and I have no
intention of implementing it.

> I'm not sure about getopt, whose supported syntax ReST's option lists are
> documented to implement, but multiple-argument options are well possible
> with Python's optparse standard module, so it's at least nothing wildly
> uncommon.

The reStructuredText Markup Specification states: "There are many
variant option systems, and reStructuredText option lists do not
support all of them." Every step we take is a bit of feature bloat...

--

-- 
David Goodger <http://python.net/~goodger>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Option list with multiple option arguments

On Tue, Nov 11, 2008 at 12:05, Thomas Lotze <thomas <at> thomas-lotze.de> wrote:
> I'm not sure about getopt, whose supported syntax ReST's option lists are
> documented to implement, but multiple-argument options are well possible
> with Python's optparse standard module, so it's at least nothing wildly
> uncommon.

I have never in the last 15 years seen a program take an option of the form 

--optname=arg1 arg2 

or

-o arg1 arg2

so it's not wildly common either 

In fact, I would expect arg2 to stay in argv after processing via optparse, 
unless it was joined by using quotes in the command line, like 

--optname="arg1 arg2"

--

-- 
 ("\''/").__..-''"`-. .         Roberto Alsina
 `9_ 9  )   `-. (    ).`-._.`)  KDE Developer (MFCH)
 (_Y_.)' ._   ) `._`.  " -.-'  http://lateral.netmanagers.com.ar 
  _..`-'_..-_/ /-'_.'     The 6,855th most popular site of Slovenia   
(l)-'' ((i).' ((!.'       according to alexa.com (27/5/2007) 

Debugging is twice as hard as writing the code in the first place. 
Therefore, if you write the code as cleverly as possible, you are, 

Re: Option list with multiple option arguments

Roberto Alsina wrote:

> In fact, I would expect arg2 to stay in argv after processing via
> optparse, unless it was joined by using quotes in the command line, like
> 
> --optname="arg1 arg2"

The nargs option is a documented optparse feature:

>>> import optparse
>>> parser = optparse.OptionParser()
>>> parser.add_option('-r', nargs=2)
<Option at 0xb7cdc56c: -r>
>>> parser.parse_args(['-r', 'arg1', 'arg2'])
(<Values at 0xb7cdc8ec: {'r': ('arg1', 'arg2')}>, [])

The two arguments following -r are stored in the 'r' attribute as a tupel,
and removed from the positional arguments.

--

-- 
Thomas

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Option list with multiple option arguments

"David Goodger" <goodger <at> python.org> wrote:

> On Tue, Nov 11, 2008 at 12:05, Thomas Lotze <thomas <at> thomas-lotze.de> wrote:
> > However, in my case, I find it misleading to use one option name for what
> > is actually two option arguments, even if explained. Would it be possible
> > to extend the syntax to allow for multiple option arguments, each of which
> > might stay as simple as it is now?
> 
> It's possible. Patches are welcome, the more complete the better (e.g.
> tests & docs).

OK, I'll look into it.

--

-- 
Viele Grüße,
Thomas

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/