## docutils-develop — For developer discussions of the implementation.

You can subscribe to this list here.

2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 Jan Feb Mar Apr (5) May (27) Jun (22) Jul (72) Aug (82) Sep (86) Oct (138) Nov (100) Dec (62) Jan (122) Feb (147) Mar (92) Apr (82) May (101) Jun (153) Jul (37) Aug (34) Sep (46) Oct (46) Nov (6) Dec (38) Jan (64) Feb (81) Mar (36) Apr (194) May (329) Jun (272) Jul (68) Aug (74) Sep (150) Oct (57) Nov (62) Dec (63) Jan (78) Feb (30) Mar (137) Apr (78) May (54) Jun (122) Jul (72) Aug (110) Sep (80) Oct (75) Nov (125) Dec (79) Jan (100) Feb (15) Mar (41) Apr (67) May (30) Jun (11) Jul (14) Aug (22) Sep (20) Oct (14) Nov (11) Dec (15) Jan (17) Feb (16) Mar (35) Apr (21) May (33) Jun (50) Jul (12) Aug (7) Sep (2) Oct (6) Nov (5) Dec (2) Jan (14) Feb (20) Mar (35) Apr (9) May (57) Jun (21) Jul (42) Aug (4) Sep (13) Oct (76) Nov (40) Dec (55) Jan (26) Feb (15) Mar (3) Apr (67) May (32) Jun (39) Jul (59) Aug (31) Sep (59) Oct (64) Nov (21) Dec (10) Jan (21) Feb (3) Mar (116) Apr (33) May (9) Jun (28) Jul (21) Aug (23) Sep (146) Oct (70) Nov (31) Dec (57) Jan (33) Feb (22) Mar (11) Apr (21) May (51) Jun (47) Jul (35) Aug (26) Sep (25) Oct (34) Nov (61) Dec (51) Jan (75) Feb (31) Mar (26) Apr (16) May (24) Jun (24) Jul (31) Aug (46) Sep (36) Oct (28) Nov (37) Dec (21) Jan (16) Feb (56) Mar (31) Apr (44) May (45) Jun (29) Jul (38) Aug (18) Sep (12) Oct (16) Nov (21) Dec (11) Jan (13) Feb (14) Mar (28) Apr (7) May (72) Jun (33) Jul (21) Aug (1) Sep (6) Oct (14) Nov (18) Dec (22) Jan (23) Feb (108) Mar (76) Apr (114) May (60) Jun (9) Jul (8) Aug (9) Sep (1) Oct Nov Dec
S M T W T F S

1
(4)
2

3

4
(1)
5

6

7
(1)
8
(2)
9

10
(8)
11
(9)
12

13

14
(2)
15
(4)
16
(1)
17
(2)
18
(1)
19

20
(1)
21
(1)
22
(1)
23
(2)
24
(2)
25
(6)
26
(5)
27
(1)
28
(6)
29
(1)
30

Showing results of 61

1 2 3 > >> (Page 1 of 3)
 Re: [Docutils-develop] [ docutils-Feature Requests-3444138 ] Allows easy referencing of section titles From: Guenter Milde - 2011-11-29 09:35:11 On 2011-11-28, David Goodger wrote: > On Mon, Nov 28, 2011 at 14:52, Guenter Milde wrote: >>>>Comment By: David Goodger (goodger) >>> Date: 2011-11-28 06:58 >>> Message: >>> +0 on implementing a self-link feature. >>> -1 on implementing it via the TOC backlinks feature, which is orthogonal. >>> This has nothing to do with the TOC. ... >> You cannot have self-referencing section headings *and* one of >> --toc-entry-backlinks or --toc-top-backlinks. > Sure you could. ToC backlink as currently, plus a "¶" or "§" > self-link. I see you point: If the self-reference is provided by an added object instead of a self-referencing section heading (right-click on the section title would allow to copy the sections URL), there is of course no option clash. [#]_ .. [#] I find the pop-up headerlinks in Sphinx ugly but this should not prevent someone to migrate this feature to Docutils. ... > Let's not call these "backlinks", another misnomer. They wouldn't link > *back* to the ToC. They'd link to the section itself, not *back* to > anything. Sphinx calls them "headerlink". > (I like "§", since it means "section". "¶" was probably > chosen for "Permalink". But whatever, it can be configured.) (In Germany, § is associated with article/section in a law while ¶ is a more generic section sign. The Unicode database says:: 00A7 SECTION SIGN * paragraph sign in some European usage 00B6 PILCROW SIGN = paragraph sign * section sign in some European usage (Georg seems used to this European usage, too.) With CSS2, configuration can be done in the style sheet.) Günter 
 Re: [Docutils-develop] [ docutils-Feature Requests-3444138 ] Allows easy referencing of section titles From: David Goodger - 2011-11-28 20:28:21 On Mon, Nov 28, 2011 at 14:52, Guenter Milde wrote: > On 2011-11-28, SourceForge.net wrote: > >> Initial Comment: > > ... > >> However I would like each section title to have a link to itself, or at >> least some anchor that allows to have the link to the current section, >> regardless whether there's a toc in the document or not. > > ... > >> we could offer a new option for the toc_backlinks setting: > >>   Enable backlinks from section titles to > >>   * table of contents entries ("entry"), >>   * to the top of the TOC ("top"), >>   * to themselves ("self"), >>   * or disable ("none"). > >>   together with a --self-backlinks command line option. > >> Then, with toc_backlinks == "self", right-click on a section title would >> allow to copy the sections URL.>> > >>>Comment By: David Goodger (goodger) >> Date: 2011-11-28 06:58 > >> Message: >> +0 on implementing a self-link feature. > >> -1 on implementing it via the TOC backlinks feature, which is orthogonal. >> This has nothing to do with the TOC. > > While --self-backlinks has nothing to do with the TOC, it nevertheless > correlates: > > The three options --toc-entry-backlinks, --toc-top-backlinks, > --no-toc-backlinks as well as the proposed --self-backlinks determine > the link target of the section headings.  You cannot have > self-referencing section headings *and* one of > --toc-entry-backlinks or --toc-top-backlinks. Sure you could. ToC backlink as currently, plus a "¶" or "§" self-link. (I like "§", since it means "section". "¶" was probably chosen for "Permalink". But whatever, it can be configured.) > This is, why it makes sense to use a common settings variable for all > four command line options. No, it's orthogonal. You can have both at the same time. If you insist on using the section text as the link anchor, you can only use one, but that's an artificial limitation. The ToC backlinks could use a separate character also (make *that* a new option, --toc-backlink-slug or whatever). The only real limitation is that you can only use the section title itself as one anchor at a time. Docutils can warn if the user tries to use the section title as an anchor twice. The two functions are similar, but orthogonal. Let's not conflate them. > I agree that the name "toc-backlinks" is misleading --- > "section-backlinks" or "section-heading-link-targets" would be more > appropriate. Let's not call these "backlinks", another misnomer. They wouldn't link *back* to the ToC. They'd link to the section itself, not *back* to anything. > If there is no need for plain section headings, we could also just > change the behaviour of the --no-toc-backlinks option: instead of no > links at all, section headers would become self-referencing links (which > are, as the setting implies no *toc* backlinks ;-). Let's not change existing functionality. -- David Goodger ; 
 Re: [Docutils-develop] [ docutils-Feature Requests-3444138 ] Allows easy referencing of section titles From: Guenter Milde - 2011-11-28 19:52:52 On 2011-11-28, SourceForge.net wrote: > Initial Comment: ... > However I would like each section title to have a link to itself, or at > least some anchor that allows to have the link to the current section, > regardless whether there's a toc in the document or not. ... > we could offer a new option for the toc_backlinks setting: > Enable backlinks from section titles to > * table of contents entries ("entry"), > * to the top of the TOC ("top"), > * to themselves ("self"), > * or disable ("none"). > together with a --self-backlinks command line option. > Then, with toc_backlinks == "self", right-click on a section title would > allow to copy the sections URL.>> >>Comment By: David Goodger (goodger) > Date: 2011-11-28 06:58 > Message: > +0 on implementing a self-link feature. > -1 on implementing it via the TOC backlinks feature, which is orthogonal. > This has nothing to do with the TOC. While --self-backlinks has nothing to do with the TOC, it nevertheless correlates: The three options --toc-entry-backlinks, --toc-top-backlinks, --no-toc-backlinks as well as the proposed --self-backlinks determine the link target of the section headings. You cannot have self-referencing section headings *and* one of --toc-entry-backlinks or --toc-top-backlinks. This is, why it makes sense to use a common settings variable for all four command line options. I agree that the name "toc-backlinks" is misleading --- "section-backlinks" or "section-heading-link-targets" would be more appropriate. If there is no need for plain section headings, we could also just change the behaviour of the --no-toc-backlinks option: instead of no links at all, section headers would become self-referencing links (which are, as the setting implies no *toc* backlinks ;-). Günter 
 [Docutils-develop] [ docutils-Feature Requests-3444138 ] Allows easy referencing of section titles From: SourceForge.net - 2011-11-28 14:58:25 Feature Requests item #3444138, was opened at 2011-11-28 06:44 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422033&aid=3444138&group_id=38414 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Yuri D'Elia (wavexx) Assigned to: Nobody/Anonymous (nobody) Summary: Allows easy referencing of section titles Initial Comment: In rst2html, you have three choices regarding to generating toc backlinks: --no-toc-backlinks --top-toc-backlinks --toc-entry-backlinks However I would like each section title to have a link to itself, or at least some anchor that allows to have the link to the current section, regardless whether there's a toc in the document or not. This is very handy when referencing online documents. Sphinx does something similar by using an on-hover pilcrow: http://docs.python.org/reference/compound_stmts.html#the-for-statement after each section title, there's pilcrow (on hover) linking to the current section. See the discussion at: http://thread.gmane.org/gmane.text.docutils.user/6517 < brings you to the toc, * right-click at the toc entry and select "copy link address", * paste the link in the editor. Example: http://docutils.sourceforge.net/docs/dev/todo.html#epub-html-writer b) Without a toc or with --no-toc-backlinks, this work-flow does not work: * no "copyable link" in the document without a toc * "copyable link" in the toc not easy to find when reading the section with --no-toc-backlinks. So, while I don't like Sphinx's "pop-up" pilcrows, I see their use in case b) (and for other referencable objects). You could file a feature request at the tracker http://sourceforge.net/tracker/?group_id=38414&atid=422033 Alternatively, we could offer a new option for the toc_backlinks setting: Enable backlinks from section titles to * table of contents entries ("entry"), * to the top of the TOC ("top"), * to themselves ("self"), * or disable ("none"). together with a --self-backlinks command line option. Then, with toc_backlinks == "self", right-click on a section title would allow to copy the sections URL.>> That's exactly my use case as well: I generate online documents with rst2html all the time, and whenever I need to reference to a document I usually do link to the relevant section. I was already aware of the "entry" option (to toc, then get the url), but that's rather inconvenient, and as you say it doesn't work whenever the toc is missing. I'm personally fine with either the Sphinx solution ("on-hover pilcrow", which would be easy enough to customize via css) or via the "self" behavior (which I like much more at the moment. Admittedly I have never used the back-to-toc feature of the section titles, I would instead certainly use the direct link without further fuss). ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2011-11-28 06:58 Message: +0 on implementing a self-link feature. -1 on implementing it via the TOC backlinks feature, which is orthogonal. This has nothing to do with the TOC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422033&aid=3444138&group_id=38414 
 [Docutils-develop] [ docutils-Feature Requests-3444138 ] Allows easy referencing of section titles From: SourceForge.net - 2011-11-28 14:44:36 Feature Requests item #3444138, was opened at 2011-11-28 06:44 Message generated for change (Tracker Item Submitted) made by wavexx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422033&aid=3444138&group_id=38414 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Yuri D'Elia (wavexx) Assigned to: Nobody/Anonymous (nobody) Summary: Allows easy referencing of section titles Initial Comment: In rst2html, you have three choices regarding to generating toc backlinks: --no-toc-backlinks --top-toc-backlinks --toc-entry-backlinks However I would like each section title to have a link to itself, or at least some anchor that allows to have the link to the current section, regardless whether there's a toc in the document or not. This is very handy when referencing online documents. Sphinx does something similar by using an on-hover pilcrow: http://docs.python.org/reference/compound_stmts.html#the-for-statement after each section title, there's pilcrow (on hover) linking to the current section. See the discussion at: http://thread.gmane.org/gmane.text.docutils.user/6517 < brings you to the toc, * right-click at the toc entry and select "copy link address", * paste the link in the editor. Example: http://docutils.sourceforge.net/docs/dev/todo.html#epub-html-writer b) Without a toc or with --no-toc-backlinks, this work-flow does not work: * no "copyable link" in the document without a toc * "copyable link" in the toc not easy to find when reading the section with --no-toc-backlinks. So, while I don't like Sphinx's "pop-up" pilcrows, I see their use in case b) (and for other referencable objects). You could file a feature request at the tracker http://sourceforge.net/tracker/?group_id=38414&atid=422033 Alternatively, we could offer a new option for the toc_backlinks setting: Enable backlinks from section titles to * table of contents entries ("entry"), * to the top of the TOC ("top"), * to themselves ("self"), * or disable ("none"). together with a --self-backlinks command line option. Then, with toc_backlinks == "self", right-click on a section title would allow to copy the sections URL.>> That's exactly my use case as well: I generate online documents with rst2html all the time, and whenever I need to reference to a document I usually do link to the relevant section. I was already aware of the "entry" option (to toc, then get the url), but that's rather inconvenient, and as you say it doesn't work whenever the toc is missing. I'm personally fine with either the Sphinx solution ("on-hover pilcrow", which would be easy enough to customize via css) or via the "self" behavior (which I like much more at the moment. Admittedly I have never used the back-to-toc feature of the section titles, I would instead certainly use the direct link without further fuss). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422033&aid=3444138&group_id=38414 
 Re: [Docutils-develop] How can I test if a directive is available? From: Guenter Milde - 2011-11-28 12:43:01 On 2011-11-24, Martin Bless wrote: > This is what I want to do: > if not directive_is_available('field-list-table'): > from fieldlisttable import FieldListTable > register_directive('field-list-table', FieldListTable) > Q: How would I write that test function?: > def directive_is_available(name): > "some clever coding" > return True or False a) using the internal dictionary docutils.parsers.rst.directives._directives:: def directive_is_available(name): return name in _directives Simple but relies on the internal implementation. b) with try/except using some "probe" call to the directive via the registration interface. c) not at all. Instead, place the registration code in the fieldlisttable module and use an uncoditional :: from fieldlisttable import FieldListTable As import evaluates the module only once, this should do the trick. Günter 
 Re: [Docutils-develop] where is docutils moving to? From: Guenter Milde - 2011-11-28 07:22:36 On 2011-11-27, engelbert gruber wrote: > plan > * revoke all write grants to berlios > * svnadmin dump on berlios > * import into sf svn > is it that simple ? Basically. (I hope so.) Some more points: * The daily snapshot build: * do we want to keep it? * can we just move the script (with little adaptions)? * Check documentation for references to berlios.de * update docutils-SVN docs * fix links Could you do this? And in the future: * Check whether we can auto-build the web site (again) with the SVN repo at Docutils. * Consider moving to distributed VS (git, ...) (However, using the repo with git svn is already possible and helpfull.) Thanks, Günter 
 Re: [Docutils-develop] where is docutils moving to? From: engelbert gruber - 2011-11-27 19:21:27 plan * revoke all write grants to berlios * svnadmin dump on berlios * import into sf svn is it that simple ? -- engelbert On Fri, Nov 25, 2011 at 8:46 PM, Guenter Milde wrote: > On 2011-11-25, Paul Tremblay wrote: > >> With berlios no longer hosting projects, any thoughts on where docutils is >> going to migrate to? > > As > > * using berlios for the repo was only done because sourceforge did not >  offer SVN at this time and > > * SVN is supported by sourceforge for some years now, > > moving the repo to sourceforge seems the "minimal invasive" choice. > > > (Someone has to do it, though.) > > Günter > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Docutils-develop mailing list > Docutils-develop@... > https://lists.sourceforge.net/lists/listinfo/docutils-develop > > Please use "Reply All" to reply to the list. > -- http://darefoot.blogspot.com 
 Re: [Docutils-develop] where is docutils moving to? From: Aahz - 2011-11-26 22:58:39 On Sat, Nov 26, 2011, Matthew Brett wrote: > > [2] http://nipyworld.blogspot.com/2011/07/why-you-shouldnt-use-google-code.html Also, Google is killing code search, I wouldn't trust them to keep code, either: http://googleblog.blogspot.com/2011/10/fall-sweep.html -- Aahz (aahz@...) <*> http://www.pythoncraft.com/ "....Normal is what cuts off your sixth finger and your tail..." --Siobhan 
 Re: [Docutils-develop] where is docutils moving to? From: Matthew Brett - 2011-11-26 22:19:29 Hi, On Sat, Nov 26, 2011 at 1:04 PM, Ben Finney wrote: > Matthew Brett writes: > >> Hi, >> >> On Fri, Nov 25, 2011 at 3:26 PM, Fred Drake wrote: >> > I think SourceForge has been bypassed for new projects since many >> > didn't really like their tracker, and sticking with CVS for so long >> > was a mistake on their part. >> >> Also a lot of projects are switching to distributed version control >> (mercurial -> bitbucket, git -> github) > > Note that Sourceforge has DVCS hosting for projects since 2009 > ; > ;. Right - sourceforge do git too [1]. My impression (uninformed by data) is that users of mercurial have preferred the code interfaces of bitbucket or google code [2], and users of git vastly prefer github. Obviously bitbucket or github aren't going to be of much interest if you're sticking with subversion. Best, Matthew [1] http://sourceforge.net/apps/trac/sourceforge/wiki/Git [2] http://nipyworld.blogspot.com/2011/07/why-you-shouldnt-use-google-code.html 
 Re: [Docutils-develop] where is docutils moving to? From: Ben Finney - 2011-11-26 21:04:38 Matthew Brett writes: > Hi, > > On Fri, Nov 25, 2011 at 3:26 PM, Fred Drake wrote: > > I think SourceForge has been bypassed for new projects since many > > didn't really like their tracker, and sticking with CVS for so long > > was a mistake on their part. > > Also a lot of projects are switching to distributed version control > (mercurial -> bitbucket, git -> github) Note that Sourceforge has DVCS hosting for projects since 2009 ; ;. -- \ “The number of UNIX installations has grown to 10, with more | \ expected.” —Unix Programmer's Manual, 2nd Ed., 1972-06-12 | _o__) | Ben Finney 
 Re: [Docutils-develop] where is docutils moving to? From: Matthew Brett - 2011-11-26 18:52:09 Hi, On Fri, Nov 25, 2011 at 3:26 PM, Fred Drake wrote: > On Fri, Nov 25, 2011 at 5:32 PM, Paul Tremblay wrote: >> When I did a search on line, I found that bitbucket >> and github seem to be all the rage, and no one is using sourceforge. I >> just wondered if I am missing something. > > I think SourceForge has been bypassed for new projects since many > didn't really like their tracker, and sticking with CVS for so long > was a mistake on their part. > > Since then, I think their status was pretty well set.  We just don't > hear about them much any more. Also a lot of projects are switching to distributed version control (mercurial -> bitbucket, git -> github) http://www.joelonsoftware.com/items/2010/03/17.html Best, Matthew 
 [Docutils-develop] [ docutils-Bugs-3442827 ] ImportError: no module named roman after upgrade From: SourceForge.net - 2011-11-26 15:25:02 Bugs item #3442827, was opened at 2011-11-26 07:25 Message generated for change (Tracker Item Submitted) made by jaraco You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3442827&group_id=38414 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason R. Coombs (jaraco) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: no module named roman after upgrade Initial Comment: Related to #2971827, the detection of the run-time environment doesn't just affect buildout deployments, but any deployment doing an upgrade using setuptools. Consider this scenario: 1) User installs docutils 0.8. 2) User upgrades to docutils 0.8.1. During the upgrade, the install detects that roman is present (because it's part of 0.8), so doesn't include it in the install of 0.8.1. Shortly thereafter, setuptools removes 0.8 from the path. Now 0.8.1 is installed without a roman module. This happened to me on Python 2.7.2 (see transcript below). I can think of a few possible solutions to this issue: 1) Abandon Python 2.3 and 2.4 support (as suggested in 2971827) and depend on the roman package. 2) Keep Python 2.3 and 2.4 support, but use a more robust implementation for the roman dependency in later versions. 3) Abandon strict distutils support and require setuptools and depend on the roman package. 4) Always include the roman module as docutils.roman or similar and only import it if a system roman module is not present. I see reports of this issue going back many years. Surely something can be done. {{{ PS C:\Users\jaraco\projects\RecaptureDocs\recapturedocs\text> easy_install -U docutils Searching for docutils Reading http://pypi.python.org/simple/docutils/ Reading http://docutils.sourceforge.net/ Best match: docutils 0.8.1 Downloading http://pypi.python.org/packages/source/d/docutils/docutils-0.8.1.tar.gz#md5=2ecf8ba3ece1be1ed666150a80c838c8 Processing docutils-0.8.1.tar.gz Running docutils-0.8.1\setup.py -q bdist_egg --dist-dir c:\users\jaraco\appdata\local\temp\easy_install-5eghqz\docutils-0.8.1\egg-dist-tmp-xl5omq "roman" module already present; ignoring extras/roman.py. warning: no files found matching 'MANIFEST' warning: no previously-included files matching '.cvsignore' found under directory '*' warning: no previously-included files matching '*.pyc' found under directory '*' warning: no previously-included files matching '*~' found under directory '*' warning: no previously-included files matching '.DS_Store' found under directory '*' zip_safe flag not set; analyzing archive contents... docutils.parsers.rst.directives.misc: module references __file__ docutils.writers.html4css1.__init__: module references __file__ docutils.writers.latex2e.__init__: module references __file__ docutils.writers.odf_odt.__init__: module references __file__ docutils.writers.pep_html.__init__: module references __file__ docutils.writers.s5_html.__init__: module references __file__ Removing docutils 0.8 from easy-install.pth file Adding docutils 0.8.1 to easy-install.pth file Installing rst2html.py script to c:\python\Scripts Installing rst2latex.py script to c:\python\Scripts Installing rst2man.py script to c:\python\Scripts Installing rst2odt.py script to c:\python\Scripts Installing rst2odt_prepstyles.py script to c:\python\Scripts Installing rst2pseudoxml.py script to c:\python\Scripts Installing rst2s5.py script to c:\python\Scripts Installing rst2xetex.py script to c:\python\Scripts Installing rst2xml.py script to c:\python\Scripts Installing rstpep2html.py script to c:\python\Scripts Installed c:\python\lib\site-packages\docutils-0.8.1-py2.7.egg Processing dependencies for docutils Finished processing dependencies for docutils PS C:\Users\jaraco\projects\RecaptureDocs\recapturedocs\text> rst2html '.\work in progress.rst' Traceback (most recent call last): File "c:\python\scripts\rst2html.py", line 5, in pkg_resources.run_script('docutils==0.8.1', 'rst2html.py') File "C:\Python\lib\site-packages\distribute-0.6.24-py2.7.egg\pkg_resources.py", line 499, in run_script self.require(requires)[0].run_script(script_name, ns) File "C:\Python\lib\site-packages\distribute-0.6.24-py2.7.egg\pkg_resources.py", line 1235, in run_script execfile(script_filename, namespace, namespace) File "c:\python\lib\site-packages\docutils-0.8.1-py2.7.egg\EGG-INFO\scripts\rst2html.py", line 23, in publish_cmdline(writer_name='html', description=description) File "C:\Python\lib\site-packages\docutils-0.8.1-py2.7.egg\docutils\core.py", line 336, in publish_cmdline pub.set_components(reader_name, parser_name, writer_name) File "C:\Python\lib\site-packages\docutils-0.8.1-py2.7.egg\docutils\core.py", line 93, in set_components self.set_reader(reader_name, self.parser, parser_name) File "C:\Python\lib\site-packages\docutils-0.8.1-py2.7.egg\docutils\core.py", line 83, in set_reader self.reader = reader_class(parser, parser_name) File "C:\Python\lib\site-packages\docutils-0.8.1-py2.7.egg\docutils\readers\__init__.py", line 49, in __init__ self.set_parser(parser_name) File "C:\Python\lib\site-packages\docutils-0.8.1-py2.7.egg\docutils\readers\__init__.py", line 60, in set_parser parser_class = parsers.get_parser_class(parser_name) File "C:\Python\lib\site-packages\docutils-0.8.1-py2.7.egg\docutils\parsers\__init__.py", line 46, in get_parser_class module = __import__(parser_name, globals(), locals()) File "C:\Python\lib\site-packages\docutils-0.8.1-py2.7.egg\docutils\parsers\rst\__init__.py", line 75, in from docutils.parsers.rst import states File "C:\Python\lib\site-packages\docutils-0.8.1-py2.7.egg\docutils\parsers\rst\states.py", line 108, in import roman ImportError: No module named roman }}} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3442827&group_id=38414 
 Re: [Docutils-develop] where is docutils moving to? From: Fred Drake - 2011-11-25 23:27:24 On Fri, Nov 25, 2011 at 5:32 PM, Paul Tremblay wrote: > When I did a search on line, I found that bitbucket > and github seem to be all the rage, and no one is using sourceforge. I > just wondered if I am missing something. I think SourceForge has been bypassed for new projects since many didn't really like their tracker, and sticking with CVS for so long was a mistake on their part. Since then, I think their status was pretty well set. We just don't hear about them much any more.   -Fred -- Fred L. Drake, Jr.    "A storm broke loose in my mind."  --Albert Einstein 
 Re: [Docutils-develop] where is docutils moving to? From: Paul Tremblay - 2011-11-25 22:33:06 On 11/25/11 2:46 PM, Guenter Milde wrote: > On 2011-11-25, Paul Tremblay wrote: > >> With berlios no longer hosting projects, any thoughts on where docutils is >> going to migrate to? > As > > * using berlios for the repo was only done because sourceforge did not > offer SVN at this time and > > * SVN is supported by sourceforge for some years now, > > moving the repo to sourceforge seems the "minimal invasive" choice. > > > (Someone has to do it, though.) > > That sounds logical. When I did a search on line, I found that bitbucket and github seem to be all the rage, and no one is using sourceforge. I just wondered if I am missing something. Paul 
 [Docutils-develop] [ docutils-Bugs-2926161 ] combining unicode chars count in grid tables From: SourceForge.net - 2011-11-25 21:25:28 Bugs item #2926161, was opened at 2010-01-05 02:49 Message generated for change (Comment added) made by milde You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=2926161&group_id=38414 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None >Priority: 3 Private: No Submitted By: Günter Milde (milde) Assigned to: Nobody/Anonymous (nobody) >Summary: combining unicode chars count in grid tables Initial Comment: Combining unicode chars in headings like à with varia ----------------- and simple tables lead to warnings and errors, as they contribute to the string lenght. ---------------------------------------------------------------------- >Comment By: Günter Milde (milde) Date: 2011-11-25 13:25 Message: Fixed for headings and simple tables. Fixing grid tables is an open task. Tools are in docutils.utils but the grid table parser is rather complex. ---------------------------------------------------------------------- Comment By: Günter Milde (milde) Date: 2010-11-10 04:05 Message: Fixed for section headings. The fix for tables is nontrivial, as both stringlist.get_2D_block() in statemachine.py and SimpleTableParser.check_columns() in tableparser.py must be made to account for zero-width combining chars. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=2926161&group_id=38414 
 Re: [Docutils-develop] where is docutils moving to? From: Guenter Milde - 2011-11-25 19:50:18 On 2011-11-25, Paul Tremblay wrote: > With berlios no longer hosting projects, any thoughts on where docutils is > going to migrate to? As * using berlios for the repo was only done because sourceforge did not offer SVN at this time and * SVN is supported by sourceforge for some years now, moving the repo to sourceforge seems the "minimal invasive" choice. (Someone has to do it, though.) Günter 
 [Docutils-develop] where is docutils moving to? From: Paul Tremblay - 2011-11-25 18:10:57 Attachments: Message as HTML With berlios no longer hosting projects, any thoughts on where docutils is going to migrate to? Paul 
 Re: [Docutils-develop] math in HTML From: Guenter Milde - 2011-11-25 07:11:46 On 2011-11-10, Guenter Milde wrote: > currently, HTML math output defaults to embedded MathML: ... > With the "html4css1" writer, the resulting HTML document does > not validate, as there is no DTD for MathML + XHTML > Transitional. However, MathML-enabled browsers will render it > fine. After evaluating the responses (1), I choose > a) a different math-output default ... >:MathJax: > Format math for display with MathJax_, a JavaScript-based math > rendering engine that uses HTML/CSS, JavaScript, and unicode > fonts for high-quality typesetting that is scalable and prints > at full resolution. > Pro: > Works 'out of the box' across multiple browsers and platforms. > Supports a large subset of LaTeX math commands and constructs > (see http://www.mathjax.org/docs/1.1/tex.html). > Con: > Requires an Internet connection or a local MathJax > installation. Günter 
 [Docutils-develop] How can I test if a directive is available? From: Martin Bless - 2011-11-24 22:08:04 This is what I want to do: if not directive_is_available('field-list-table'): from fieldlisttable import FieldListTable register_directive('field-list-table', FieldListTable) Q: How would I write that test function?: def directive_is_available(name): "some clever coding" return True or False cheers ... Martin -- http://mbless.de 
 [Docutils-develop] [ docutils-Bugs-3423983 ] test_writers.test_docutils_xml.DocutilsXMLTestCase fails From: SourceForge.net - 2011-11-24 09:02:11 Bugs item #3423983, was opened at 2011-10-14 17:18 Message generated for change (Comment added) made by milde You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3423983&group_id=38414 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jakub Wilk (jakub-wilk) Assigned to: Nobody/Anonymous (nobody) Summary: test_writers.test_docutils_xml.DocutilsXMLTestCase fails Initial Comment: It looks like recent changes to xml.dom.minidom[0][1] broke test_writers.test_docutils_xml.DocutilsXMLTestCase: ====================================================================== FAIL: test_publish (test_writers.test_docutils_xml.DocutilsXMLTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/build/python-docutils-_daXVI/python-docutils-0.8.1/test/test_writers/test_docutils_xml.py", line 80, in test_publish expected) File "/build/python-docutils-_daXVI/python-docutils-0.8.1/test/DocutilsTestSupport.py", line 116, in failUnlessEqual (msg or '%s != %s' % _format_str(first, second)) AssertionError: '''\ Test Test. \xe4\xf6\xfc€ ''' != '''\ Test Test. \xe4\xf6\xfc€ ''' [0] http://bugs.python.org/issue4147 [1] http://hg.python.org/cpython/rev/fa0b1e50270f ---------------------------------------------------------------------- >Comment By: Günter Milde (milde) Date: 2011-11-24 01:02 Message: Applied the patch from the mailing list with some modifications to separate sample strings from the logic. Thanks! ---------------------------------------------------------------------- Comment By: Günter Milde (milde) Date: 2011-11-24 01:02 Message: Fixed; thanks for the bug report. You can download a current snapshot from: http://docutils.sf.net/docutils-snapshot.tgz ---------------------------------------------------------------------- Comment By: Jakub Wilk (jakub-wilk) Date: 2011-10-20 14:22 Message: Indeed, when I originally wrote the bug report, I didn't realize that Python in Debian is so heavily patched (it's in fact based on Mercurial snapshot). Sorry for the noise. ---------------------------------------------------------------------- Comment By: Günter Milde (milde) Date: 2011-10-20 14:13 Message: Looking at the Debian bugreport http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645369 I get the impression that this affects only a patched xml.dom.minidom.toprettyxml in Debian's "python2.7" package, version 2.7.2-7. Putting this in "Pending" status. For a solution, either the patch needs to be revoked or we need a recipe to tell the patched module from the original one. ---------------------------------------------------------------------- Comment By: Günter Milde (milde) Date: 2011-10-17 03:30 Message: Thanks for your bug report. It looks like the test needs either to consider python versions or to be relaxed. Can you provide a version test line that could be used to define two variants of the bodyindents string used in test/test_writers/test_docutils_xml.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3423983&group_id=38414 
 Re: [Docutils-develop] test_writers.test_docutils_xml.DocutilsXMLTestCase.test_publish() fails with future versions of Python 2.7 and >=3.2 From: Arfrever Frehtes Taifersar Arahesis - 2011-11-23 22:25:48 Attachments: Message as HTML     signature.asc
 [Docutils-develop] Please look at this implementation of the "field-list-table"-directive From: Martin Bless - 2011-11-23 14:54:18 Hello everybody, I'm glad I can present a first version of the "field-list-table"-directive. For the whole story please see: http://mbless.de/4us/typo3-oo2rest/06-The-%5Bfield-list-table%5D-directive/1-demo.rst.html Feedback welcome! Currently I'm not aware of any errors. The error handling isn't state of the art yet and often just uses 'sys.exit(1)'. Also there is no unit test in the moment. OTH the above document shows quite some capabilites. It is also shown in the folder of the above document how homebrew directives can be included and how the HTML-writer can be inherited and modified. ... happily dreaming a little dream ... Martin -- http://mbless 
 Re: [Docutils-develop] strip-elements-with-classes From: Guenter Milde - 2011-11-22 08:05:27 On 2011-11-17, Guenter Milde wrote: > Dear List, > why is it, that compiling:: > paragraph foo > .. class:: moo > paragraph moo > with rst2... --strip-elements-with-class moo works as expected, > but the config line :: > strip-elements-with-classes: moo > does not? > Is this an mistake my config file or a bug in the transform or the config > file reader? Found it. It is a bug in the config file reader. It affects strip-elements-with-classes and strip-classes, where config file values were not converted to a list. I will submit a patch when the test cases are ready. Günter 
 Re: [Docutils-develop] german translation for "pull-quote"?! From: Martin Bless - 2011-11-21 07:56:38 [Guenter Milde] wrote & schrieb: >On 2011-11-18, Martin Bless wrote: [...] >> (A) From reading [1] "Lockzitat" came into my mind. I'm feeling its a >> very precise, short and "sexy" translation. Analogous to >> "Lockangebot". >True. :-) And thank you very much for pondering and for the references. Cool. If "Lockzitat" doesn't quite have the "bingo, that's it" quality by itself I'd prefer leaving it as it is: "pull-quote". But it should never become "Kasten" - a question that's noted as comment in the language file. And yes, I'm going to spread the word. At Leo, as you suggest. BTW, http://www.linguee.de/ is another very interest spot for finding translations English <-> German as well. Special: It has a large stock of texts that have been translated already by humans. Martin -- http://mbless.de `

Showing results of 61

1 2 3 > >> (Page 1 of 3)