## 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 (6) 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 Nov Dec
S M T W T F S

1
(1)
2
(1)
3
(10)
4

5
(3)
6
(2)
7
(3)
8
(1)
9

10

11

12

13

14
(1)
15

16
(2)
17

18

19

20
(4)
21
(4)
22
(1)
23
(2)
24

25

26
(1)
27

28

29

30

Showing results of 36

1 2 > >> (Page 1 of 2)
 Re: [Docutils-develop] emphasis/strong within literal_block? From: Kirill Smelkov - 2012-09-26 08:15:30 Günter, On Sun, Sep 23, 2012 at 07:28:28PM +0000, Guenter Milde wrote: > On 2012-09-20, Kirill Smelkov wrote: > > Hello, > > > On Tue, Dec 24, 2002 at 04:44:20PM -0500, David Goodger wrote: > >> [Benja Fallenstein] > >> >> IIRC parsed-literal is a directive, so, > >> >> > >> >> .. parsed-literal:: > >> >> > > >> [Bill Bumgarner] > >> > Right. Got it. That works great. > >> > > >> > But it looks ugly-- it is the first intrusive formatting command I have > >> > had to include in the documents. Feature request; maybe if a > >> > paragraph ends in :;, the following block is a parsed literal as > >> > opposed to a literal block? > > >> Adding ";;" as syntax is already a "to do?" item (search > >> ; for 'Syntax for the "line-block" > >> directive?'). ":;" is equivalent; I can see advantages and disadvantages. > > >> Such syntax would be a minor enhancement (or wart, depending on tolerance > >> levels). If you want it, a patch is the best way to get it. Building > >> consensus is also required. You've got to push for it. > > > Just a FYI: I needed it and implemented a patch for it using ::~ suffix. > > The patch is here: > > > https://sourceforge.net/tracker/?func=detail&aid=3570019&group_id=38414&atid=422032 > > My idea is to make the meaning of the "literal block syntax" configurable: > > Analogue to customising the default role of "interpreted text" with the > "default-role" directive, the concise :: literal-block markup could be > used for e.g. > > * a "code-block" directive for syntax highight > > * the "line-block" directive for poems or addresses > > * the "parsed-literal" directive > > Example:: > > ordinary literal block:: > > some text typeset in monospace > > .. default-literal-block:: code-block python > > this is colourful Python code:: > > def hello(): > print "hello world" > > > In the same line, a "default-block-quote" setting or directive could be > considered to configure the role of a block quote. I think it is maybe useful to be able to set the default style, and considering analogue with roles something like the following could be used: ordinary literal block:: some text text text ... a code block::(code) some code etc... but as with roles we have :emphasis: and :strong: etc, we also have shortcuts like "*text*" and "**text**" or the text could quickly become more verbose and less .txt like. So my imho is that having a shortcut (maybe tunable) for parsed literal block still would be a good thing. Thanks for replying, Kirill 
 Re: [Docutils-develop] emphasis/strong within literal_block? From: Guenter Milde - 2012-09-23 19:30:07 On 2012-09-20, Kirill Smelkov wrote: > Hello, > On Tue, Dec 24, 2002 at 04:44:20PM -0500, David Goodger wrote: >> [Benja Fallenstein] >> >> IIRC parsed-literal is a directive, so, >> >> >> >> .. parsed-literal:: >> >> >> [Bill Bumgarner] >> > Right. Got it. That works great. >> > >> > But it looks ugly-- it is the first intrusive formatting command I have >> > had to include in the documents. Feature request; maybe if a >> > paragraph ends in :;, the following block is a parsed literal as >> > opposed to a literal block? >> Adding ";;" as syntax is already a "to do?" item (search >> ; for 'Syntax for the "line-block" >> directive?'). ":;" is equivalent; I can see advantages and disadvantages. >> Such syntax would be a minor enhancement (or wart, depending on tolerance >> levels). If you want it, a patch is the best way to get it. Building >> consensus is also required. You've got to push for it. > Just a FYI: I needed it and implemented a patch for it using ::~ suffix. > The patch is here: > https://sourceforge.net/tracker/?func=detail&aid=3570019&group_id=38414&atid=422032 My idea is to make the meaning of the "literal block syntax" configurable: Analogue to customising the default role of "interpreted text" with the "default-role" directive, the concise :: literal-block markup could be used for e.g. * a "code-block" directive for syntax highight * the "line-block" directive for poems or addresses * the "parsed-literal" directive Example:: ordinary literal block:: some text typeset in monospace .. default-literal-block:: code-block python this is colourful Python code:: def hello(): print "hello world" In the same line, a "default-block-quote" setting or directive could be considered to configure the role of a block quote. Günter 
 Re: [Docutils-develop] [ docutils-Feature Requests-3563801 ] include directive and parsed literals From: Guenter Milde - 2012-09-23 19:23:46 On 2012-09-21, SourceForge.net wrote: > Initial Comment: > With Docutils >= 0.9, it is impossible to include HTML files (without > parsing of rst-inline-markup in the HTML file) with the "include" > directive:: > .. include:: test.html > :code: HTML > It would be nice to have a new option for the include directive that > allowed one to pass the content of the included file to a "parsed > literal" block. Something like: > .. include:: test.html > :parsed-literal: HTML > ---------------------------------------------------------------------- >>Comment By: David Goodger (goodger) > Date: 2012-09-21 07:05 > Message: > I don't understand the request. What does "rst-inline-markup in the HTML > file" mean? Please show an example of the input file and describe what you > want as output. The idea is to allow input of an external file as parsed-literal block similar to the input as a literal block with the :litaral: option. A use case could be similar to what is stated as use case for the parsed-literal directive: source code with links and/or other inline markup, e.g. File ham.html:: ;

nice

File eggs.txt:: This is the file ham.html: .. input:: ham.html :parsed-literal: .. _das: http://example.org/very/nice/example The request comes from a Sphinx user, where it is possible to have syntax highlight of code in a parsed-literal block. This explains the idea to specify a code language as well, something that will most probably not be implemented in Docutils. Günter 
 Re: [Docutils-develop] Version 1.4.0 of rst.el From: Stefan Merten - 2012-09-22 09:50:03 Attachments: Message as HTML Hi Ben and all! Yesterday Ben Finney wrote: > In announcements like this, can you give the URL to this new release? Good point. As always it's in the SVN main line at http://docutils.svn.sourceforge.net/svnroot/docutils/trunk/docutils/tools/editors/emacs/rst.el or as a complete package at http://www.merten-home.de/FreeSoftware/rst_el/ Grüße Stefan 
 [Docutils-develop] [ docutils-Feature Requests-3563801 ] include directive and parsed literals From: SourceForge.net - 2012-09-21 14:05:46 Feature Requests item #3563801, was opened at 2012-08-31 11:49 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422033&aid=3563801&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: Mike Solomon (organdiae) Assigned to: Nobody/Anonymous (nobody) Summary: include directive and parsed literals Initial Comment: With Docutils >= 0.9, it is impossible to include HTML files (without parsing of rst-inline-markup in the HTML file) with the "include" directive:: .. include:: test.html :code: HTML It would be nice to have a new option for the include directive that allowed one to pass the content of the included file to a "parsed literal" block. Something like: .. include:: test.html :parsed-literal: HTML ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2012-09-21 07:05 Message: I don't understand the request. What does "rst-inline-markup in the HTML file" mean? Please show an example of the input file and describe what you want as output. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422033&aid=3563801&group_id=38414 
 Re: [Docutils-develop] Configuring MathJax URL From: Guenter Milde - 2012-09-21 14:02:16 On 2012-09-08, Dmitry Shachnev wrote: Hi everybody! > I've written a small patch that adds an ability to configure URL of > MathJax JS file. The configuration is done by appending the URL to value > of "math_output" setting. When nothing is appended, the default URL is > used. The "MathJax" word (which can be lowercase) and the URL can be > separated by a space or any other character. ... > My patch can be found at: > http://sourceforge.net/tracker/index.php?func=detail&aid=3540052&group_id=38414&atid=422030. Thanks for the patch and sorry for taking so long. I have some problems with the patch as it is now: 1. I opt for whitespace as separator between keyword and mathjax-URL: * dropping one character between the keyword and the mathjax URL is error prone (how about two spaces?) and without precedence. * a comma separates list values (class arguments, stylesheets) in other options. It might be used for a list of math-output formats later (e.g. fallbacks to try when an error occurs) and should therefore not be used within one output format specifier. * if given on the command line, the argument can be quoted like --math-output="mathjax myURL". 2. The configuration part of the URL (?config=TeX-AMS-MML_HTMLorMML) should not be hardcoded but part of the configurable URL. (See the mathjax homepage for the many options that users may want to specify.) 3. There should be a test case. I will add support for a configurable mathjax-URL when time permits. > See also http://bugs.debian.org/677929 for the corresponding bug report > in Debian. My preference for solving this bug is changing the default math-output of the html4css1 writer to HTML+CSS. My question how to handle the required math.css style sheet still waits for a comment from co-developers. If noone responds, I may end up implementing automatic loading of the stylesheet if there is math content with the option to add an alternative stylesheet URL to the math-output option (similar to the mathjax-URL). Günter 
 [Docutils-develop] [ docutils-Feature Requests-3563801 ] include directive and parsed literals From: SourceForge.net - 2012-09-21 13:04:26 Feature Requests item #3563801, was opened at 2012-08-31 11:49 Message generated for change (Settings changed) made by milde You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422033&aid=3563801&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: Mike Solomon (organdiae) Assigned to: Nobody/Anonymous (nobody) Summary: include directive and parsed literals Initial Comment: With Docutils >= 0.9, it is impossible to include HTML files (without parsing of rst-inline-markup in the HTML file) with the "include" directive:: .. include:: test.html :code: HTML It would be nice to have a new option for the include directive that allowed one to pass the content of the included file to a "parsed literal" block. Something like: .. include:: test.html :parsed-literal: HTML ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422033&aid=3563801&group_id=38414 
 Re: [Docutils-develop] Version 1.4.0 of rst.el From: Ben Finney - 2012-09-21 03:02:19 Stefan Merten writes: > I just committed version 1.4.0 of rst.el. Here are the user visible > changes: In announcements like this, can you give the URL to this new release? -- \ “To have the choice between proprietary software packages, is | \ being able to choose your master. Freedom means not having a | _o__) master.” —Richard M. Stallman, 2007-05-16 | Ben Finney 
 [Docutils-develop] Version 1.4.0 of rst.el From: Stefan Merten - 2012-09-20 21:49:34 Attachments: Message as HTML Hi! I just committed version 1.4.0 of rst.el. Here are the user visible changes: Add support for imenu and which-func-mode. Remember setting which-func-modes for this feature to work. Automated calculations of section title faces replaced by defface. The latter replaces the calculated background colors of section titles by explicit defface\s. This may break existing customizations although these faces are not customizable really. I'm interested in feedback on this. This version - or may be a slightly refactored one - will be included in Emacs 24.3. This will replace a very old version of rst.el up to the Emacs 24.2 distribution. Grüße Stefan 
 [Docutils-develop] [ docutils-Bugs-3479594 ] rst.el: header faces don't handle light/dark bg properly From: SourceForge.net - 2012-09-20 21:12:50 Bugs item #3479594, was opened at 2012-01-25 04:54 Message generated for change (Settings changed) made by smerten You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3479594&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: emacs mode Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jakub Wilk (jakub-wilk) Assigned to: Stefan Merten (smerten) Summary: rst.el: header faces don't handle light/dark bg properly Initial Comment: I'm forwarding a bug reported by Samuel Bronson, orignally at ;: The header face background color initialization is based on the assumption that if frame-background-mode' is not dark', then the frame background color must be light. However, this variable is documented as follows: ,----[ C-h v frame-background-mode RET ] | frame-background-mode is a variable defined in faces.el'. | Its value is nil | | Documentation: | The brightness of the background. | Set this to the symbol dark' if your background color is dark, | light' if your background is light, or nil (automatic by default) | if you want Emacs to examine the brightness for you. Don't set this | variable with setq'; this won't have the expected effect. | | You can customize this variable. ---- Thus, if the value is nil, this variable tells us nothing about whether the background color is light or dark. In fact, it turns out that this can vary between frames within an Emacs session. The usual way of handling this is to use background' specs in the face definition, something like this: ,---- | (defface link-visited | '((default :inherit link) | (((class color) (background light)) :foreground "magenta4") | (((class color) (background dark)) :foreground "violet")) | "Basic face for visited links." | :group 'basic-faces | :version "22.1") ---- I would suggest replacing the affected options in the rst-faces-defaults' group with two options each, one for light backgrounds and one for dark backgrounds. One approach would be to allow each affected variable to accept a "(light . dark)" cons as an alternative to the single scalar it accepts now, and putting the defaults in this form rather than conditionalizing them. Note: the easiest way to see the problem is to try using the mode in a terminal which Emacs automatically identifies as having a dark background color, with frame-background-mode' at its default (nil) value. (Try PuTTY/pterm, for example.) ---------------------------------------------------------------------- >Comment By: Stefan Merten (smerten) Date: 2012-09-20 14:12 Message: Faces for section header titles are defined by defface. Fixed in version 1.4.0 of rst.el. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3479594&group_id=38414 
 Re: [Docutils-develop] emphasis/strong within literal_block? From: Kirill Smelkov - 2012-09-20 11:31:32 Hello, On Tue, Dec 24, 2002 at 04:44:20PM -0500, David Goodger wrote: > [Benja Fallenstein] > >> IIRC parsed-literal is a directive, so, > >> > >> .. parsed-literal:: > >> > > [Bill Bumgarner] > > Right. Got it. That works great. > > > > But it looks ugly-- it is the first intrusive formatting command I have > > had to include in the documents. Feature request; maybe if a > > paragraph ends in :;, the following block is a parsed literal as > > opposed to a literal block? > > Adding ";;" as syntax is already a "to do?" item (search > ; for 'Syntax for the "line-block" > directive?'). ":;" is equivalent; I can see advantages and disadvantages. > > Such syntax would be a minor enhancement (or wart, depending on tolerance > levels). If you want it, a patch is the best way to get it. Building > consensus is also required. You've got to push for it. Just a FYI: I needed it and implemented a patch for it using ::~ suffix. The patch is here: https://sourceforge.net/tracker/?func=detail&aid=3570019&group_id=38414&atid=422032 Attaching it to mail, just in case. Thanks, Kirill ---- 8< ---- From: Kirill Smelkov Date: Thu, 20 Sep 2012 15:06:44 +0400 Subject: [PATCH] rst: Add support for inline parsed-literals via ::~ postfix Just like with :: let's have ::~ to start a parsed-literal block, e.g. like this A paragraph::~ Alpha *beta* gamma Q which is equivalent to A paragraph: .. parsed-literal:: Alpha *beta* gamma Q P.S. The patch was not thoroughly written, because based on earlier experience, I suspect the probability of its inclusion is low. Still imho it's good to have at least as a demo. --- docutils/docutils/parsers/rst/states.py | 32 ++++++++++++-------- .../test_parsers/test_rst/test_literal_blocks.py | 35 ++++++++++++++++++++++ 2 files changed, 55 insertions(+), 12 deletions(-) diff --git a/docutils/docutils/parsers/rst/states.py b/docutils/docutils/parsers/rst/states.py index 0905ab7..9f1a742 100644 --- a/docutils/docutils/parsers/rst/states.py +++ b/docutils/docutils/parsers/rst/states.py @@ -408,14 +408,16 @@ class RSTState(StateWS): Return a list (paragraph & messages) & a boolean: literal_block next? """ data = '\n'.join(lines).rstrip() - if re.search(r'(? + + A paragraph: + + Alpha *beta* gamma + Q +"""], +["""\ +A paragraph::~ + + Alpha *beta* gamma + Q +""", +"""\ + + + A paragraph: + + Alpha \n\ + + beta + gamma + Q +"""], +] + + if __name__ == '__main__': import unittest unittest.main(defaultTest='suite') -- 1.7.12.1.510.g5dd77d8 
 [Docutils-develop] [ docutils-Patches-3570019 ] Inline parsed literals via ::~ From: SourceForge.net - 2012-09-20 11:11:34 Patches item #3570019, was opened at 2012-09-20 04:11 Message generated for change (Tracker Item Submitted) made by kirr79 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422032&aid=3570019&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: Kirill Smelkov (kirr79) Assigned to: Nobody/Anonymous (nobody) Summary: Inline parsed literals via ::~ Initial Comment: rst: Add support for inline parsed-literals via ::~ postfix Just like with :: let's have ::~ to start a parsed-literal block, e.g. like this A paragraph::~ Alpha *beta* gamma Q which is equivalent to A paragraph: .. parsed-literal:: Alpha *beta* gamma Q P.S. The patch was not thoroughly written, because based on earlier experience, I suspect the probability of its inclusion is low. Still imho it's good to have at least as a demo. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422032&aid=3570019&group_id=38414 
 [Docutils-develop] [ docutils-Feature Requests-3567688 ] I want to use strikethrough text From: SourceForge.net - 2012-09-16 22:35:27 Feature Requests item #3567688, was opened at 2012-09-14 03:34 Message generated for change (Comment added) made by milde You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422033&aid=3567688&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: Remind >Priority: 2 Private: No Submitted By: togakushi (togakushi) Assigned to: Nobody/Anonymous (nobody) Summary: I want to use strikethrough text Initial Comment: Please implement the markup of strikethrough text to use many by a business scene. For example, I sandwich it in a Hyphen-minus like textile. Example:: I like -textile- reStructuredText. STRIKE or DEL of html tag, or style sheet(text-decoration: line-through) ... ---------------------------------------------------------------------- >Comment By: Günter Milde (milde) Date: 2012-09-16 15:35 Message: Strikethrough markup is already possible with a custom role and style sheet:: .. role:: del I like :del:muffins apples. would create muffins in HTML and \DUrole[del]{muffins} in LaTeX. Special markup for strikethrough text is rather unlikely to be accepted to the reST syntax. For simpler markup, you may consider setting the default role. http://docutils.sourceforge.net/docs/ref/rst/directives.html#setting-the-default-interpreted-text-role Alternatively, you may consider the combining Unicode characters for strikethrough in the source (will only work with xetex, not with pdftex). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422033&aid=3567688&group_id=38414 
 [Docutils-develop] [ docutils-Bugs-3540052 ] Please add an option to specify path to MathJax.js From: SourceForge.net - 2012-09-16 11:14:41 Bugs item #3540052, was opened at 2012-07-03 22:58 Message generated for change (Comment added) made by mandriver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3540052&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: HTML writer Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dmitry Shachnev (mandriver) Assigned to: Nobody/Anonymous (nobody) Summary: Please add an option to specify path to MathJax.js Initial Comment: Please add a configuration option to specify path to MathJax.js which is used for math processing. For example, in Debian we have MathJax packaged and some users may want to use the local version (file:///usr/share/javascript/mathjax/MathJax.js) instead of the web one. Having such an option will also make it possible to view docutils-generated HTML files without an internet connection. See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677929 for Debian bug report. ---------------------------------------------------------------------- >Comment By: Dmitry Shachnev (mandriver) Date: 2012-09-16 04:14 Message: See also http://article.gmane.org/gmane.text.docutils.devel/6227. ---------------------------------------------------------------------- Comment By: Dmitry Shachnev (mandriver) Date: 2012-09-02 02:44 Message: Quoting the TODO from writers/html4css1/__init__.py: # TODO: make this configurable: # # a) as extra option or # b) appended to math-output="MathJax"? # # If b), which delimiter/delimter-set (':', ',', ' ')? I've chosen b), and there's no check for delimiter: it reads 'MathJax', then any symbol, and then the URL. Please find the patch attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3540052&group_id=38414 
 [Docutils-develop] [ docutils-Feature Requests-3567688 ] I want to use strikethrough text From: SourceForge.net - 2012-09-14 10:34:13 Feature Requests item #3567688, was opened at 2012-09-14 03:34 Message generated for change (Tracker Item Submitted) made by togakushi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422033&aid=3567688&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: togakushi (togakushi) Assigned to: Nobody/Anonymous (nobody) Summary: I want to use strikethrough text Initial Comment: Please implement the markup of strikethrough text to use many by a business scene. For example, I sandwich it in a Hyphen-minus like textile. Example:: I like -textile- reStructuredText. STRIKE or DEL of html tag, or style sheet(text-decoration: line-through) ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422033&aid=3567688&group_id=38414 
 [Docutils-develop] Configuring MathJax URL From: Dmitry Shachnev - 2012-09-08 13:22:46 Attachments: signature.asc [ I'm not subscribed to this list, so please CC me when you reply. ] Hi everybody! I've written a small patch that adds an ability to configure URL of MathJax JS file. The configuration is done by appending the URL to value of "math_output" setting. When nothing is appended, the default URL is used. The "MathJax" word (which can be lowercase) and the URL can be separated by a space or any other character. Having such an option will make it possible to view docutils-generated HTML files without an internet connection. Examples: 1. math_output = MathJax file:///usr/share/javascript/mathjax/MathJax.js 2. math_output = MathJax,https://c328740.ssl.cf1.rackcdn.com/mathjax/latest/MathJax.js My patch can be found at: http://sourceforge.net/tracker/index.php?func=detail&aid=3540052&group_id=38414&atid=422030. See also http://bugs.debian.org/677929 for the corresponding bug report in Debian. Can you please apply my patch or let me know if there's something wrong with it? Cheers, -- Dmitry Shachnev 
 Re: [Docutils-develop] NoTex - ReStructured Text Editor From: Guenter Milde - 2012-09-07 20:24:34 On 2012-09-05, Hasan Karahan wrote: > [-- Type: text/plain, Encoding: --] > Dear Docutils Maintainer, > I wrote a GPLv3 browser based editor for restructured text (see > https://notex.ch) with PDF/HTML/LaTex export functionality (based on Sphinx > & Texlive) and would like it to be included into > http://docutils.sourceforge.net/docs/user/links.html. Is that possible? > It's open source and the code is available at http://github.com/hsk81/notex. > I thought maybe in the "Editors" section, something like: > - NoTex ; is a browser based restructured text editor > with syntax highlighting and PDF/HTML export functionality. Done. Thanks for the link. Günter 
 Re: [Docutils-develop] New role idea: definition term From: Guenter Milde - 2012-09-07 08:36:22 On 2012-09-07, Michał Górny wrote: > On Thu, 6 Sep 2012 23:37:25 +0000 (UTC) > Guenter Milde wrote: >> On 2012-09-05, Michał Górny wrote: >> > On Wed, 5 Sep 2012 12:32:34 +0000 (UTC) >> Dear Michał, ... >> > means nothing to a standards-compliant >> >HTML >> > browser. On the other hand, has a pre-defined meaning which >> > can be used by a more advanced HTML parsing engine to achieve some >> > goal. >> Agreed. However, my argument was about the reStructuredText source >> but the response concerns the HTML output. >> But also this is theory: Is there an example of a parsing engine that >> makes use of the tag beyond "meaningless styling"? > You mean like voice browsers? Well, one could consider that meaningless > styling as well. I mean in order to convince me that adding Docutils support for the HTML tag, you should show me a real usage example that * fails with * works with and would gain from standards-complient semantic markup in Docutils generated HTML. >> a) Add a pre-defined :definition: role to rst syntax? >> +1 easy to map to the HTML element >> +1 precedence: the (undocumented) acronym and abbreviation roles >> +1 the existence of a pre-defined role may encourage people to >> actually do proper semantic markup of definition terms (did this work >> in HTML?). >> -1 one more special markup to document and remember. > Special markup? I think I fail to understand. I mean specific as opposed to generic. There are two cases of semantic markup in most markup languages: a) a core of specific, pre-defined roles/tags/elements like \emph \section \figure # LaTeX ? # HTML * * ======== .. figure:: # reST +1 consistent, standardized meaning -1 restricted -1 canges to the role/tag/element set require changes to the language core b) a means to define local exensions, like \newcommand \newenvironment # LaTeX class="..." # HTML .. role:: # reST .. :: # reST :class: ... +1 flexibility -1 requires additional conventions or other means to carry the meaning. >> -1 Should it be called "definition" or "dfn". >> -2 Proliferation: Why "definition" but not ... > Well, I don't mind looking at other elements which could be added at > the same time. For Docutils, I prefer a small core set of specific roles as base for local hierarchies of semantic markup. >> The existence of a matching tag in one of the supported output >> formats is a hint that this may be worth considering. The >> non-existence in all other output formats should be considered, >> too. > Docbook has it too. Well, it has clear, separate > and for further occurrences. Currently, Docbook is not supported by the Docutils core. (It should be possible to add either a Docbook writer or an XSLT stylesheet for this task.) With added Docbook support: would you now also propose :firstterm: and :glossterm: rules? As replacement for :dfn: or in additon to it? And how about the \index LaTeX macro? >> c) let Docutils generate tags for definition terms HTML output? >> +1 The html writer could transform , >> , , and/or >> to a html tag. >> -1 Another special case to document. > Is is possible to define a custom rule with a custom HTML element? I've > seen the docs mentioning raw-html but if I understand it right, it > transforms the whole block to raw HTML. But from this thread, I start > to see that there are more hidden features than I've seen already. Roles based on "raw" insert the content (inline content, not a block) as-is. This makes:: .. role:: definition(raw) :format: html a :definition:poor alternative. My suggestion would require a change to the HTML writer, either locally (in a custom wrapper script (myrst2html.py, say) or in the Docutils core adding a special case for inline nodes with 'definition' in node.class in the visit_inline() and depart_inline (and other concerned) functions. Günter 
 Re: [Docutils-develop] New role idea: definition term From: Michał Górny - 2012-09-07 07:28:35 Attachments: signature.asc On Thu, 6 Sep 2012 23:37:25 +0000 (UTC) Guenter Milde wrote: > On 2012-09-05, Michał Górny wrote: > > On Wed, 5 Sep 2012 12:32:34 +0000 (UTC) > > Guenter Milde wrote: > >> On 2012-09-03, Michał Górny wrote: > >> > On Mon, 3 Sep 2012 21:27:00 +0000 (UTC) > >> > Guenter Milde wrote: > > > Dear Michał, > > I understand your concerns about the semantic correctness of the HTML > output. I strongly support the concept of semantic markup of a > document source. > > When discussing markup of definition terms with reStructuredText, the > following 3 domains should be considered separately (but not > completely independent): > > a) reStructuredText syntax > b) the Doctutils document model > c) HTML output (and other output formats) > > > The following is a classical example of misunderstanding: > > >> >> What is the benefit of a pre-defined role over a custom one? > >> >> Does it outwight the added complexity? > > >> > Semantic correctness. > > >> Semantic markup is a primary use case for custom roles. Define and > >> use the roles that suit the needs of the document, for example:: > > >> .. role:: definition > >> .. role:: trademark > >> .. role:: informal > > >> Viewing online content with an :acronym:HTML viewer like > >> :trademark:firefox is called :definition:browsing or > >> :informal:surfing. > > >> I don't think that pre-defined roles are "more correct" than custom > >> ones. > > > means nothing to a standards-compliant > >HTML > > browser. On the other hand, has a pre-defined meaning which > > can be used by a more advanced HTML parsing engine to achieve some > > goal. > > Agreed. However, my argument was about the reStructuredText source > but the response concerns the HTML output. > > But also this is theory: Is there an example of a parsing engine that > makes use of the tag beyond "meaningless styling"? You mean like voice browsers? Well, one could consider that meaningless styling as well. > > > Shortly saying, is as meaningful as no tag. So what's the > > point of defining it? Except for the fact that you can add > > *meaningless* styling with CSS. > > A generic markup tag makes it possible to add "local semantic markup" > to the markup constructs provided by the language core. Basing the > extension on the standard markup provides "graceful degradation", e.g. > > .. role:: definition(emphasis) > > would present the definition term in a commonly used form without need > for a custom CSS style sheet but add the special meaning to the source > and the document tree. A matching XSLT stylesheet could be used to > extract the meaning from the Docutils XML or (X)HTML output. > > ... > > > >> Imagine the problems it would make to add a new element and markup > >> tag to HTML. Also imagine the problems it makes to remove an > >> element and markup tag from the specification of a formal language. > > > You mean like HTML5? > ... > > No, I meant the discussion and work and documentation requirements > involved in going from one version to the next. I wanted to make > clear that adding a pre-defined role is not a "quick fix" and requires > discussion and careful consideration. And why it is a work that may > overstretch the limited ressources available for Docutils development. > > >> This is why I prefer the flexible and simple way to extend the set > >> of semantic markup roles: the "role" directive. > > > It's not semantic. Unless you add a post-processor which would > > actually transform it into something meaningful. > > Using roles results in semantic markup in the rst source whether these > are pre-defined or custom roles. And yes, the output could be > post-processed to extract the meaning of the semantic markup. > However, the most common use case is still presentation which works > out of the box. > > The Docutils FAQ (not written by me) puts it so: > > HTML is being used for dumb formatting for nothing but final > display. A stylesheet is required, and one is provided; > > -- > http://docutils.sourceforge.net/FAQ.html#unexpected-results-from-tools-rst2html-py-h1-h1-instead-of-h1-h2-why > > > Summary: > > a) Add a pre-defined :definition: role to rst syntax? > > +1 easy to map to the HTML element > > +1 precedence: the (undocumented) acronym and abbreviation roles > > +1 the existence of a pre-defined role may encourage people to > actually do proper semantic markup of definition terms (did this work > in HTML?). > -1 one more special markup to document and remember. Special markup? I think I fail to understand. > -1 Should it be called "definition" or "dfn". > > -2 Proliferation: Why "definition" but not ... Well, I don't mind looking at other elements which could be added at the same time. > The existence of a matching tag in one of the supported output > formats is a hint that this may be worth considering. The > non-existence in all other output formats should be considered, > too. Docbook has it too. Well, it has clear, separate and for further occurrences. > c) let Docutils generate tags for definition terms HTML output? > > +1 The html writer could transform , > , , and/or > to a html tag. > > -1 Another special case to document. Is is possible to define a custom rule with a custom HTML element? I've seen the docs mentioning raw-html but if I understand it right, it transforms the whole block to raw HTML. But from this thread, I start to see that there are more hidden features than I've seen already. -- Best regards, Michał Górny 
 Re: [Docutils-develop] New role idea: definition term From: Guenter Milde - 2012-09-06 23:37:49 On 2012-09-05, Michał Górny wrote: > On Wed, 5 Sep 2012 12:32:34 +0000 (UTC) > Guenter Milde wrote: >> On 2012-09-03, Michał Górny wrote: >> > On Mon, 3 Sep 2012 21:27:00 +0000 (UTC) >> > Guenter Milde wrote: Dear Michał, I understand your concerns about the semantic correctness of the HTML output. I strongly support the concept of semantic markup of a document source. When discussing markup of definition terms with reStructuredText, the following 3 domains should be considered separately (but not completely independent): a) reStructuredText syntax b) the Doctutils document model c) HTML output (and other output formats) The following is a classical example of misunderstanding: >> >> What is the benefit of a pre-defined role over a custom one? >> >> Does it outwight the added complexity? >> > Semantic correctness. >> Semantic markup is a primary use case for custom roles. Define and use >> the roles that suit the needs of the document, for example:: >> .. role:: definition >> .. role:: trademark >> .. role:: informal >> Viewing online content with an :acronym:HTML viewer like >> :trademark:firefox is called :definition:browsing or >> :informal:surfing. >> I don't think that pre-defined roles are "more correct" than custom >> ones. > means nothing to a standards-compliant HTML > browser. On the other hand, has a pre-defined meaning which can > be used by a more advanced HTML parsing engine to achieve some goal. Agreed. However, my argument was about the reStructuredText source but the response concerns the HTML output. But also this is theory: Is there an example of a parsing engine that makes use of the tag beyond "meaningless styling"? > Shortly saying, is as meaningful as no tag. So what's the point > of defining it? Except for the fact that you can add *meaningless* > styling with CSS. A generic markup tag makes it possible to add "local semantic markup" to the markup constructs provided by the language core. Basing the extension on the standard markup provides "graceful degradation", e.g. .. role:: definition(emphasis) would present the definition term in a commonly used form without need for a custom CSS style sheet but add the special meaning to the source and the document tree. A matching XSLT stylesheet could be used to extract the meaning from the Docutils XML or (X)HTML output. ... >> Imagine the problems it would make to add a new element and markup >> tag to HTML. Also imagine the problems it makes to remove an element >> and markup tag from the specification of a formal language. > You mean like HTML5? ... No, I meant the discussion and work and documentation requirements involved in going from one version to the next. I wanted to make clear that adding a pre-defined role is not a "quick fix" and requires discussion and careful consideration. And why it is a work that may overstretch the limited ressources available for Docutils development. >> This is why I prefer the flexible and simple way to extend the set of >> semantic markup roles: the "role" directive. > It's not semantic. Unless you add a post-processor which would actually > transform it into something meaningful. Using roles results in semantic markup in the rst source whether these are pre-defined or custom roles. And yes, the output could be post-processed to extract the meaning of the semantic markup. However, the most common use case is still presentation which works out of the box. The Docutils FAQ (not written by me) puts it so: HTML is being used for dumb formatting for nothing but final display. A stylesheet is required, and one is provided; -- http://docutils.sourceforge.net/FAQ.html#unexpected-results-from-tools-rst2html-py-h1-h1-instead-of-h1-h2-why Summary: a) Add a pre-defined :definition: role to rst syntax? +1 easy to map to the HTML element +1 precedence: the (undocumented) acronym and abbreviation roles +1 the existence of a pre-defined role may encourage people to actually do proper semantic markup of definition terms (did this work in HTML?). -1 one more special markup to document and remember. -1 Should it be called "definition" or "dfn". -2 Proliferation: Why "definition" but not ... The existence of a matching tag in one of the supported output formats is a hint that this may be worth considering. The non-existence in all other output formats should be considered, too. The non-existence of the role in reStructuredText may be the result of careful consideration and not neglect. After all, the HTML tag existed before the development of reStructuredText by David Godger. b) Add a "definition" element to the Docutils document model and a "definition" node class to nodes.py -2 Proliferation. -2 Update required for all writers (writers must handle all existing node classes). Using is the safe alternative, using provides for graceful degradation. c) let Docutils generate tags for definition terms HTML output? +1 The html writer could transform , , , and/or to a html tag. -1 Another special case to document. Günter 
 Re: [Docutils-develop] New role idea: definition term From: engelbert gruber - 2012-09-06 07:27:09 On Wed, Sep 5, 2012 at 5:09 PM, Michał Górny wrote: > On Wed, 5 Sep 2012 12:32:34 +0000 (UTC) > Guenter Milde wrote: > >> On 2012-09-03, Michał Górny wrote: >> >> > [-- Type: text/plain, Encoding: quoted-printable --] >> >> > On Mon, 3 Sep 2012 21:27:00 +0000 (UTC) >> > Guenter Milde wrote: >> >> >> What is the benefit of a pre-defined role over a custom one? >> >> Does it outwight the added complexity? >> >> > Semantic correctness. >> >> Semantic markup is a primary use case for custom roles. Define and use >> the roles that suit the needs of the document, for example:: >> >> .. role:: definition >> .. role:: trademark >> .. role:: informal >> >> Viewing online content with an :acronym:HTML viewer like >> :trademark:firefox is called :definition:browsing or >> :informal:surfing. >> >> I don't think that pre-defined roles are "more correct" than custom >> ones. > > means nothing to a standards-compliant HTML > browser. On the other hand, has a pre-defined meaning which can > be used by a more advanced HTML parsing engine to achieve some goal. > > Shortly saying, is as meaningful as no tag. So what's the point > of defining it? Except for the fact that you can add *meaningless* > styling with CSS. > >> I see that one of the potentially unlimited number of output formats >> (HTML) uses a special element for one of the unlimited number of >> possible semantic markup roles (definition term). But I don't think >> it is "more correct" to force this special treatment on all other >> formats (reST + all other output formats) for this reason. > > Theory. We could also use images instead of text because just few of > the potentially unlimited ways of displaying text use ASCII coding. > > So, if you decide to add a plain-text output format, will you remove > all metadata which couldn't be represented as plain text? Because of > many output formats (images, plain-text, sculptures...) only a few > carry metadata... > >> >> Adding a new node class to the DTD_ would require a change to all >> >> (also user-contributed) writers and possibly break applications >> >> like Sphinx. (A backwards compatible way would be to pre-define a >> >> "definition" role that maps to an "inline" element with >> >> class="definition" in the document-tree and to add a special case >> >> in the HTML writer's visit_inline() function to map > >> class="definition"> to .) >> >> > Ouch. No offense but I think that if adding such a thing will cause >> > damage that severe (esp. regarding Sphinx), something is probably >> > designed wrong. Or with not enough consideration for future >> > extension, to be more correct. >> >> Both, the reST syntax and the Docutils document model are formally >> specified and users and applications rely on the stability of these >> definitions. > > Document model which cannot be extended is a dead document model. In > other words, it has no future. everything and body will die, i was told. >> Imagine the problems it would make to add a new element and markup >> tag to HTML. Also imagine the problems it makes to remove an element >> and markup tag from the specification of a formal language. > > You mean like HTML5? Yes, it had a few important problems. Most notably > I recall Internet Explorer 6 which weren't able to style unknown > elements with CSS. probably he meant sgml, html1, html2, html3, html4, html5 (where would you put xml, xhtml) they all have no future in your wording, they have limitations in mine. > But these problems were solved long ago. Using versioning, using > namespaces... sorry , long ago is not so long as to have passed my way. >> This is why I prefer the flexible and simple way to extend the set of >> semantic markup roles: the "role" directive. > > It's not semantic. Unless you add a post-processor which would actually > transform it into something meaningful. but reST for sure is not a easy-to-type-html-preprocessor-that-follows-at-the-heels there is semantic/word meaning that is not translatable into html-tags what then, isn't it ? what then ... all the best engelbert 
 Re: [Docutils-develop] New role idea: definition term From: Michał Górny - 2012-09-05 15:08:15 Attachments: signature.asc On Wed, 5 Sep 2012 12:32:34 +0000 (UTC) Guenter Milde wrote: > On 2012-09-03, Michał Górny wrote: > > > [-- Type: text/plain, Encoding: quoted-printable --] > > > On Mon, 3 Sep 2012 21:27:00 +0000 (UTC) > > Guenter Milde wrote: > > >> What is the benefit of a pre-defined role over a custom one? > >> Does it outwight the added complexity? > > > Semantic correctness. > > Semantic markup is a primary use case for custom roles. Define and use > the roles that suit the needs of the document, for example:: > > .. role:: definition > .. role:: trademark > .. role:: informal > > Viewing online content with an :acronym:HTML viewer like > :trademark:firefox is called :definition:browsing or > :informal:surfing. > > I don't think that pre-defined roles are "more correct" than custom > ones. means nothing to a standards-compliant HTML browser. On the other hand, has a pre-defined meaning which can be used by a more advanced HTML parsing engine to achieve some goal. Shortly saying, is as meaningful as no tag. So what's the point of defining it? Except for the fact that you can add *meaningless* styling with CSS. > I see that one of the potentially unlimited number of output formats > (HTML) uses a special element for one of the unlimited number of > possible semantic markup roles (definition term). But I don't think > it is "more correct" to force this special treatment on all other > formats (reST + all other output formats) for this reason. Theory. We could also use images instead of text because just few of the potentially unlimited ways of displaying text use ASCII coding. So, if you decide to add a plain-text output format, will you remove all metadata which couldn't be represented as plain text? Because of many output formats (images, plain-text, sculptures...) only a few carry metadata... > >> Adding a new node class to the DTD_ would require a change to all > >> (also user-contributed) writers and possibly break applications > >> like Sphinx. (A backwards compatible way would be to pre-define a > >> "definition" role that maps to an "inline" element with > >> class="definition" in the document-tree and to add a special case > >> in the HTML writer's visit_inline() function to map >> class="definition"> to .) > > > Ouch. No offense but I think that if adding such a thing will cause > > damage that severe (esp. regarding Sphinx), something is probably > > designed wrong. Or with not enough consideration for future > > extension, to be more correct. > > Both, the reST syntax and the Docutils document model are formally > specified and users and applications rely on the stability of these > definitions. Document model which cannot be extended is a dead document model. In other words, it has no future. > Imagine the problems it would make to add a new element and markup > tag to HTML. Also imagine the problems it makes to remove an element > and markup tag from the specification of a formal language. You mean like HTML5? Yes, it had a few important problems. Most notably I recall Internet Explorer 6 which weren't able to style unknown elements with CSS. But these problems were solved long ago. Using versioning, using namespaces... > This is why I prefer the flexible and simple way to extend the set of > semantic markup roles: the "role" directive. It's not semantic. Unless you add a post-processor which would actually transform it into something meaningful. -- Best regards, Michał Górny 
 Re: [Docutils-develop] New role idea: definition term From: Guenter Milde - 2012-09-05 12:32:59 On 2012-09-03, Michał Górny wrote: > [-- Type: text/plain, Encoding: quoted-printable --] > On Mon, 3 Sep 2012 21:27:00 +0000 (UTC) > Guenter Milde wrote: >> What is the benefit of a pre-defined role over a custom one? >> Does it outwight the added complexity? > Semantic correctness. Semantic markup is a primary use case for custom roles. Define and use the roles that suit the needs of the document, for example:: .. role:: definition .. role:: trademark .. role:: informal Viewing online content with an :acronym:HTML viewer like :trademark:firefox is called :definition:browsing or :informal:surfing. I don't think that pre-defined roles are "more correct" than custom ones. I see that one of the potentially unlimited number of output formats (HTML) uses a special element for one of the unlimited number of possible semantic markup roles (definition term). But I don't think it is "more correct" to force this special treatment on all other formats (reST + all other output formats) for this reason. >> How would this translate to other output formats (LaTeX, manpage, >> ODF, ...)? > I believe that there are people who can answer that better than I do. > In any case, if no semantically correct solution is available, I think > it should fallback to italic (and italic, not emphasis). >> Adding a new node class to the DTD_ would require a change to all >> (also user-contributed) writers and possibly break applications like >> Sphinx. (A backwards compatible way would be to pre-define a >> "definition" role that maps to an "inline" element with >> class="definition" in the document-tree and to add a special case in >> the HTML writer's visit_inline() function to map > class="definition"> to .) > Ouch. No offense but I think that if adding such a thing will cause > damage that severe (esp. regarding Sphinx), something is probably > designed wrong. Or with not enough consideration for future extension, > to be more correct. Both, the reST syntax and the Docutils document model are formally specified and users and applications rely on the stability of these definitions. Imagine the problems it would make to add a new element and markup tag to HTML. Also imagine the problems it makes to remove an element and markup tag from the specification of a formal language. This is why I prefer the flexible and simple way to extend the set of semantic markup roles: the "role" directive. Günter 
 [Docutils-develop] NoTex - ReStructured Text Editor From: Hasan Karahan - 2012-09-05 05:36:16 Attachments: Message as HTML Dear Docutils Maintainer, I wrote a GPLv3 browser based editor for restructured text (see https://notex.ch) with PDF/HTML/LaTex export functionality (based on Sphinx & Texlive) and would like it to be included into http://docutils.sourceforge.net/docs/user/links.html. Is that possible? It's open source and the code is available at http://github.com/hsk81/notex. I thought maybe in the "Editors" section, something like: - NoTex ; is a browser based restructured text editor with syntax highlighting and PDF/HTML export functionality. Sincerely, Hasan Karahan. 
 Re: [Docutils-develop] New role idea: definition term From: Michał Górny - 2012-09-03 22:02:25 Attachments: signature.asc On Mon, 3 Sep 2012 21:27:00 +0000 (UTC) Guenter Milde wrote: > >> Unless there is a strong indication of real benefits in real use > >> cases, it is unlikely to become a pre-defined role. > > > Like scientific papers, articles, tutorials and so on? > > I understand that there are cases where semantic markup with a > :definition:something role makes sense. > > However: > > What is the benefit of a pre-defined role over a custom one? > Does it outwight the added complexity? Semantic correctness. > How would this translate to other output formats (LaTeX, manpage, > ODF, ...)? I believe that there are people who can answer that better than I do. In any case, if no semantically correct solution is available, I think it should fallback to italic (and italic, not emphasis). > IMV, there are more important weaknesses regarding scientific papers > (citation handling, formal tables and images (with numbering and > auto-generated listing of all tables/images), better footnote > handling, ...). Well, I was more referring to articles, where the mentioned things are not *that* important. On the other hand, I wouldn't mind them being implemented ;). > Adding a new node class to the DTD_ would require a change to all > (also user-contributed) writers and possibly break applications like > Sphinx. (A backwards compatible way would be to pre-define a > "definition" role that maps to an "inline" element with > class="definition" in the document-tree and to add a special case in > the HTML writer's visit_inline() function to map class="definition"> to .) Ouch. No offense but I think that if adding such a thing will cause damage that severe (esp. regarding Sphinx), something is probably designed wrong. Or with not enough consideration for future extension, to be more correct. -- Best regards, Michał Górny 

Showing results of 36

1 2 > >> (Page 1 of 2)