You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(15) |
Oct
(21) |
Nov
(18) |
Dec
(59) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(43) |
Feb
(35) |
Mar
(78) |
Apr
(65) |
May
(163) |
Jun
(169) |
Jul
(137) |
Aug
(77) |
Sep
(47) |
Oct
(27) |
Nov
(43) |
Dec
(68) |
2004 |
Jan
(61) |
Feb
(39) |
Mar
(11) |
Apr
(42) |
May
(86) |
Jun
(82) |
Jul
(24) |
Aug
(26) |
Sep
(37) |
Oct
(62) |
Nov
(131) |
Dec
(43) |
2005 |
Jan
(31) |
Feb
(56) |
Mar
(65) |
Apr
(165) |
May
(106) |
Jun
(97) |
Jul
(65) |
Aug
(150) |
Sep
(78) |
Oct
(115) |
Nov
(41) |
Dec
(26) |
2006 |
Jan
(50) |
Feb
(39) |
Mar
(56) |
Apr
(67) |
May
(89) |
Jun
(68) |
Jul
(116) |
Aug
(65) |
Sep
(58) |
Oct
(103) |
Nov
(28) |
Dec
(52) |
2007 |
Jan
(92) |
Feb
(60) |
Mar
(124) |
Apr
(96) |
May
(69) |
Jun
(79) |
Jul
(25) |
Aug
(22) |
Sep
(7) |
Oct
(17) |
Nov
(27) |
Dec
(32) |
2008 |
Jan
(57) |
Feb
(87) |
Mar
(51) |
Apr
(43) |
May
(56) |
Jun
(62) |
Jul
(25) |
Aug
(82) |
Sep
(58) |
Oct
(42) |
Nov
(38) |
Dec
(86) |
2009 |
Jan
(50) |
Feb
(33) |
Mar
(84) |
Apr
(90) |
May
(109) |
Jun
(37) |
Jul
(22) |
Aug
(51) |
Sep
(93) |
Oct
(86) |
Nov
(31) |
Dec
(62) |
2010 |
Jan
(33) |
Feb
(57) |
Mar
(62) |
Apr
(43) |
May
(30) |
Jun
(49) |
Jul
(20) |
Aug
(40) |
Sep
(152) |
Oct
(38) |
Nov
(15) |
Dec
(32) |
2011 |
Jan
(29) |
Feb
(25) |
Mar
(65) |
Apr
(45) |
May
(27) |
Jun
(11) |
Jul
(14) |
Aug
(8) |
Sep
(13) |
Oct
(117) |
Nov
(60) |
Dec
(19) |
2012 |
Jan
(23) |
Feb
(32) |
Mar
(24) |
Apr
(41) |
May
(56) |
Jun
(24) |
Jul
(15) |
Aug
(11) |
Sep
(26) |
Oct
(21) |
Nov
(12) |
Dec
(31) |
2013 |
Jan
(32) |
Feb
(24) |
Mar
(39) |
Apr
(44) |
May
(44) |
Jun
(8) |
Jul
(9) |
Aug
(12) |
Sep
(34) |
Oct
(19) |
Nov
(5) |
Dec
(9) |
2014 |
Jan
(22) |
Feb
(12) |
Mar
(7) |
Apr
(2) |
May
(13) |
Jun
(17) |
Jul
(8) |
Aug
(10) |
Sep
(7) |
Oct
(4) |
Nov
|
Dec
(39) |
2015 |
Jan
(13) |
Feb
(12) |
Mar
(12) |
Apr
(40) |
May
(5) |
Jun
(22) |
Jul
(3) |
Aug
(42) |
Sep
(5) |
Oct
(10) |
Nov
|
Dec
(10) |
2016 |
Jan
(9) |
Feb
(43) |
Mar
(5) |
Apr
(14) |
May
(17) |
Jun
(5) |
Jul
(5) |
Aug
(22) |
Sep
(5) |
Oct
|
Nov
(4) |
Dec
(18) |
2017 |
Jan
(28) |
Feb
(29) |
Mar
(9) |
Apr
(23) |
May
(48) |
Jun
(5) |
Jul
(32) |
Aug
(9) |
Sep
(13) |
Oct
(13) |
Nov
(6) |
Dec
(4) |
2018 |
Jan
(6) |
Feb
(5) |
Mar
(1) |
Apr
(2) |
May
(5) |
Jun
(17) |
Jul
(12) |
Aug
(15) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
(6) |
Mar
(3) |
Apr
(5) |
May
(10) |
Jun
(6) |
Jul
(6) |
Aug
|
Sep
(11) |
Oct
(18) |
Nov
(10) |
Dec
(7) |
2020 |
Jan
(3) |
Feb
(14) |
Mar
(2) |
Apr
(1) |
May
(5) |
Jun
|
Jul
(1) |
Aug
(11) |
Sep
(8) |
Oct
|
Nov
(1) |
Dec
(14) |
2021 |
Jan
(7) |
Feb
(2) |
Mar
(1) |
Apr
(8) |
May
(23) |
Jun
(7) |
Jul
(10) |
Aug
(1) |
Sep
|
Oct
(7) |
Nov
(10) |
Dec
(2) |
2022 |
Jan
|
Feb
(21) |
Mar
|
Apr
(3) |
May
(7) |
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
2023 |
Jan
(18) |
Feb
|
Mar
(1) |
Apr
|
May
(9) |
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
(2) |
Mar
(3) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Stefan M. <sm...@oe...> - 2003-05-17 17:40:39
|
-----BEGIN PGP SIGNED MESSAGE----- Hi! Today Magnus Lyck=E5 wrote: > The *language* code for > Swedish (svenska) is sv. The *country* code for Sweden (Sverige) > is se. These are different things. E.g. for Finland, there are > two official languages, Swedish and Finnish. A country code can't > be used to determine language. I think the respective standard is at http://www.loc.gov/standards/iso639-2/englangn.html ISO 3166 encodes countries while ISO 4217 encodes currencies (from ftp://dkuug.dk/i18n/index.htm) Hope this helps Stefan -----BEGIN PGP SIGNATURE----- Version: 2.6.3in Charset: noconv Comment: Processed by Mailcrypt 3.5.7, an Emacs/PGP interface iQCVAwUBPsZzvQnTZgC3zSk5AQHl3AP/f5LZsxDVxsYyvV/lgKZsZBfm66QF5MYI WPJcfSpcVwJnvVjV4llx6gTec3V+YReakXikOTjiwsuZ3v0TyhB48gGs05ezuYPf eS7WY1T7LxM+9/xWtieUNDWRx+el5on2nf9rE0r6iNMx8H16tTE3hh4dbWnUzX6L DaozcOJyRSY=3D =3D63W0 -----END PGP SIGNATURE----- |
From: Stefan M. <sm...@oe...> - 2003-05-17 17:11:44
|
-----BEGIN PGP SIGNED MESSAGE----- Hi all! I'd like to see nesting of inline tags in reST. Actually it is one of the *main* drawbacks of the tool I'm still using that it does not allow for such nesting. And it would be good if such a feature is kind of orthogonal - i.e. you can combine arbitrary tags freely. However, I have no opinion on the syntax. May be some sort of parentheses (``()``, ``[]``, ``{}``, ``<>``) would be most appropriate because people already know that parentheses nest. 4 days ago David Goodger wrote: > Issues: >=20 > 1. I had already settled on "phrase" as the generic inline element, > but perhaps "inline" is more direct and expressive. Opinions? I like "inline". > 2. The existing "class" attribute is perfectly suitable to this task. > There's no need for a new "argument" attribute. I'll come back to that (on the developer list). This time with a calmer mood ;-) . Mit Freien Gr=FC=DFen Stefan -----BEGIN PGP SIGNATURE----- Version: 2.6.3in Charset: noconv Comment: Processed by Mailcrypt 3.5.7, an Emacs/PGP interface iQCVAwUBPsZs8AnTZgC3zSk5AQErggP8D9QlXcz3kPdrgTkhRlBwDL/dyO/cMAAl C1NN3sgbiycq1B5UvKLy/HP2RlLX7DKYg8SZdLLPrfFx4tTp7Td+BDcv2Cts4gqt xCiQ7fSmVUEbg8SbOWFTnDR4uehC+gXsG3tTNazKLJnVyU3kSmx7SAOYIpsadgDE rc7GhLqj0ys=3D =3DRSzw -----END PGP SIGNATURE----- |
From: Magnus <ma...@th...> - 2003-05-17 15:13:00
|
At 11:29 2003-05-17 +0200, Engelbert Gruber wrote: >not an answer to my question but a good point. I haven't used citations yet. For me, this is no big deal today, but for people who write scientific articles, the different journals often have specific requirements that BibTex can handle. I did notice a technical problem though: Having more than 18 footnotes or citations that have been marked "[x]_" but not yet defined ".. [x] ..." will cause: ! LaTeX Error: Too many unprocessed floats. As I understand, the current solution uses the mechanism for placing pictures etc, and it isn't supposed to handle a lot of things at once. Just for footnotes placed in the bottom of a page, 18 is enough in most cases, but a limit of 18 references in a reference list (if there are no footnotes) isn't so good. Regarding the looks for citations, a numeric "[5]" notation is very common, as is "[Mey97b]" etc. If there should be options in docutils, it should be to either print numbers, or to print the citation label as today. But there's hardly any point in writing numerical citations if the footnotes are in bracket form, since they will look the same then! :) I haven't looked into the technical aspects of this, but it seems to me if docutils footnotes could be turned in to \footnotemark and \footnotetext. I don't quite understand why this isn't done. Is it for the sake of hyperlinks? I don't get that to work anyway. Neither bookmarks nor hyperlinks work as expected for mw with rst2latex -> latex -> dvipdf. Do I have to do something special? I don't really care though. For online viewing I prefer (X)HTML/CSS. I mainly use PDF for printing. For \footnotemark and -text to work, we have to keep track of a counter, in case the definitions aren't given in the same order as the markers, or in case there is more than one marker for a footnote, but that seems quite plausible. For citations, we'd simply turn "The LaTexBook [Lamport94]_" into "The LaTexBook~\cite{Lamport94}" and .. [Lamport94] Latex A Doc... into \bibitem{Lamport94} Latex A Doc... Then we need to put \begin{thebibliography} and \end{ditto} around the bibitems. We also need to put all bibitems in one place... Is this difficult? Perhaps it would be good to add some Docutils notation for the heading above the references. I think Latex will print the heading "References" automatically above the references, and if we want such a title in the text version as well, or in the HTML version, we don't want it twice in Latex output... -- Magnus Lycka (It's really Lyckå), ma...@th... Thinkware AB, Sweden, www.thinkware.se I code Python ~ The shortest path from thought to working program |
From: Magnus <ma...@th...> - 2003-05-17 10:59:05
|
At 11:39 2003-05-17 +0200, eng...@ss... wrote: > > Just to be clear, there's no active translation being done. The intent > > is that Swedish-language document with a ":F=F6rfattare:" bibliographic > > field will become an <authors> element internally, and this will > > generate the text "F=F6rfattare:" on output. If you use ":Authors:" in= a > > Swedish document, "Authors:" will be output; it would be a generic > > (unregistered) bibliographic field. Right, of course. I guess all this transformation to HTML and Latex/PDF made me forget that the text file is supposed to be readable... :) > > --language=3Dse > >there is no se in docutils/languages and swedish seams to be sv.py, going= with >the toplevel domain codes "sv" would be El Salvador, should this be changed= ? No, don't change that, it's correct. The *language* code for Swedish (svenska) is sv. The *country* code for Sweden (Sverige) is se. These are different things. E.g. for Finland, there are two official languages, Swedish and Finnish. A country code can't be used to determine language. >the language setting is not to get a translation, but to enable docutils >to recognize bibliographic items. and in latex the correct hyphenation >should be loaded. I understand that now... :) -- Magnus Lycka (It's really Lyckå), ma...@th... Thinkware AB, Sweden, www.thinkware.se I code Python ~ The shortest path from thought to working program=20 |
From: Gunnar S. <g.s...@gm...> - 2003-05-17 10:29:49
|
> A sample style.tex would be great. I'm still lost on this one. Hi, here is mine. (Please note that you need the fancyhdr-package to use this one.) Happy reSTing, Gunnar. % geometry \geometry{a4paper,twoside,tmargin=1.5cm, headheight=1cm,headsep=0.75cm} % donot indent first line. \setlength{\parindent}{0pt} \setlength{\parskip}{5pt plus 2pt minus 1pt} % sloppy \sloppy % fonts \usepackage{times} \renewcommand{\familydefault}{\sfdefault} % pagestyle \usepackage{fancyhdr} \pagestyle{fancy} \addtolength{\headheight}{\baselineskip} \renewcommand{\sectionmark}[1]{\markboth{#1}{}} \renewcommand{\subsectionmark}[1]{\markright{#1}} \fancyhf{} \fancyhead[LE,RO]{\bfseries\textsf{\Large\thepage}} \fancyhead[LO]{\textsf{\footnotesize\rightmark}} \fancyhead[RE]{\textsc{\textsf{\footnotesize\leftmark}}} \fancyfoot[RE,LO]{\textsf{\scriptsize\today}} |
From: <eng...@ss...> - 2003-05-17 09:38:05
|
On Fri, 16 May 2003, David Goodger wrote: > Magnus Lyck=E5 wrote: > > I've seen in the source that there are language > > specific things, like translating Authors to > > F=F6rfattare. > > Read the docs for a description of the intention of the code: > <http://docutils.sf.net/spec/rst/reStructuredText.html#bibliographic-fiel= ds>. > > Just to be clear, there's no active translation being done. The intent > is that Swedish-language document with a ":F=F6rfattare:" bibliographic > field will become an <authors> element internally, and this will > generate the text "F=F6rfattare:" on output. If you use ":Authors:" in a > Swedish document, "Authors:" will be output; it would be a generic > (unregistered) bibliographic field. > > For an English-language document, the inverse will be true ("F=F6rfattare= " > will *not* be translated). > > The output text is inserted by the writer for registered bibliographic > fields. If a writer is not inserting a label in the correct language, > it's a bug in the writer. > > > What I haven't quite figured out is how to turn this on. > > --language=3Dse there is no se in docutils/languages and swedish seams to be sv.py, going w= ith the toplevel domain codes "sv" would be El Salvador, should this be changed= ? > > Using "-lsv" for rst2latex.py, I get > > > > \documentclass[10pt,swedish]{article} > > > > in the Latex file, but is still says "Author" and "Date" > > and "Generated on" in the text. I though those would get > > translated... the language setting is not to get a translation, but to enable docutils to recognize bibliographic items. and in latex the correct hyphenation should be loaded. --=20 BINGO: high-performance breakthrough --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6170 Zirl Innweg 5b / Tel. ++43-5238-93535 ---+ |
From: <eng...@ss...> - 2003-05-17 09:38:04
|
On Fri, 16 May 2003, Magnus Lyck=E5 wrote: > At 16:41 2003-05-16 +0200, eng...@ss... wrote: > >BTW the option is footnote-reference, citation references have always > >brackets. > > > >* is this ok ? > >* should it be one option ? > >* should it be a separate option ? > > I'm not using citation references right now. I guess the most > flexible thing would be to make it work with BibTex, but I've > never really worked with that. It's the normal thing to do > with Latex and citations though. not an answer to my question but a good point. --=20 BINGO: Testing! Testing! Testing! Testing! This is your nine o'clock alarm= call! --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6170 Zirl Innweg 5b / Tel. ++43-5238-93535 ---+ |
From: David G. <go...@py...> - 2003-05-17 04:01:12
|
Paul Tremblay wrote: > It is just that Docutils > seems a bit hard for a novice like me to comprehend. It is complex, so that's perfectly understandable. Please feel free to ask any questions you may have. The answers often become part of the project documentation. > Also, it was mentioned that I could get a sandbox to > post some of my experimental code. Can I get one, > David? I actually added you to the project a few days ago, but forgot to tell you about it. -- David Goodger http://starship.python.net/~goodger Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv |
From: Paul T. <pht...@ya...> - 2003-05-16 22:25:36
|
> > 4. I find your proposed syntax pretty ugly. (This is > clearly the key > problem with it :-)) > > Can I suggest that you separate your two proposals. > On the one hand, > arguing for the *existence* of inline nesting (in > isolation of syntax) > looks like it may gain some support. The second > issue, of thrashing out > an acceptable syntax for the feature, can be handled > later, once the > need for the feature has been agreed. This second > issue is likely to > attract much more heat, but that's the nature of > syntax discussions :-) > Sorry I haven't checked my mail for this group. Using Yahoo web mail is a pain. I agree with your change. I am not attatched to using brackets. I would simply like the ability to have inline nesting. David has said he is more likely to accept a change if accompanied by a patch. I have looked at the docutils state machine, and it looks like it will take me quite a while to figure it out. In fact, I must be honest: I don't know if I really want to spend the time to do so. That makes me guilty of dumping an idea on someone else without contributing. It is just that Docutils seems a bit hard for a novice like me to comprehend. I am saying this now for the sake of honesty. If David never gets around to implementing the change, I can only blame myself. Does anyone out there ever find a need for inline nesting? Also, it was mentioned that I could get a sandbox to post some of my experimental code. Can I get one, David? My sourceforge id is paultremblay. Thanks Paul ===== ************************** * pht...@ea... * ************************** __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com |
From: David G. <go...@py...> - 2003-05-16 22:18:04
|
Magnus Lyckå wrote: > I've seen in the source that there are language > specific things, like translating Authors to > Författare. Read the docs for a description of the intention of the code: <http://docutils.sf.net/spec/rst/reStructuredText.html#bibliographic-fields>. Just to be clear, there's no active translation being done. The intent is that Swedish-language document with a ":Författare:" bibliographic field will become an <authors> element internally, and this will generate the text "Författare:" on output. If you use ":Authors:" in a Swedish document, "Authors:" will be output; it would be a generic (unregistered) bibliographic field. For an English-language document, the inverse will be true ("Författare" will *not* be translated). The output text is inserted by the writer for registered bibliographic fields. If a writer is not inserting a label in the correct language, it's a bug in the writer. > What I haven't quite figured out is how to turn this on. --language=se > Using "-lsv" for rst2latex.py, I get > > \documentclass[10pt,swedish]{article} > > in the Latex file, but is still says "Author" and "Date" > and "Generated on" in the text. I though those would get > translated... The word "still" above is what made me suspicious. Please show your original text. The "Generated on" text hasn't been translated yet. Patches welcome. -- David Goodger http://starship.python.net/~goodger Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv |
From: Magnus <ma...@th...> - 2003-05-16 21:49:10
|
I've seen in the source that there are language specific things, like translating Authors to F=F6rfattare. What I haven't quite figured out is how to turn this on. Using "-lsv" for rst2latex.py, I get \documentclass[10pt,swedish]{article} in the Latex file, but is still says "Author" and "Date" and "Generated on" in the text. I though those would get translated... -- Magnus Lycka (It's really Lyckå), ma...@th... Thinkware AB, Sweden, www.thinkware.se I code Python ~ The shortest path from thought to working program=20 |
From: Magnus <ma...@th...> - 2003-05-16 21:03:49
|
At 16:41 2003-05-16 +0200, eng...@ss... wrote: >BTW the option is footnote-reference, citation references have always >brackets. > >* is this ok ? >* should it be one option ? >* should it be a separate option ? I'm not using citation references right now. I guess the most flexible thing would be to make it work with BibTex, but I've never really worked with that. It's the normal thing to do with Latex and citations though. -- Magnus Lycka (It's really Lyckå), ma...@th... Thinkware AB, Sweden, www.thinkware.se I code Python ~ The shortest path from thought to working program |
From: <eng...@ss...> - 2003-05-16 15:16:43
|
On Fri, 16 May 2003, Magnus Lyck=E5 wrote: > Thanks Engelbert, > > At 08:48 2003-05-15 +0200, eng...@ss... wrote: > >command line option --hyperlink-color=3D0 see docs/latex.txt or > >http://docutils.sourceforge.net/docs/latex.html > ... > >--footnote-references Format for footnote references: one of > > "superscript" or "brackets". > > Default is "brackets". > > Great! It seems these things are just what I need. > I needed a new snapshot for this to work though... BTW the option is footnote-reference, citation references have always brack= ets. * is this ok ? * should it be one option ? * should it be a separate option ? --=20 BINGO: pining for the fjords. --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6170 Zirl Innweg 5b / Tel. ++43-5238-93535 ---+ |
From: <eng...@ss...> - 2003-05-16 15:16:27
|
On Fri, 16 May 2003, Magnus Lyck=E5 wrote: > I do like the get away from the space between text and superscript > digit, and I would prefer to see the superscript at the hypertarget > as well, e.g. > > < \begin{figure}[b]\hypertarget{agile}[1] > --- > > \begin{figure}[b]\raisebox{0.5em}[0em]{\hypertarget{agile}\scriptsize = 1} i have a added a option --snap-footnote-refs=3D1 FOR TESTING MIGHT BE CHANG= ED. this one removes trailing blanks and end of lines from the previous item. > but it's beyond my current skills to fix that other than as a little > post processing script. At least tonight... :) > > > > Are there any good docs for this styles.tex thingie? > >no and yes. no not in docutils. yes: style.tex is included after > >setting defaults in the latex header, style.tex could override nearly > >anything. > > > >few examples are in http://docutils.sourceforge.net/docs/latex.html. > > A sample style.tex would be great. I'm still lost on this one. this is mine:: % donot indent first line. \setlength{\parindent}{0pt} \setlength{\parskip}{5pt plus 2pt minus 1pt} % sloppy % ------ % Less strict (opposite to default fussy) space size between words. There= fore % less hyphenation. \sloppy % fonts % ----- % times for pdf generation, gives smaller pdf files. % % But in standard postscript fonts: courier and times/helvetica do not fi= t. % Maybe use pslatex. \usepackage{times} % pagestyle DOS NOT WORK \pagestyle{headings} to change the papersize (untested):: \geometry{a5paper,landscape} make admonitions narrower:: \setlength{\admonitionwidth}{0.7\textwidth} --=20 BINGO: significantly improved cost structure --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6170 Zirl Innweg 5b / Tel. ++43-5238-93535 ---+ |
From: Magnus <ma...@th...> - 2003-05-15 22:13:07
|
Thanks Engelbert, At 08:48 2003-05-15 +0200, eng...@ss... wrote: >command line option --hyperlink-color=0 see docs/latex.txt or >http://docutils.sourceforge.net/docs/latex.html ... >--footnote-references Format for footnote references: one of > "superscript" or "brackets". > Default is "brackets". Great! It seems these things are just what I need. I needed a new snapshot for this to work though... I do like the get away from the space between text and superscript digit, and I would prefer to see the superscript at the hypertarget as well, e.g. < \begin{figure}[b]\hypertarget{agile}[1] --- > \begin{figure}[b]\raisebox{0.5em}[0em]{\hypertarget{agile}\scriptsize 1} but it's beyond my current skills to fix that other than as a little post processing script. At least tonight... :) > > Are there any good docs for this styles.tex thingie? >no and yes. no not in docutils. yes: style.tex is included after >setting defaults in the latex header, style.tex could override nearly >anything. > >few examples are in http://docutils.sourceforge.net/docs/latex.html. A sample style.tex would be great. I'm still lost on this one. -- Magnus Lycka (It's really Lyckå), ma...@th... Thinkware AB, Sweden, www.thinkware.se I code Python ~ The shortest path from thought to working program |
From: Beni C. <cb...@te...> - 2003-05-15 20:07:14
|
David Goodger wrote on 2003-05-15: > There's one problem with this concession. What if one wants a > definition list item which defines the term "::"? We'd have to escape > it somehow. Currenty, "\::" doesn't work (although it should; I'll > fix it), and ":\:" is misinterpreted as a field name (name "\"; also a > bug to be fixed). You forgot the fourth option: ``\:\:`` does work. > Assuming these bugs are squashed, I suppose it's a useful special > case. It would only be reasonable to apply it to "::"-only > paragraphs though. I think the blank line is visually necessary if > there's text before the "::": > > The text in this paragraph needs separation > from the literal block following:: > This doesn't look right. > I'll tell you what it should work like: comments! :: .. Here is the body. .. Here is another body. I guess the bullet style has to be allowed if we go with the analogy to comments. .. But this is an empty comment followed by a blockquote. This breaks the analogy because... :: ...this must be parsed as a literal block to maintain backward compatibility. So if you want to allow compact literal blocks, it makes sense to define them precisely as for comments, as a parallel alternative to the current ::-at-end-of-paragraph syntaxes (including the special case of a paragraph consisting of only ``::``). Consider my other message opposing ``::`` bullet syntax on aesthetic reasons withdrawn :-). > The literal block item is indented because literal blocks *are* > indented. A special case could be made for literal blocks which are > the sole content of their container; wouldn't be difficult. > If you do, make it an option, like list compaction currently is. This seems to belong in the stylesheet -- by analogy with the merging of vertical spaces between paragraphs, I think one should be able to merge indentations. I can't think of a way to do it in CSS though, short of making the writer emit a special class attribute for cases where this is applicable. > The bullet list is indented because web browsers indent lists relative > to the surrounding text. I don't agree with this policy, but I don't > think it's going to change any time soon. I don't know if it can be > "fixed" both easily and universally. > CSS? -- Beni Cherniavsky <cb...@us...> The Three Laws of Copy-Protechnics: http://www.technion.ac.il/~cben/threelaws.html |
From: Beni C. <cb...@te...> - 2003-05-15 19:39:35
|
David Goodger wrote on 2003-05-15: > [Aahz] > >> Ick. What's the correct indentation for each line of the following? > >> > >> :: if foo: > >> print "spam" > >> else: > >> print "eggs" > > [David Goodger] > > It would be the same as if it was spelled out fully as follows: > > > > :: > > > > if foo: > > print "spam" > > else: > > print "eggs" > > > > ("if" and "else" don't line up; intentionally, I suppose.) Including > > the "::" on the first line would leave all indentation as-is, visually. > > The "::" itself would not detract from the indentation. > > I just realized that "::" would serve the same function as "*" in a > bullet list, with identical indentation rules for the block. I.e., > > +-------+-----------------------+ > | ":: " | literal block text | > +-------| | > +-----------------------+ > I object on (subjective) aesthetic grounds. I looks to me very unnatural to have ``::`` as a bullet. It asks for putting several such "items" but what would be the meaning of it? :: :: One literal block :: Another literal block OK, this probably means what it means - two literal blocks one after the other. I guess I'm attacking it for the wrong reason. Still, when you have one such "item", something looks wrong to me. -- Beni Cherniavsky <cb...@us...> The Three Laws of Copy-Protechnics: http://www.technion.ac.il/~cben/threelaws.html |
From: Fred L. D. Jr. <fd...@ac...> - 2003-05-15 16:52:03
|
Aahz writes: > Incidentally, the box formatting is wrong because there's a TAB in it; > I've left it for you to see yourself. (Just a reminder that TABs are > evil. ;-) i'm coming to realize that us-ascii contains far too many characters; upper case and spaces aren't exactly our friends, either. wouldn'tpythonbeeasiertoreadlikethis?;) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation |
From: Aahz <aa...@py...> - 2003-05-15 16:47:15
|
On Thu, May 15, 2003, David Goodger wrote: > > I just realized that "::" would serve the same function as "*" in a > bullet list, with identical indentation rules for the block. I.e., > > +-------+-----------------------+ > | ":: " | literal block text | > +-------| | > +-----------------------+ That's even worse -- now the rule is ":: " gets replaced by " ". IMO, it's acceptable for bullets because every line has to have the same indent; it doesn't work where varying indent is the standard case. Incidentally, the box formatting is wrong because there's a TAB in it; I've left it for you to see yourself. (Just a reminder that TABs are evil. ;-) -- Aahz (aa...@py...) <*> http://www.pythoncraft.com/ "In many ways, it's a dull language, borrowing solid old concepts from many other languages & styles: boring syntax, unsurprising semantics, few automatic coercions, etc etc. But that's one of the things I like about it." --Tim Peters on Python, 16 Sep 93 |
From: Aahz <aa...@py...> - 2003-05-15 16:44:18
|
On Thu, May 15, 2003, David Goodger wrote: > Aahz wrote: >> >>Ick. What's the correct indentation for each line of the following? >> >>:: if foo: >> print "spam" >> else: >> print "eggs" > > It would be the same as if it was spelled out fully as follows: > > :: > > if foo: > print "spam" > else: > print "eggs" > > ("if" and "else" don't line up; intentionally, I suppose.) Including > the "::" on the first line would leave all indentation as-is, visually. > The "::" itself would not detract from the indentation. So you're saying that "::" gets replaced by " " in the output? That works, but I still think it's ugly and too easily confused. -- Aahz (aa...@py...) <*> http://www.pythoncraft.com/ "In many ways, it's a dull language, borrowing solid old concepts from many other languages & styles: boring syntax, unsurprising semantics, few automatic coercions, etc etc. But that's one of the things I like about it." --Tim Peters on Python, 16 Sep 93 |
From: David G. <go...@py...> - 2003-05-15 16:40:11
|
[Aahz] >> Ick. What's the correct indentation for each line of the following? >> >> :: if foo: >> print "spam" >> else: >> print "eggs" [David Goodger] > It would be the same as if it was spelled out fully as follows: > > :: > > if foo: > print "spam" > else: > print "eggs" > > ("if" and "else" don't line up; intentionally, I suppose.) Including > the "::" on the first line would leave all indentation as-is, visually. > The "::" itself would not detract from the indentation. I just realized that "::" would serve the same function as "*" in a bullet list, with identical indentation rules for the block. I.e., +-------+-----------------------+ | ":: " | literal block text | +-------| | +-----------------------+ -- David Goodger |
From: David G. <go...@py...> - 2003-05-15 16:28:08
|
Aahz wrote: > Ick. What's the correct indentation for each line of the following? > > :: if foo: > print "spam" > else: > print "eggs" It would be the same as if it was spelled out fully as follows: :: if foo: print "spam" else: print "eggs" ("if" and "else" don't line up; intentionally, I suppose.) Including the "::" on the first line would leave all indentation as-is, visually. The "::" itself would not detract from the indentation. -- David Goodger |
From: Aahz <aa...@py...> - 2003-05-15 16:15:16
|
On Thu, May 15, 2003, David Goodger wrote: > > Here's an idea. Would it be worthwhile to allow literal blocks to > begin without a newline after the "::"? Example: > > :: while True: > print 'hello world' Ick. What's the correct indentation for each line of the following? :: if foo: print "spam" else: print "eggs" -- Aahz (aa...@py...) <*> http://www.pythoncraft.com/ "In many ways, it's a dull language, borrowing solid old concepts from many other languages & styles: boring syntax, unsurprising semantics, few automatic coercions, etc etc. But that's one of the things I like about it." --Tim Peters on Python, 16 Sep 93 |
From: David G. <go...@py...> - 2003-05-15 14:10:41
|
Moore, Paul wrote: > Sorry for the wasted bandwidth. Too late. ;-) I happen to be online and in a communicative mood this morning. > In an attempt to salvage some useful point from this (other than > that I'm incompetent :-)), Not at all. Nested indentation is tricky. There ought to be more about it in the docs. > maybe there's a real issue here. Quoting from the spec, "Blank lines > may be omitted when the markup makes element separation unambiguous, > in conjunction with indentation". Now, that's clearly a concession > to usability, and as such will always result in arguable > edge-cases. However, I'd suggest that indentation is enough to make > the separation between a paragraph which contains just a ``::`` and > the literal text, unambiguous. So I'm arguing that:: > > :: > This is a literal block > > should be treated as a literal block, even in the absence of a blank > line. That's certainly what I was assuming, and it still feels right > to me. This looks like a definition list item to the parser. In fact, the parser produces an "info" (level-1) system message (normally not shown) in such cases: Blank line missing before literal block? Interpreted as a definition list item. There's one problem with this concession. What if one wants a definition list item which defines the term "::"? We'd have to escape it somehow. Currenty, "\::" doesn't work (although it should; I'll fix it), and ":\:" is misinterpreted as a field name (name "\"; also a bug to be fixed). Assuming these bugs are squashed, I suppose it's a useful special case. It would only be reasonable to apply it to "::"-only paragraphs though. I think the blank line is visually necessary if there's text before the "::": The text in this paragraph needs separation from the literal block following:: This doesn't look right. Here's an idea. Would it be worthwhile to allow literal blocks to begin without a newline after the "::"? Example: :: while True: print 'hello world' Perhaps. Perhaps not. > PS I'm going off field lists as a function signature documentation > approach. If I put complex markup in the field body, the > indentation seems inconsistent. I know it's a writer issue, but > the HTML writer is important to me, and I suspect the issue is > too complex to admit a simple CSS fix. Look at the output for > this, to see what I mean:: > > :Literal Block: > :: > > Some literal data > > :Definition List: > name > definition > name: classification > definition > > :Normal Paragraph: > Blah, blah, normal paragraph. > > :Bullet List: > - List item > - List item > > Specifically, the first and last ones look misaligned. I think > it's advisable to keep the contents of field bodies consistent > within one list. The literal block item is indented because literal blocks *are* indented. A special case could be made for literal blocks which are the sole content of their container; wouldn't be difficult. The bullet list is indented because web browsers indent lists relative to the surrounding text. I don't agree with this policy, but I don't think it's going to change any time soon. I don't know if it can be "fixed" both easily and universally. -- David Goodger http://starship.python.net/~goodger Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv |
From: Beni C. <cb...@te...> - 2003-05-15 13:57:04
|
David Goodger wrote on 2003-05-15: > Moore, Paul wrote: > > > Something feels too subtle here, but I don't know quite what. > > It's the interaction of the indentation of multiple nested blocks > which is tricky. > It seems rather easy to fix. The situation is already detected: a message (``Blank line missing before literal block? Interpreted as a definition list item.``) is produced. So why not interpret it the other way around, always treating a ``::`` term as a literal block start? When on earth would one really need a ``::`` term and what will happen if he would have to quote it as ``\:\:``? (Just checked, that works right and suppresses the message. In short, I think ``::`` should always start a literal block. One wart less. -- Beni Cherniavsky <cb...@us...> The Three Laws of Copy-Protechnics: http://www.technion.ac.il/~cben/threelaws.html |