headers
Beni Cherniavsky | 2 Jul 2004 16:12
Gravatar

Re: Refactoring?

David Priest wrote:
> I'm wondering if we should halt the current development and do two things:
>  * rationalize the reST markup to a very, very high degree.
> 
I don't see how that can be done, except by considering flaws and
possible improvements when somebody notices them. If you see specific
inconsitencies, please post them.

--

-- 
Beni Cherniavsky <cben <at> users.sf.net>
Note: I can only read email on week-ends...

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
Permalink | Reply | 0 comments |
headers
Beni Cherniavsky | 2 Jul 2004 16:19
Gravatar

Re: Re: docutils BUGS.txt,1.9,1.10

David Goodger wrote:
> Felix Wiemann wrote:
>  >> http://cvs.sf.net/viewcvs.py/*checkout*/emu/speech_tools/scripts/
>  >> tex_to_images.prl?rev=HEAD
>  >
>  > If we did URI recognition *before* any other inline markup
>  > recognition, this bug would be fixed.  David, can you implement
>  > that?
> 
> No, because inline literals like ``this='http://example.org/'``
> wouldn't work any more.
> 
Why can't the URL recognition explicitly search inside literal nodes?

--

-- 
Beni Cherniavsky <cben <at> users.sf.net>
Note: I can only read email on week-ends...

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
Permalink | Reply | 1 comment |
headers
David Goodger | 2 Jul 2004 17:30
Favicon

Re: Re: docutils BUGS.txt,1.9,1.10

Beni Cherniavsky wrote:
> Why can't the URL recognition explicitly search inside literal nodes?

Because "No markup interpretation (including backslash-escape
interpretation) is done within inline literals."  That includes
standalone URL recognition.

--

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

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
Permalink | Reply | 0 comments |
headers
David Goodger | 2 Jul 2004 18:28
Favicon

Re: unknown_reference_resolvers example

Jason Diamond wrote:
 > My question is: am I using the API correctly?

Yes, but the 'refname' attribute should be removed, and the node
marked as resolved:

    del node['refname']
    node.resolved = 1

That is now documented in the
docutils.TransformSpec.unknown_reference_resolvers docstring.

 > By the way, what if I wanted to "override" a local reference
 > resolver?  For example, if I have an external reference in a
 > document with the name 'foo' but then add a header in the document
 > with the name 'foo', my link will be resolved to the local header
 > and my resolver will never get called.

The unknown_reference_resolvers functions are only called to resolve
unknown references, like wiki names, where there's a reference in the
document but no corresponding target.  If there *is* a corresponding
target, it's true that the resolver function is not called.  That's
intentional and by design.

 > One way I can think of working around this would be to introduce
 > some extra characters into the reference. `foo`_ could resolve to
 > the local header and `::foo`_ could resolve to the external resource
 > (can you tell I'm a C++ programmer?). I assume that my resolver
 > would have to examine the text content of the reference so that it
 > could check for the leading '::' and remove it so that it doesn't
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jason Diamond | 2 Jul 2004 19:48

Re: unknown_reference_resolvers example

First of all: thanks for the detailed feedback!

David Goodger said:
> Jason Diamond wrote:
>  > My question is: am I using the API correctly?
>
> Yes, but the 'refname' attribute should be removed, and the node
> marked as resolved:
>
>     del node['refname']
>     node.resolved = 1
>
> That is now documented in the
> docutils.TransformSpec.unknown_reference_resolvers docstring.

Should reference nodes have a method to do these three steps as a single
transaction? Perhaps multiple methods since there seems to be different
types of resolved nodes (refuri, refid, and refname).

> The unknown_reference_resolvers functions are only called to resolve
> unknown references, like wiki names, where there's a reference in the
> document but no corresponding target.  If there *is* a corresponding
> target, it's true that the resolver function is not called.  That's
> intentional and by design.

I understand. I am, actually, working on a wiki which is why I'm trying to
use this API. I want to be able to have internal references as docutils
has great support for but also want to be able to reference other pages in
the wiki without having to use yet another syntax.
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Goodger | 3 Jul 2004 21:29
Favicon

Re: unknown_reference_resolvers example

Jason Diamond wrote:
 > First of all: thanks for the detailed feedback!

You're welcome.

 > Should reference nodes have a method to do these three steps as a
 > single transaction? Perhaps multiple methods since there seems to be
 > different types of resolved nodes (refuri, refid, and refname).

The idea may have potential.  We'd have to look through the codebase
to see what patterns exist.

 > Do you think that a "standard" convention for overriding reference
 > resolution would be a good idea?

I don't know.  Is there really a need for
guaranteed-internally-unresolvable references?  IOW, is this really a
problem, or are you just imagining a worst-case scenario that will
rarely if ever actually happen?

 > I'm not trying to force one on you but it might be nice to if
 > everybody who was working on integrating reST into a wiki could use
 > something consistent.

Understood.

 > I'm totally open to suggestions and not at all stuck on the "::"
 > hack if you have any better ideas.

If we do need some way of indicating "external wiki link", I have two
(Continue reading)

Permalink | Reply | 0 comments |
headers
Beni Cherniavsky | 4 Jul 2004 00:59
Gravatar

stylesheet-path in /etc/docutils.conf > stylesheet in ./docutils.conf?

Recently I was playing with my config and tried using
``stylesheet-path`` in /etc/docutils.conf (pretty silly and not what I
wanted but that's not relevant here).  The result was breakage in 
directories that specify their own ``stylesheet`` - the 
``stylesheet-path`` won over it, although it came from /etc/docutils.conf

This is perfectly correct behavior under the current design. I think
this is a design bug. Both ``stylesheet`` and ``stylesheet-path`` serve
(from a user's standpoint) to specify the stylesheet, although in
different ways. The priority among them is pretty arbitrary and IMHO
either should override either when it comes from a more influnecive file.

Implementation-wise, it means that both are converted into a single 
setting containing a tuple with both the path and the type (explicit / 
to-be-adjusted).

Interface-wise, perhaps we should indeed unify these settings, with some 
prefix in the value (e.g. ``stylesheet = adjust:foo/bar`` indicating 
this)?  The old setting names could of course remain for 
backward-compatibility.  What do you think?

--

-- 
Beni Cherniavsky <cben <at> users.sf.net>
Note: I can only read email on week-ends...

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
(Continue reading)

Permalink | Reply | 3 comments |
headers
David Goodger | 4 Jul 2004 05:26
Favicon

Re: stylesheet-path in /etc/docutils.conf > stylesheet in ./docutils.conf?

Beni Cherniavsky wrote:
 > Recently I was playing with my config and tried using
 > ``stylesheet-path`` in /etc/docutils.conf (pretty silly and not what
 > I wanted but that's not relevant here).  The result was breakage in
 > directories that specify their own ``stylesheet`` - the
 > ``stylesheet-path`` won over it, although it came from
 > /etc/docutils.conf
 >
 > This is perfectly correct behavior under the current design. I think
 > this is a design bug. Both ``stylesheet`` and ``stylesheet-path``
 > serve (from a user's standpoint) to specify the stylesheet, although
 > in different ways.  The priority among them is pretty arbitrary

Yes, the priority is arbitrary, but (at least in the current
implementation) it has to be.  "stylesheet" is a verbatim URL, and
"stylesheet-path" is a filesystem path.  They're handled differently.

 > IMHO either should override either when it comes from a more
 > influnecive file.

You can force a later config file's "stylesheet" to override an
earlier file's "stylesheet-path" by adding this setting to the later
file:

     stylesheet-path=

On the command line, use ``--stylesheet-path=''``.  Added to docs.

 > Implementation-wise, it means that both are converted into a single
 > setting containing a tuple with both the path and the type (explicit
(Continue reading)

Permalink | Reply | 2 comments |
headers
Beni Cherniavsky | 9 Jul 2004 13:37
Gravatar

Re: stylesheet-path in /etc/docutils.conf > stylesheetin ./docutils.conf?

David Goodger wrote:
> Beni Cherniavsky wrote:
>  > Recently I was playing with my config and tried using
>  > ``stylesheet-path`` in /etc/docutils.conf (pretty silly and not what
>  > I wanted but that's not relevant here).  The result was breakage in
>  > directories that specify their own ``stylesheet`` - the
>  > ``stylesheet-path`` won over it, although it came from
>  > /etc/docutils.conf
>  >
>  > This is perfectly correct behavior under the current design. I think
>  > this is a design bug. Both ``stylesheet`` and ``stylesheet-path``
>  > serve (from a user's standpoint) to specify the stylesheet, although
>  > in different ways.  The priority among them is pretty arbitrary
> 
> Yes, the priority is arbitrary, but (at least in the current
> implementation) it has to be.  "stylesheet" is a verbatim URL, and
> "stylesheet-path" is a filesystem path.  They're handled differently.
> 
>  > IMHO either should override either when it comes from a more
>  > influnecive file.
> 
> You can force a later config file's "stylesheet" to override an
> earlier file's "stylesheet-path" by adding this setting to the later
> file:
> 
>     stylesheet-path=
> 
> On the command line, use ``--stylesheet-path=''``.  Added to docs.
> 
Thanks for the workaround.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Felix Wiemann | 10 Jul 2004 22:37
Picon

Python 2.4 compatibility

There are two Py2.4 compatibility issues:

Firstly, ConfigParser.set() doesn't allow non-string arguments for
'value' anymore.  See
<http://sourceforge.net/tracker/index.php?func=detail&aid=810843&group_id=5470&atid=105470>
and
<http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Lib/ConfigParser.py>.

The following change might fix this:

--- docutils/frontend.py.~1.63.~	2004-07-10 11:55:58.000000000 +0200
+++ docutils/frontend.py	2004-07-10 21:34:49.000000000 +0200
 <at>  <at>  -609,9 +609,9  <at>  <at> 
                 if validator:
                     value = self.get(section, setting, raw=1)
                     try:
-                        new_value = validator(
+                        new_value = str(validator(
                             setting, value, option_parser,
-                            config_parser=self, config_section=section)
+                            config_parser=self, config_section=section))
                     except Exception, error:
                         raise (ValueError(
                             'Error in config file "%s", section "[%s]":\n'

Then, test_settings.py fails:

------------------------------------------------------------------------
.
test_list (__main__.ConfigEnvVarFileTests)
(Continue reading)

Permalink | Reply | 2 comments |

Gmane