## 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 (42) Oct (9) Nov Dec (7) Jan (6) Feb (15) Mar (7) Apr May (33) Jun (3) Jul (19) Aug (12) Sep (6) Oct (16) Nov (17) Dec (125) Jan (66) Feb (98) Mar (29) Apr (32) May (63) Jun (98) Jul (26) Aug (33) Sep (9) Oct Nov Dec
S M T W T F S

1

2
(3)
3

4

5
(5)
6

7

8

9

10

11
(8)
12

13

14

15
(9)
16

17

18

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

26

27

28
(1)
29

30

Showing results of 37

1 2 > >> (Page 1 of 2)
 [Docutils-develop] [ docutils-Patches-3587533 ] latex2e: Handle classes for bullet & field lists From: SourceForge.net - 2012-11-28 10:11:57 Patches item #3587533, was opened at 2012-11-15 07:22 Message generated for change (Settings changed) made by kirr79 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422032&aid=3587533&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: latex2e: Handle classes for bullet & field lists Initial Comment: latex2e: Handle classes for bullet lists For example authors could customize documents as follows: .. class:: compact - item 1 - item 2 - item 3 and expect the writer to apply the class. This works for html writer, but not yet for latex2e/xetex and that's why this patch is here. Usual rules for customizing rendering for classed elements is done - for class compact, if stylesheet provides an environment named DUitemizecompact, it will be used, otherwise the default itemize. Personally, for compact lists I use \newenvironment{DUitemizecompact}{% \begingroup% \small% \begin{itemize}% \itemsep=0pt\parskip=0pt% }{% \end{itemize}% \endgroup% } which make text a bit smaller and tightens inter-line gaps. NOTES: * There is no \provideenvironment in LaTeX, so plain \newenviroment is used. * The implementation of DUitemize environment is a bit cumbersome. That's because it is not possible to pass arguments to end when defining environments and because my TeX foo is probably not high enough. (help appreciated) * I've patched the code to emit \begin{DUitemize} only when classes attrubute is present - only to minimize changes to tests, for the patch not being huge with low signal/noise ratio. ---------------------------------------------------------------------- Comment By: Kirill Smelkov (kirr79) Date: 2012-11-20 08:45 Message: Uploaded cleaned up patch and demo. ---------------------------------------------------------------------- Comment By: Kirill Smelkov (kirr79) Date: 2012-11-15 08:41 Message: Simplified TeX preamble: PreambleCmds.itemize = r""" % bullet list \newenvironment{DUitemize}[1][class-arg]{% % store #1 for end \begingroup% \def\DUitemizearg{#1}% % \ifcsname DUitemize#1\endcsname% %\begin{DUitemize#1}% XXX why this does not work? \begin{DUitemize\DUitemizearg}% \else% \begin{itemize}% \fi% }{% \ifcsname endDUitemize\DUitemizearg\endcsname% \end{DUitemize\DUitemizearg}% \else% \end{itemize}% \fi% \endgroup% }% """ ---------------------------------------------------------------------- Comment By: Kirill Smelkov (kirr79) Date: 2012-11-15 07:24 Message: NOTE: The TeX part of the patch (DUitemize environmet) probably needs polish, but if otherwise in general this approach is correct, I'd like to add more class handling to latex2e backend - for example to field lists and other environments. Thanks beforehand for your reply, Kirill ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422032&aid=3587533&group_id=38414 
 Re: [Docutils-develop] Incompatible options for rst2pdf From: Stefan Merten - 2012-11-24 18:54:47 Attachments: application/pgp-signature createpdf.py.patch Hi Roberto! Last week (13 days ago) Roberto Alsina wrote: > On 11/11/2012 12:17 PM, Stefan Merten wrote: >> Ah, I think I found out. Robert Alsina seems to prefer to maintain an > > Roberto, not Robert, if you don't mind. I'm really sorry. I try to get names right but failed in this case. >> own project at http://rst2pdf.ralsina.com.ar/ which is not reflected >> in the sandbox. In this project the command line conventions do not >> follow the usual rst2* conventions and even collide with them. That is >> really, really bad. > > It's not that I prefer to maintain my own project. It just is a separate > project, that supported for a long time a lot of things > docutils didn't (for example: math, code blocks, plugins). > > Also, it's implemented completely differently from how docutils > implements writers, so it would have been a horrible fit for the > docutils codebase, and would probably, according to what I have seen, > never been accepted into docutils, which is just fine by me, too. Well, there is the sandbox in the docutils repository. AFAICS there are not really limitations to put something there as long as it is related to Docutils. If the reportlab based rst2pdf would be there it would certainly be easier for Docutils hackers to help maintaining it. >> So I'm pretty much inclined to say: The behavior of rst.el conforms >> to the reStructuredText standards and thus should not be changed. >> Instead the external project should be fixed. > > Not going to happen, sorry. rst2pdf does what it does and has been doing > it for a long time, and I owe compatibility to the userbase :-) I don't think that compatibility is an issue here. See below. > Since AFAIK none of the rst2pdfs in the sandbox has ever been released, > you can probably assume that a rst2pdf you find in the path is my rst2pdf. Frankly I find this position a bit arrogant. >> A simple fix could be to make the -o/--output optional. > > You mean in rst2pdf? It *is* optional. Well, if it were I wouldn't get requests to support the -o/--output option in rst.el if reportlab based rst2pdf is used. AFAICS -o/--output outfile is optional but -o/--output is required if you want to give an output file. I may be missing something but I can't see a reason for that. I downloaded the code for the reportlab based rst2pdf. There is :: elif len(args) > 1: log.critical('Usage: %s file.txt [ -o file.pdf ]', sys.argv[0]) sys.exit(1) IOW: reportlab based rst2pdf does not support a second argument [1]_. .. [1] Really the error message is wrong. I corrected it in my patch. The standard syntax for rst2* is :: rst2* [options] [ []] So if the reportlab based rst2pdf would accept a second argument and use this as the output file everything would be fine. Since so far a second argument resulted in an error it would simply be an upward compatible extension and with it the reportlab based rst2pdf would comply to established Docutils standards. I attached patch to rst2pdf/createpdf.py from 0.92 which should do the trick. Unfortunately I found no way to run the tests of rst2pdf without a full blown installation. Thus I added no test and didn't run any. However, it's a simple patch and looks right to me. Grüße Stefan 
 Re: [Docutils-develop] [ docutils-Patches-3587533 ] latex2e: Handle classes for bullet lists From: Kirill Smelkov - 2012-11-23 10:05:59 On Thu, Nov 22, 2012 at 01:42:51PM +0000, Guenter Milde wrote: > On 2012-11-22, Kirill Smelkov wrote: > > On Wed, Nov 21, 2012 at 03:49:29PM +0000, Guenter Milde wrote: > > Dear Kirill, > > >> >> I agree that support for class arguments in LaTeX can/should be extended > >> >> to include more useful cases. Docutils already adds a mechanism with the > >> >> DUrole command, which could be employed here. > > >> >> Suggestion: handle class arguments for bullet lists similar to > >> >> block-quotes: > > >> >> +1 simple, > >> >> +1 applicable to other elements without inflating latex2e/__init__.py > >> >> nor the generated LaTeX source. > > >> ... > > >> > Thanks for thorough reply. However I feel that reusing DUrole for > >> > handling classes would be inflexible, because when DUrole is in > >> > effect we already are in an environment (itemize in your example) and in > >> > general case one may want to use different environments for different > >> > classes. That is not artificial - I've already had to use my own > >> > environment instead of description for customized fieldlists. > > >> This could be remedied by wrapping \DUrole around the environment:: > > >> \DUrole{compact}{ > >> \begin{itemize} > >> \item item 1 > > >> \item item 2 > > >> \item item 3 > >> \end{itemize} > >> } > > > Imho no, this won't work. > > ... > > > This is related to how latex environments work - either you set > > it's settings inside, or you should know the nesting level and set > > itemsep and parskip etc, which is not elegantly possible > > for general wrapper ... > > I recommend the very nice enumitem_ package for list customization. It's > comprehensive documentation reveals that the example problem could be > solved via "global settings" where the level-argument is optional :: > > \documentclass[]{article} > \usepackage{lmodern} > \usepackage[T1]{fontenc} > > \usepackage{enumitem} > > \begin{document} > > Compact: > > { > \setlist[itemize]{noitemsep} > \small% > \begin{itemize} > \item item 1 > \item item 2 > \end{itemize} > } > > Back to normal: > > \begin{itemize} > \item item 1 > \item item 2 > \end{itemize} > > \end{document} > > > .. _enumitem: > http://mirror.ctan.org/help/Catalogue/entries/enumitem.html > > > > Besides, we are hardcoding used environment in stone. > > Yes, if there is a matching standard environment (or macro), we are using > it. IMO this is "the right thing". It provides widely compatible, clean > LaTeX files and allows styling with the established LaTeX tools. > > A stylesheet can even save the original environment or macro to an alias > and overwrite the definition with a custom version. > > > I think the consensus here could be as follows: > > > 1. \DUenv[class] looks for \DUenvclass, and uses it if found. > > 2. if not, fallback environment is used (itemize for DUitemize) with > > your \DUclass[class] inside it (sorry, I've missed it in a hurry > > on the first read), e.g. > > ... > > > What do you think? > > -1 too complicated. > -1 inflating latex2e/__init__.py and the generated LaTeX source. > -1 custom macros are cumbersome when hand-editing the LaTeX source or > converting it to other source formats. > > > > ( And also, using DUrole for styling classes could come into confilict > > with using roles in the document itself, e.g. as in :compact:text ) > > It would be up to the user to ensure that "DUrole..." macros do not > interfere. Class arguments and custom styles are advanced stuff, so, IMO, > we are not demanding too much. > > Considering that "compact" is already established in the HTML writer, a > different name could be used for the role. In other cases, a class argument > like "compactlist" or similar can be used. > > Also mind, that, e.g. :: > > \newcommand{\DUrolesmall}[1]{% > {\setlist[itemize]{noitemsep}\small#1}% > } > > would work as expected in both, a "small" bullet-list and a > :small:role. > > > >> > I'm also proposing we next convert all direct usage of TeX environments > >> > to DUsomething classed dispatch step-by-step. > > >> This blows up the latex source and makes it hard to convert to anything > >> except DVI or PDF. (Think about import to LyX or OpenOffice, e.g.) as well > >> as working on Docutils-generated LaTeX source. > > > This blows up only preamble, which we are maybe better move to separate > > static file, and add an option for rst2latex to whether embed it or not > > into generated tex source, just like html writer does with > > --embed-stylesheet. > > This is a separate TODO item: Move the preamble code to a LaTeX package > (which should also be uploaded to CTAN) and provide an > "embed-stylesheet" setting with possible values: yes, no, and subset > (where subset is basically the current behaviour). > > > The document text itself is not blown up, and still remains structured. > > I see no problem importing it to anywhere, without embedded preamble. > > > Yes, importers should be taught about what used DUenv means, but we > > already have to do it, because for example we already use > > \begin{DUfieldlist} ... \end{DUfiledlist}. > > > I'd rather get rid of DUfieldlist... Dear Günter, Maybe you are right, but I think the consensus here is that we disagree. Maybe we have different tastes or whatever, I don't know. It's a pity, but I'm already used to the fact that my patches don't get in and only serve to start discussions. Hope they are somehow, at least, inderectly useful. Unfortunately my current situation does not allow me to spend time on discussions nor I see we are getting near to solutions which I would like. I will try to continue to give back via posting my occasional changes to sourceforge patch tracker. Thats all I can afford myself. > Thanks, > > Günter Thanks for maintaining Docutils, Kirill .--. .--. ._' |/ :.-, | '.-;-.; .' _:._/.'.'.'\.-. / \.'.'.'/ / '-._.;'-'-';---' , /> jgs / /| \'-. \\/( --' -.-' \|_.-' \ ' 
 Re: [Docutils-develop] [ docutils-Patches-3587533 ] latex2e: Handle classes for bullet lists From: Guenter Milde - 2012-11-22 13:43:16 On 2012-11-22, Kirill Smelkov wrote: > On Wed, Nov 21, 2012 at 03:49:29PM +0000, Guenter Milde wrote: Dear Kirill, >> >> I agree that support for class arguments in LaTeX can/should be extended >> >> to include more useful cases. Docutils already adds a mechanism with the >> >> DUrole command, which could be employed here. >> >> Suggestion: handle class arguments for bullet lists similar to >> >> block-quotes: >> >> +1 simple, >> >> +1 applicable to other elements without inflating latex2e/__init__.py >> >> nor the generated LaTeX source. >> ... >> > Thanks for thorough reply. However I feel that reusing DUrole for >> > handling classes would be inflexible, because when DUrole is in >> > effect we already are in an environment (itemize in your example) and in >> > general case one may want to use different environments for different >> > classes. That is not artificial - I've already had to use my own >> > environment instead of description for customized fieldlists. >> This could be remedied by wrapping \DUrole around the environment:: >> \DUrole{compact}{ >> \begin{itemize} >> \item item 1 >> \item item 2 >> \item item 3 >> \end{itemize} >> } > Imho no, this won't work. ... > This is related to how latex environments work - either you set > it's settings inside, or you should know the nesting level and set > itemsep and parskip etc, which is not elegantly possible > for general wrapper ... I recommend the very nice enumitem_ package for list customization. It's comprehensive documentation reveals that the example problem could be solved via "global settings" where the level-argument is optional :: \documentclass[]{article} \usepackage{lmodern} \usepackage[T1]{fontenc} \usepackage{enumitem} \begin{document} Compact: { \setlist[itemize]{noitemsep} \small% \begin{itemize} \item item 1 \item item 2 \end{itemize} } Back to normal: \begin{itemize} \item item 1 \item item 2 \end{itemize} \end{document} .. _enumitem: http://mirror.ctan.org/help/Catalogue/entries/enumitem.html > Besides, we are hardcoding used environment in stone. Yes, if there is a matching standard environment (or macro), we are using it. IMO this is "the right thing". It provides widely compatible, clean LaTeX files and allows styling with the established LaTeX tools. A stylesheet can even save the original environment or macro to an alias and overwrite the definition with a custom version. > I think the consensus here could be as follows: > 1. \DUenv[class] looks for \DUenvclass, and uses it if found. > 2. if not, fallback environment is used (itemize for DUitemize) with > your \DUclass[class] inside it (sorry, I've missed it in a hurry > on the first read), e.g. ... > What do you think? -1 too complicated. -1 inflating latex2e/__init__.py and the generated LaTeX source. -1 custom macros are cumbersome when hand-editing the LaTeX source or converting it to other source formats. > ( And also, using DUrole for styling classes could come into confilict > with using roles in the document itself, e.g. as in :compact:text ) It would be up to the user to ensure that "DUrole..." macros do not interfere. Class arguments and custom styles are advanced stuff, so, IMO, we are not demanding too much. Considering that "compact" is already established in the HTML writer, a different name could be used for the role. In other cases, a class argument like "compactlist" or similar can be used. Also mind, that, e.g. :: \newcommand{\DUrolesmall}[1]{% {\setlist[itemize]{noitemsep}\small#1}% } would work as expected in both, a "small" bullet-list and a :small:role. >> > I'm also proposing we next convert all direct usage of TeX environments >> > to DUsomething classed dispatch step-by-step. >> This blows up the latex source and makes it hard to convert to anything >> except DVI or PDF. (Think about import to LyX or OpenOffice, e.g.) as well >> as working on Docutils-generated LaTeX source. > This blows up only preamble, which we are maybe better move to separate > static file, and add an option for rst2latex to whether embed it or not > into generated tex source, just like html writer does with > --embed-stylesheet. This is a separate TODO item: Move the preamble code to a LaTeX package (which should also be uploaded to CTAN) and provide an "embed-stylesheet" setting with possible values: yes, no, and subset (where subset is basically the current behaviour). > The document text itself is not blown up, and still remains structured. > I see no problem importing it to anywhere, without embedded preamble. > Yes, importers should be taught about what used DUenv means, but we > already have to do it, because for example we already use > \begin{DUfieldlist} ... \end{DUfiledlist}. I'd rather get rid of DUfieldlist... Thanks, Günter 
 Re: [Docutils-develop] [ docutils-Patches-3587533 ] latex2e: Handle classes for bullet lists From: Kirill Smelkov - 2012-11-22 09:11:45 On Wed, Nov 21, 2012 at 03:49:29PM +0000, Guenter Milde wrote: > On 2012-11-20, Kirill Smelkov wrote: > > On Mon, Nov 19, 2012 at 10:24:12AM +0000, Guenter Milde wrote: > >> > Patches item #3587533 by kirr79 > >> > https://sourceforge.net/tracker/?func=detail&atid=422032&aid=3587533&group_id=38414 > > Dear Kirill, > > >> > For example authors could customize documents as follows: > > >> > .. class:: compact > > >> > - item 1 > >> > - item 2 > >> > - item 3 > > ... > > >> > This works for html writer, > >> > but not yet for latex2e/xetex and that's why this patch is here. > > >> I agree that support for class arguments in LaTeX can/should be extended > >> to include more useful cases. Docutils already adds a mechanism with the > >> DUrole command, which could be employed here. > > >> Suggestion: handle class arguments for bullet lists similar to block-quotes: > > >> +1 simple, > >> +1 applicable to other elements without inflating latex2e/__init__.py > >> nor the generated LaTeX source. > > ... > > >> > NOTES: > > >> * Instead of a new environment definition, the already established > >> mechanism and macro name for custom inline roles is re-used. > ... > >> * the definition of \DUrolecompact affects **all** elements with > >> the class argument "compact" (if the element is of a type where the > >> LaTeX writer supports class arguments). > > >> It may be more safe to define \DUrolecompact like :: > > >> \newcommand{\DUrolecompact}[1]{% > >> {\small% > >> \itemsep=0pt\parskip=0pt% > >> #1% > >> }% > >> } > > >> (untested). > > >> * Alternatively, one could consider a \DUclass macro without > >> argument for styling of environments:: > > >> PreambleCmds.class = r""" > >> % class arguments: \DUclass{#1} tries \DUclass#1 > >> \providecommand{\DUclass}[1]{% > >> \ifcsname DUclass#1\endcsname% > >> \csname DUclass#1\endcsname% > >> \fi% > >> }""" > > >> +1 simpler than \DUrole > >> -1 new name and function needs extra documentation > >> -1 more preamble code if both, inline elements and block elements > >> have class arguments. > > ... > > > Thanks for thorough reply. However I feel that reusing DUrole for > > handling classes would be inflexible, because when DUrole is in > > effect we already are in an environment (itemize in your example) and in > > general case one may want to use different environments for different > > classes. That is not artificial - I've already had to use my own > > environment instead of description for customized fieldlists. > > This could be remedied by wrapping \DUrole around the environment:: > > \DUrole{compact}{ > \begin{itemize} > \item item 1 > > \item item 2 > > \item item 3 > \end{itemize} > } Imho no, this won't work. For example in { \small% \itemsep=0pt\parskip=0pt% \begin{itemize} \item item 1 \item item 2 \item item 3 \end{itemize} } only \small takes the effect, and itemsep and parskip settings do not. This is related to how latex environments work - either you set it's settings inside, or you should know the nesting level and set itemsep and parskip etc, which is not elegantly possible for general wrapper ... Besides, we are hardcoding used environment in stone. I think the consensus here could be as follows: 1. \DUenv[class] looks for \DUenvclass, and uses it if found. 2. if not, fallback environment is used (itemize for DUitemize) with your \DUclass[class] inside it (sorry, I've missed it in a hurry on the first read), e.g. > * Alternatively, one could consider a \DUclass macro without > argument for styling of environments:: > > PreambleCmds.class = r""" > % class arguments > % \DUclass{#1} tries \DUrole#1 > \providecommand{\DUclass}[1]{% > \ifcsname DUclass#1\endcsname% > \csname DUclass#1\endcsname% > \fi% > }""" \begin{itemize} \DUclass[compact] \item ... \end{itemize} This way, if particular classed environment is provided by user stylesheet - all is in that environment control. If not, we still try to do styling via DUclass which definition is not duplicated for all environments. What do you think? ( And also, using DUrole for styling classes could come into confilict with using roles in the document itself, e.g. as in :compact:text ) > > Imho classed DUrole is good, but it should only complement classed > > environments, not replace them. The same for uniformity. > > ... > > > It is true that support for classes in writer is optional, but if that > > support is there it should be robust, uniform and flexible. And to me that > > means we should emit \DUsomething or \DUsomething[class] for something > > document elements. > > This is where I disagree: I do not like to have a lot of DUsomething > definitions in the latex document's preamble. see below. > > I'm also proposing we next convert all direct usage of TeX environments > > to DUsomething classed dispatch step-by-step. > > This blows up the latex source and makes it hard to convert to anything > except DVI or PDF. (Think about import to LyX or OpenOffice, e.g.) as well > as working on Docutils-generated LaTeX source. This blows up only preamble, which we are maybe better move to separate static file, and add an option for rst2latex to whether embed it or not into generated tex source, just like html writer does with --embed-stylesheet. The document text itself is not blown up, and still remains structured. I see no problem importing it to anywhere, without embedded pramble. Yes, importers should be taught about what used DUenv means, but we already have to do it, because for example we already use \begin{DUfieldlist} ... \end{DUfiledlist}. Thanks, Kirill 
 [Docutils-develop] [ docutils-Feature Requests-3588800 ] emacs mode to match rst2pdf syntax (for Ubuntu 12.04) From: SourceForge.net - 2012-11-21 19:06:50 Feature Requests item #3588800, was opened at 2012-11-20 12:59 Message generated for change (Comment added) made by smerten You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422033&aid=3588800&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: Pending Resolution: None Priority: 5 Private: No Submitted By: Eric W. Anderson (kluwak) >Assigned to: Stefan Merten (smerten) Summary: emacs mode to match rst2pdf syntax (for Ubuntu 12.04) Initial Comment: This patch is relative to the version of Docutils (0.8.1) and rst2pdf (0.16) present on Ubuntu 12.04. rst2pdf expects its output file to be indicated with a '-o' flag, but the emacs mode only knows how to produce commands of the form: command [options] [conffile] input_file output_file This patch adds an "out-options" record to allow: command [options] [conffile] input [out-options] output_file This may not be useful to anyone, since it looks like the current development version of rst.el has changed a lot since 0.8.1. That's OK with me. ---------------------------------------------------------------------- >Comment By: Stefan Merten (smerten) Date: 2012-11-21 11:06 Message: This is really a feature request to support the non-standard behavior of rst2pdf based on reportlab. In any case this needs further clarification. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422033&aid=3588800&group_id=38414 
 Re: [Docutils-develop] [ docutils-Patches-3587533 ] latex2e: Handle classes for bullet lists From: Guenter Milde - 2012-11-21 15:50:00 On 2012-11-20, Kirill Smelkov wrote: > On Mon, Nov 19, 2012 at 10:24:12AM +0000, Guenter Milde wrote: >> > Patches item #3587533 by kirr79 >> > https://sourceforge.net/tracker/?func=detail&atid=422032&aid=3587533&group_id=38414 Dear Kirill, >> > For example authors could customize documents as follows: >> > .. class:: compact >> > - item 1 >> > - item 2 >> > - item 3 ... >> > This works for html writer, >> > but not yet for latex2e/xetex and that's why this patch is here. >> I agree that support for class arguments in LaTeX can/should be extended >> to include more useful cases. Docutils already adds a mechanism with the >> DUrole command, which could be employed here. >> Suggestion: handle class arguments for bullet lists similar to block-quotes: >> +1 simple, >> +1 applicable to other elements without inflating latex2e/__init__.py >> nor the generated LaTeX source. ... >> > NOTES: >> * Instead of a new environment definition, the already established >> mechanism and macro name for custom inline roles is re-used. ... >> * the definition of \DUrolecompact affects **all** elements with >> the class argument "compact" (if the element is of a type where the >> LaTeX writer supports class arguments). >> It may be more safe to define \DUrolecompact like :: >> \newcommand{\DUrolecompact}[1]{% >> {\small% >> \itemsep=0pt\parskip=0pt% >> #1% >> }% >> } >> (untested). >> * Alternatively, one could consider a \DUclass macro without >> argument for styling of environments:: >> PreambleCmds.class = r""" >> % class arguments: \DUclass{#1} tries \DUclass#1 >> \providecommand{\DUclass}[1]{% >> \ifcsname DUclass#1\endcsname% >> \csname DUclass#1\endcsname% >> \fi% >> }""" >> +1 simpler than \DUrole >> -1 new name and function needs extra documentation >> -1 more preamble code if both, inline elements and block elements >> have class arguments. ... > Thanks for thorough reply. However I feel that reusing DUrole for > handling classes would be inflexible, because when DUrole is in > effect we already are in an environment (itemize in your example) and in > general case one may want to use different environments for different > classes. That is not artificial - I've already had to use my own > environment instead of description for customized fieldlists. This could be remedied by wrapping \DUrole around the environment:: \DUrole{compact}{ \begin{itemize} \item item 1 \item item 2 \item item 3 \end{itemize} } > Imho classed DUrole is good, but it should only complement classed > environments, not replace them. The same for uniformity. ... > It is true that support for classes in writer is optional, but if that > support is there it should be robust, uniform and flexible. And to me that > means we should emit \DUsomething or \DUsomething[class] for something > document elements. This is where I disagree: I do not like to have a lot of DUsomething definitions in the latex document's preamble. > I'm also proposing we next convert all direct usage of TeX environments > to DUsomething classed dispatch step-by-step. This blows up the latex source and makes it hard to convert to anything except DVI or PDF. (Think about import to LyX or OpenOffice, e.g.) as well as working on Docutils-generated LaTeX source. Günter 
 [Docutils-develop] [ docutils-Patches-3588800 ] emacs mode to match rst2pdf syntax (for Ubuntu 12.04) From: SourceForge.net - 2012-11-20 20:59:47 Patches item #3588800, was opened at 2012-11-20 12:59 Message generated for change (Tracker Item Submitted) made by kluwak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422032&aid=3588800&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: Eric W. Anderson (kluwak) Assigned to: Nobody/Anonymous (nobody) Summary: emacs mode to match rst2pdf syntax (for Ubuntu 12.04) Initial Comment: This patch is relative to the version of Docutils (0.8.1) and rst2pdf (0.16) present on Ubuntu 12.04. rst2pdf expects its output file to be indicated with a '-o' flag, but the emacs mode only knows how to produce commands of the form: command [options] [conffile] input_file output_file This patch adds an "out-options" record to allow: command [options] [conffile] input [out-options] output_file This may not be useful to anyone, since it looks like the current development version of rst.el has changed a lot since 0.8.1. That's OK with me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422032&aid=3588800&group_id=38414 
 [Docutils-develop] [ docutils-Patches-3587533 ] latex2e: Handle classes for bullet lists From: SourceForge.net - 2012-11-20 16:45:01 Patches item #3587533, was opened at 2012-11-15 07:22 Message generated for change (Comment added) made by kirr79 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422032&aid=3587533&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: latex2e: Handle classes for bullet lists Initial Comment: latex2e: Handle classes for bullet lists For example authors could customize documents as follows: .. class:: compact - item 1 - item 2 - item 3 and expect the writer to apply the class. This works for html writer, but not yet for latex2e/xetex and that's why this patch is here. Usual rules for customizing rendering for classed elements is done - for class compact, if stylesheet provides an environment named DUitemizecompact, it will be used, otherwise the default itemize. Personally, for compact lists I use \newenvironment{DUitemizecompact}{% \begingroup% \small% \begin{itemize}% \itemsep=0pt\parskip=0pt% }{% \end{itemize}% \endgroup% } which make text a bit smaller and tightens inter-line gaps. NOTES: * There is no \provideenvironment in LaTeX, so plain \newenviroment is used. * The implementation of DUitemize environment is a bit cumbersome. That's because it is not possible to pass arguments to end when defining environments and because my TeX foo is probably not high enough. (help appreciated) * I've patched the code to emit \begin{DUitemize} only when classes attrubute is present - only to minimize changes to tests, for the patch not being huge with low signal/noise ratio. ---------------------------------------------------------------------- >Comment By: Kirill Smelkov (kirr79) Date: 2012-11-20 08:45 Message: Uploaded cleaned up patch and demo. ---------------------------------------------------------------------- Comment By: Kirill Smelkov (kirr79) Date: 2012-11-15 08:41 Message: Simplified TeX preamble: PreambleCmds.itemize = r""" % bullet list \newenvironment{DUitemize}[1][class-arg]{% % store #1 for end \begingroup% \def\DUitemizearg{#1}% % \ifcsname DUitemize#1\endcsname% %\begin{DUitemize#1}% XXX why this does not work? \begin{DUitemize\DUitemizearg}% \else% \begin{itemize}% \fi% }{% \ifcsname endDUitemize\DUitemizearg\endcsname% \end{DUitemize\DUitemizearg}% \else% \end{itemize}% \fi% \endgroup% }% """ ---------------------------------------------------------------------- Comment By: Kirill Smelkov (kirr79) Date: 2012-11-15 07:24 Message: NOTE: The TeX part of the patch (DUitemize environmet) probably needs polish, but if otherwise in general this approach is correct, I'd like to add more class handling to latex2e backend - for example to field lists and other environments. Thanks beforehand for your reply, Kirill ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422032&aid=3587533&group_id=38414 
 [Docutils-develop] [ docutils-Bugs-3575838 ] Incorrect using identity instead equality From: SourceForge.net - 2012-11-15 21:08:42 Bugs item #3575838, was opened at 2012-10-09 14:55 Message generated for change (Comment added) made by milde You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3575838&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: latex2e writer Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Serhiy Storchaka (storchaka) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect using identity instead equality Initial Comment: In writers/latex2e/__init__.py identity used instead equality. The result of this operation is implementation detail. As proposed on http://comments.gmane.org/gmane.comp.python.ideas/16547 such code even can be syntax error in future Python version. ---------------------------------------------------------------------- >Comment By: Günter Milde (milde) Date: 2012-11-15 13:08 Message: Thanks for the report and patch. However, the patched function (visit_admonition) was changed several releases ago and does no longer contain this if clause. Several other occurences of incorrect identity tests were fixed some time ago. Interestingly, the patch is to "revision 88981" while Docutils SVN is at revision 7536. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3575838&group_id=38414 
 [Docutils-develop] [ docutils-Bugs-3540052 ] Please add an option to specify path to MathJax.js From: SourceForge.net - 2012-11-15 20:57:16 Bugs item #3540052, was opened at 2012-07-03 22:58 Message generated for change (Comment added) made by milde 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: Closed >Resolution: Fixed 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: Günter Milde (milde) Date: 2012-11-15 12:57 Message: Fixed; thanks for the bug report. You can download a current snapshot from: http://docutils.svn.sourceforge.net/viewvc/docutils/trunk/docutils/?view=tar ---------------------------------------------------------------------- Comment By: Dmitry Shachnev (mandriver) Date: 2012-10-10 09:19 Message: Attached two updated patches that fix issues Guenter pointed to. ---------------------------------------------------------------------- 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-3587445 ] :leveloffset directive for master documents From: SourceForge.net - 2012-11-15 20:54:34 Feature Requests item #3587445, was opened at 2012-11-15 01:07 Message generated for change (Comment added) made by milde You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422033&aid=3587445&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: Works For Me Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: :leveloffset directive for master documents Initial Comment: Pasted fŕom AsciiDoc documentation: You have a number of stand-alone AsciiDoc documents that you want to process as a single document. Simply processing them with a series of include macros won’t work because the documents contain (level 0) document titles. The solution is to create a top level wrapper document and use the leveloffset attribute to push them all down one level. ---------------------------------------------------------------------- >Comment By: Günter Milde (milde) Date: 2012-11-15 12:54 Message: Why not simply start the wrapper document with a title using an adornment that is not used in the included files? All other section levels will move down by one automatically. It this does not help, consider using Sphinx for merging documents. It is specially built for this purpose and offers much more customization options in this regard. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422033&aid=3587445&group_id=38414 
 [Docutils-develop] [ docutils-Patches-3587533 ] latex2e: Handle classes for bullet lists From: SourceForge.net - 2012-11-15 16:41:47 Patches item #3587533, was opened at 2012-11-15 07:22 Message generated for change (Comment added) made by kirr79 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422032&aid=3587533&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: latex2e: Handle classes for bullet lists Initial Comment: latex2e: Handle classes for bullet lists For example authors could customize documents as follows: .. class:: compact - item 1 - item 2 - item 3 and expect the writer to apply the class. This works for html writer, but not yet for latex2e/xetex and that's why this patch is here. Usual rules for customizing rendering for classed elements is done - for class compact, if stylesheet provides an environment named DUitemizecompact, it will be used, otherwise the default itemize. Personally, for compact lists I use \newenvironment{DUitemizecompact}{% \begingroup% \small% \begin{itemize}% \itemsep=0pt\parskip=0pt% }{% \end{itemize}% \endgroup% } which make text a bit smaller and tightens inter-line gaps. NOTES: * There is no \provideenvironment in LaTeX, so plain \newenviroment is used. * The implementation of DUitemize environment is a bit cumbersome. That's because it is not possible to pass arguments to end when defining environments and because my TeX foo is probably not high enough. (help appreciated) * I've patched the code to emit \begin{DUitemize} only when classes attrubute is present - only to minimize changes to tests, for the patch not being huge with low signal/noise ratio. ---------------------------------------------------------------------- >Comment By: Kirill Smelkov (kirr79) Date: 2012-11-15 08:41 Message: Simplified TeX preamble: PreambleCmds.itemize = r""" % bullet list \newenvironment{DUitemize}[1][class-arg]{% % store #1 for end \begingroup% \def\DUitemizearg{#1}% % \ifcsname DUitemize#1\endcsname% %\begin{DUitemize#1}% XXX why this does not work? \begin{DUitemize\DUitemizearg}% \else% \begin{itemize}% \fi% }{% \ifcsname endDUitemize\DUitemizearg\endcsname% \end{DUitemize\DUitemizearg}% \else% \end{itemize}% \fi% \endgroup% }% """ ---------------------------------------------------------------------- Comment By: Kirill Smelkov (kirr79) Date: 2012-11-15 07:24 Message: NOTE: The TeX part of the patch (DUitemize environmet) probably needs polish, but if otherwise in general this approach is correct, I'd like to add more class handling to latex2e backend - for example to field lists and other environments. Thanks beforehand for your reply, Kirill ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422032&aid=3587533&group_id=38414 
 [Docutils-develop] [ docutils-Patches-3587533 ] latex2e: Handle classes for bullet lists From: SourceForge.net - 2012-11-15 15:24:49 Patches item #3587533, was opened at 2012-11-15 07:22 Message generated for change (Comment added) made by kirr79 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422032&aid=3587533&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: latex2e: Handle classes for bullet lists Initial Comment: latex2e: Handle classes for bullet lists For example authors could customize documents as follows: .. class:: compact - item 1 - item 2 - item 3 and expect the writer to apply the class. This works for html writer, but not yet for latex2e/xetex and that's why this patch is here. Usual rules for customizing rendering for classed elements is done - for class compact, if stylesheet provides an environment named DUitemizecompact, it will be used, otherwise the default itemize. Personally, for compact lists I use \newenvironment{DUitemizecompact}{% \begingroup% \small% \begin{itemize}% \itemsep=0pt\parskip=0pt% }{% \end{itemize}% \endgroup% } which make text a bit smaller and tightens inter-line gaps. NOTES: * There is no \provideenvironment in LaTeX, so plain \newenviroment is used. * The implementation of DUitemize environment is a bit cumbersome. That's because it is not possible to pass arguments to end when defining environments and because my TeX foo is probably not high enough. (help appreciated) * I've patched the code to emit \begin{DUitemize} only when classes attrubute is present - only to minimize changes to tests, for the patch not being huge with low signal/noise ratio. ---------------------------------------------------------------------- >Comment By: Kirill Smelkov (kirr79) Date: 2012-11-15 07:24 Message: NOTE: The TeX part of the patch (DUitemize environmet) probably needs polish, but if otherwise in general this approach is correct, I'd like to add more class handling to latex2e backend - for example to field lists and other environments. Thanks beforehand for your reply, Kirill ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422032&aid=3587533&group_id=38414 
 [Docutils-develop] [ docutils-Patches-3587533 ] latex2e: Handle classes for bullet lists From: SourceForge.net - 2012-11-15 15:22:32 Patches item #3587533, was opened at 2012-11-15 07:22 Message generated for change (Tracker Item Submitted) made by kirr79 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422032&aid=3587533&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: latex2e: Handle classes for bullet lists Initial Comment: latex2e: Handle classes for bullet lists For example authors could customize documents as follows: .. class:: compact - item 1 - item 2 - item 3 and expect the writer to apply the class. This works for html writer, but not yet for latex2e/xetex and that's why this patch is here. Usual rules for customizing rendering for classed elements is done - for class compact, if stylesheet provides an environment named DUitemizecompact, it will be used, otherwise the default itemize. Personally, for compact lists I use \newenvironment{DUitemizecompact}{% \begingroup% \small% \begin{itemize}% \itemsep=0pt\parskip=0pt% }{% \end{itemize}% \endgroup% } which make text a bit smaller and tightens inter-line gaps. NOTES: * There is no \provideenvironment in LaTeX, so plain \newenviroment is used. * The implementation of DUitemize environment is a bit cumbersome. That's because it is not possible to pass arguments to end when defining environments and because my TeX foo is probably not high enough. (help appreciated) * I've patched the code to emit \begin{DUitemize} only when classes attrubute is present - only to minimize changes to tests, for the patch not being huge with low signal/noise ratio. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422032&aid=3587533&group_id=38414 
 [Docutils-develop] [ docutils-Feature Requests-3587446 ] "leveloffset" directive for master documents From: SourceForge.net - 2012-11-15 09:08:52 Feature Requests item #3587446, was opened at 2012-11-15 01:08 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422033&aid=3587446&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: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: "leveloffset" directive for master documents Initial Comment: Pasted from AsciiDoc documentation You have a number of stand-alone AsciiDoc documents that you want to process as a single document. Simply processing them with a series of include macros won’t work because the documents contain (level 0) document titles. The solution is to create a top level wrapper document and use the leveloffset attribute to push them all down one level. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422033&aid=3587446&group_id=38414 
 [Docutils-develop] [ docutils-Feature Requests-3587445 ] :leveloffset directive for master documents From: SourceForge.net - 2012-11-15 09:07:47 Feature Requests item #3587445, was opened at 2012-11-15 01:07 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422033&aid=3587445&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: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: :leveloffset directive for master documents Initial Comment: Pasted fŕom AsciiDoc documentation: You have a number of stand-alone AsciiDoc documents that you want to process as a single document. Simply processing them with a series of include macros won’t work because the documents contain (level 0) document titles. The solution is to create a top level wrapper document and use the leveloffset attribute to push them all down one level. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422033&aid=3587445&group_id=38414 
 [Docutils-develop] [ docutils-Bugs-3587443 ] Paths in included files should be relative From: SourceForge.net - 2012-11-15 08:59:43 Bugs item #3587443, was opened at 2012-11-15 00:59 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3587443&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: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Paths in included files should be relative Initial Comment: Paths in included files should be relative to the directory of the included document. For the moment they are relative to the directory of the master document. I observed this behaviour while including source code in subdocuments. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422030&aid=3587443&group_id=38414 
 [Docutils-develop] [ docutils-Feature Requests-3586249 ] linenos='table' style code highlighting From: SourceForge.net - 2012-11-11 21:50:13 Feature Requests item #3586249, was opened at 2012-11-11 13:17 Message generated for change (Comment added) made by sf-jonas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422033&aid=3586249&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: Markarian421 (sf-jonas) Assigned to: Nobody/Anonymous (nobody) Summary: linenos='table' style code highlighting Initial Comment: Highlighting code with :number-lines: turned on renders the line numbers "inline" with the code lines in HTML. This makes it impractical to cut & paste code snippets into an editor or the shell. Pygments has an option linenos that puts line numbers in a separate table column which makes cutting work. However, from scanning the code it seems docutils' use of pygments is more low-level (e.g. not really using the formatters, just the lexers/tokenizers). An option to format lines with tables is hence not so straight-forward. Maybe I submit a patch myself later on... ---------------------------------------------------------------------- >Comment By: Markarian421 (sf-jonas) Date: 2012-11-11 13:50 Message: Seems code-block in Sphinx does the right thing with line numbering. Kind of unfortunate that there are different directives in Sphinx doing more or less the same thing... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422033&aid=3586249&group_id=38414 
 [Docutils-develop] [ docutils-Feature Requests-3586249 ] linenos='table' style code highlighting From: SourceForge.net - 2012-11-11 21:17:27 Feature Requests item #3586249, was opened at 2012-11-11 13:17 Message generated for change (Tracker Item Submitted) made by sf-jonas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422033&aid=3586249&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: Markarian421 (sf-jonas) Assigned to: Nobody/Anonymous (nobody) Summary: linenos='table' style code highlighting Initial Comment: Highlighting code with :number-lines: turned on renders the line numbers "inline" with the code lines in HTML. This makes it impractical to cut & paste code snippets into an editor or the shell. Pygments has an option linenos that puts line numbers in a separate table column which makes cutting work. However, from scanning the code it seems docutils' use of pygments is more low-level (e.g. not really using the formatters, just the lexers/tokenizers). An option to format lines with tables is hence not so straight-forward. Maybe I submit a patch myself later on... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=422033&aid=3586249&group_id=38414 
 Re: [Docutils-develop] Revision 7503 breaks command line usage From: Guenter Milde - 2012-11-11 20:51:23 On 2012-11-11, Stefan Merten wrote: > [-- Type: text/plain, Encoding: quoted-printable --] > Hi! > After some time I updated from the SVN repository and found that since > r7503 command line usage does not work any more:: > $rst2html --version > Traceback (most recent call last): > File "/home/stefan/bin/rst2html", line 23, in > publish_cmdline(writer_name='html', description=description) > File "/home/stefan/lib/python/lib/docutils/docutils/core.py", line 349, in publish_cmdline > pub.set_components(reader_name, parser_name, writer_name) > File "/home/stefan/lib/python/lib/docutils/docutils/core.py", line 93, in set_components > self.set_reader(reader_name, self.parser, parser_name) > File "/home/stefan/lib/python/lib/docutils/docutils/core.py", line 83, in set_reader > self.reader = reader_class(parser, parser_name) > File "/home/stefan/lib/python/lib/docutils/docutils/readers/__init__.py", line 52, in __init__ > self.set_parser(parser_name) > File "/home/stefan/lib/python/lib/docutils/docutils/readers/__init__.py", line 63, in set_parser > parser_class = parsers.get_parser_class(parser_name) > File "/home/stefan/lib/python/lib/docutils/docutils/parsers/__init__.py", line 53, in get_parser_class > return module.Parser > AttributeError: 'module' object has no attribute 'Parser' > For r7502:: >$ rst2html --version > rst2html (Docutils 0.10 [repository], Python 2.6.5, on linux2) Thank you for the bug report. However, I cannot reproduce it with a current SVN checkout (revision 7536): $rst2html --version rst2html (Docutils 0.10 [repository], Python 2.7.3rc2, on linux2)$ python2.6 .bin/rst2html --version rst2html (Docutils 0.10 [repository], Python 2.6.8, on linux2) $python2.5 ~/.bin/rst2html --version rst2html (Docutils 0.10 [repository], Python 2.5.5, on linux2)$ python2.4 ~/.bin/rst2html --version rst2html (Docutils 0.10 [repository], Python 2.4.6, on linux2) $python3 ~/.bin/rst2html --version rst2html (Docutils 0.10 [repository], Python 3.2.3, on linux2) Could you try again with a recent checkout or snapshot? Günter   Re: [Docutils-develop] Revision 7503 breaks command line usage From: engelbert gruber - 2012-11-11 20:17:07 Attachments: Message as HTML py25 and 26 on mac work but it is alread revision 7536.$ python2.5 tools/rst2html.py --version rst2html.py (Docutils 0.10 [repository], Python 2.5.4, on darwin) On 11 November 2012 12:07, Stefan Merten wrote: > Hi! > > After some time I updated from the SVN repository and found that since > r7503 command line usage does not work any more:: > > $rst2html --version > Traceback (most recent call last): > File "/home/stefan/bin/rst2html", line 23, in > publish_cmdline(writer_name='html', description=description) > File "/home/stefan/lib/python/lib/docutils/docutils/core.py", line > 349, in publish_cmdline > pub.set_components(reader_name, parser_name, writer_name) > File "/home/stefan/lib/python/lib/docutils/docutils/core.py", line 93, > in set_components > self.set_reader(reader_name, self.parser, parser_name) > File "/home/stefan/lib/python/lib/docutils/docutils/core.py", line 83, > in set_reader > self.reader = reader_class(parser, parser_name) > File > "/home/stefan/lib/python/lib/docutils/docutils/readers/__init__.py", line > 52, in __init__ > self.set_parser(parser_name) > File > "/home/stefan/lib/python/lib/docutils/docutils/readers/__init__.py", line > 63, in set_parser > parser_class = parsers.get_parser_class(parser_name) > File > "/home/stefan/lib/python/lib/docutils/docutils/parsers/__init__.py", line > 53, in get_parser_class > return module.Parser > AttributeError: 'module' object has no attribute 'Parser' > > For r7502:: > >$ rst2html --version > rst2html (Docutils 0.10 [repository], Python 2.6.5, on linux2) > > > Grüße > > Stefan > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_nov > _______________________________________________ > 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/ncr 

Showing results of 37

1 2 > >> (Page 1 of 2)