From Felix.Wiemann at gmx.net Tue Jun 1 09:55:18 2004 From: Felix.Wiemann at gmx.net (Felix Wiemann) Date: Tue Jun 1 10:00:38 2004 Subject: [Doc-SIG] Re: changing comment & directive syntax References: <87r7t0a5zu.fsf@news2.ososo.de> <40BB6BA7.1020108@python.org> Message-ID: <87d64jgz7d.fsf@news2.ososo.de> David Goodger wrote: > Felix Wiemann wrote: > >> IMO it's much more intuitive than the '..' syntax for comments. >> >> When the '.. invisible::' directive is available and when it is >> being used, we can start phasing out the present comment syntax. > > I'm still unconvinced that any change in the syntax is necessary. > I don't see enough benefit to justify the cost in broken documents. > This needs a lot of discussion before we make any changes at all. I think it's relatively easy to turn comments into directives in existing documents. A regexp should do for most cases. Anyway, after having the new invisible/comment directive for some time, we can ask in Docutils-users if there are still many old-style comments around. -- When replying to my email address, ensure that the mail header contains 'Felix Wiemann'. Please don't send unrequested mails > 64 KB. From Felix.Wiemann at gmx.net Tue Jun 1 10:01:46 2004 From: Felix.Wiemann at gmx.net (Felix Wiemann) Date: Tue Jun 1 10:10:06 2004 Subject: [Doc-SIG] Re: ``invisible`` reST-directive References: <87r7t0a5zu.fsf@news2.ososo.de> <40BB6B35.4060906@python.org> Message-ID: <878yf7gywl.fsf@news2.ososo.de> David Goodger wrote: > Felix Wiemann wrote: > >> I propose adding a new directive 'invisible' to the reST-syntax, >> which translates to the already existing doctree element 'comment'. > > I don't like the name "invisible". Why not "comment"? There's a > possible objection that it might be confused with admonition > directives, like "note" and "caution", but I consider that to be > minor. For a reader unfamiliar with reST, 'comment' would be almost as confusing as the existing '..' syntax. 'comment' is only appropriate when thinking of reST as a 'real' language. However, it's rather a simple markup syntax, and at least it shouldn't look like a language (as opposed to LaTeX, for example). Thus, 'invisible' describes more obviously what it does. > And please, let's use another thread for the syntax discussion. What syntax discussion? Do you mean the naming? -- When replying to my email address, ensure that the mail header contains 'Felix Wiemann'. Please don't send unrequested mails > 64 KB. From goodger at python.org Tue Jun 1 10:40:43 2004 From: goodger at python.org (David Goodger) Date: Tue Jun 1 10:40:55 2004 Subject: [Doc-SIG] Re: changing comment & directive syntax In-Reply-To: <87d64jgz7d.fsf@news2.ososo.de> References: <87r7t0a5zu.fsf@news2.ososo.de> <40BB6BA7.1020108@python.org> <87d64jgz7d.fsf@news2.ososo.de> Message-ID: <40BC956B.2090205@python.org> Felix Wiemann wrote: > I think it's relatively easy to turn comments into directives in > existing documents. A regexp should do for most cases. It may be easy, but that doesn't mean it will be done, or should be done. Discussion is welcome, but please realize that it's an uphill battle. > Anyway, after having the new invisible/comment directive for some > time, we can ask in Docutils-users if there are still many old-style > comments around. We shall see. But I'm currently strongly against "phasing out" the present comment syntax. If the explicit "comment" directive dominates usage, then we'll reconsider. ReStructuredText *is* markup. User-friendly markup, but it's still markup, and it requires some learning. -- David Goodger From goodger at python.org Tue Jun 1 10:41:00 2004 From: goodger at python.org (David Goodger) Date: Tue Jun 1 10:41:05 2004 Subject: [Doc-SIG] Re: ``invisible`` reST-directive In-Reply-To: <878yf7gywl.fsf@news2.ososo.de> References: <87r7t0a5zu.fsf@news2.ososo.de> <40BB6B35.4060906@python.org> <878yf7gywl.fsf@news2.ososo.de> Message-ID: <40BC957C.3040601@python.org> Felix Wiemann wrote: > For a reader unfamiliar with reST, 'comment' would be almost as > confusing as the existing '..' syntax. > > 'comment' is only appropriate when thinking of reST as a 'real' > language. However, it's rather a simple markup syntax, and at least > it shouldn't look like a language (as opposed to LaTeX, for > example). Thus, 'invisible' describes more obviously what it does. I'm not convinced. reST is as real a markup language as any other, and for better or worse, the accepted term in every markup language I know of is "comment". "Invisible" makes me think of the old HTML tag, or of text rendered with the foreground color set the same as the background color ("spoiler" text that you have to select to read). "Comment" is a precise and accurate term. Let's not innovate needlessly. >> And please, let's use another thread for the syntax discussion. > > What syntax discussion? Do you mean the naming? I mean the discussion in the "changing comment & directive syntax" thread. Thanks for replying there. -- David Goodger From edloper at gradient.cis.upenn.edu Tue Jun 1 12:30:23 2004 From: edloper at gradient.cis.upenn.edu (Edward Loper) Date: Tue Jun 1 12:29:15 2004 Subject: [Doc-SIG] Re: changing comment & directive syntax In-Reply-To: <200406011604.i51G48aN026037@gradient.cis.upenn.edu> References: <200406011604.i51G48aN026037@gradient.cis.upenn.edu> Message-ID: <40BCAF1F.5050204@gradient.cis.upenn.edu> Felix wrote: > Thus, comments could be written as:: > > Normal text. > > .. invisible:: This is a comment. > > This still belongs to the comment. > > Normal text again. I brought this up before, and I'm still +1 on it. I don't feel very strongly about the name. "comment::" makes the most sense to me, but I'd be ok with "invisible::" or "ignore::" or something like that, as well. How's this... 1. Add a new comment:: directive (or whatever you want to call it). 2. Change the docs to encourage people to use the new directive for comments. (I.e., under the ".." comment syntax, add a note that the prefered way to mark comments is with the directive.) 3. Put of the decision of whether to phase out the old ".." syntax for comments until later. I'm +1 for phasing it out eventually, but it's worth waiting to see if people like the new syntax and/or if people start editing their old documents to use the new syntax, before we make decisions about phasing out the old syntax. -Edward p.s., another good property of adding it as a directive instead of just "..": it gives people a keyword to search for, when they encounter it for the first time. From cben at users.sf.net Thu Jun 3 16:07:46 2004 From: cben at users.sf.net (Beni Cherniavsky) Date: Thu Jun 3 16:07:53 2004 Subject: [Doc-SIG] Re: ``invisible`` reST-directive In-Reply-To: <40BC957C.3040601@python.org> References: <87r7t0a5zu.fsf@news2.ososo.de> <40BB6B35.4060906@python.org> <878yf7gywl.fsf@news2.ososo.de> <40BC957C.3040601@python.org> Message-ID: David Goodger wrote on 2004-06-01: > Felix Wiemann wrote: > > For a reader unfamiliar with reST, 'comment' would be almost as > > confusing as the existing '..' syntax. > > > > 'comment' is only appropriate when thinking of reST as a 'real' > > language.However, it's rather a simple markup syntax, and at least > > it shouldn't look like a language (as opposed to LaTeX, for > > example).Thus, 'invisible' describes more obviously what it does. > > I'm not convinced.reST is as real a markup language as any other, > and for better or worse,the accepted term in every markup language I > know of is "comment"."Invisible" makes me think of the old HTML > tag, or of text rendered with the foreground color set the > same as the background color ("spoiler" text that you have to select > to read)."Comment" is a precise and accurate term. Let's not > innovate needlessly. > I'm also -1 on ``invisible``, because it's not WYSIWYG - it *is* visible in the source, which looks pretty confusing IMHO ;-). I'm about +0.5 on adding a comment directive at all (as ``comment``). BTW, if I remember the ``..`` vs. directives rules about empty lines, writing ``.. comment::`` now is not entirely equivallent to a real directive. That's a point in favour of adding a real directive (and not saying "you can write ``.. comment::`` (or anything else) and it will work even today). I'm -1 on phasing-out ``..`` due to backward-compatibility. -- Beni Cherniavsky From cben at users.sf.net Thu Jun 3 16:10:06 2004 From: cben at users.sf.net (Beni Cherniavsky) Date: Thu Jun 3 16:10:12 2004 Subject: [Doc-SIG] Re: [Docutils-users] objections to renaming "--exit" option / "exit_level" setting? In-Reply-To: <40BB65D5.70607@python.org> References: <40BB65D5.70607@python.org> Message-ID: David Goodger wrote on 2004-05-31: > Does anybody use the "exit_level" setting ("--exit" option)?I'm > thinking of changing the names to better reflect the function. > From docs/config.txt: > > """ > exit_level > A system message level threshold; non-halting system messages at > or above this level will produce a non-zero exit status at normal > exit. Exit status is the maximum system message level plus 10 (11 > for INFO, etc.). > > Default: disabled (5). Options: ``--exit``. > """ > > I think the option originally suggested by Beni Cherniavsky, > "--exit-status", is better.I'd also change the setting to > "exit_status_level".I'm sending this message to gauge the impact; > will this break a lot of people's systems? > I'm +1 (unsurprisingly ;-). I was just about to suggest a name change when reading the thread where Felix misunderstood the meaning of it... -- Beni Cherniavsky From cben at users.sf.net Sat Jun 5 20:27:57 2004 From: cben at users.sf.net (Beni Cherniavsky) Date: Sat Jun 5 20:28:02 2004 Subject: [Doc-SIG] field-list-table better idea than list-table Message-ID: With reference to the `list-table`__ directive idea:: .. list-table:: * - Treat - Quantity - Description * - Albatross! - 299 - On a stick! * - Crunchy Frog! - 1499 - If we took the bones out, it wouldn't be crunchy, now would it? __ http://docutils.sourceforge.net/docs/dev/todo.html#body-list-table I think it's a sub-optimal idea because it tries to find an alternative representation for a table's *layout* instead of representing its *meaning*. I find this list completely unreadable - to see what's the meaning of "1499" I must note that it's the second field, go back to the top and find the second field there ("Quantity"). I things don't line up one under the other, some other reminder is necessary. There is a natural way in reST to provide such clues: field lists! I therefore propose a field-list-table directive. To separate the table lines one from the other (adjacent field lists would just be treated as one), the natural idea is making a bulleted list of field lists:: .. field-list-table:: :header: - :treat: Treat :quantity: Quantity :descr: Description - :treat: Albatross! :quantity: 299 :descr: On a stick! - :treat: Crunchy Frog! :quantity: 1499 :descr: If we took the bones out, it wouldn't be crunchy, now would it? Header rows ----------- Why have a separate header row? We cannot in general extract it from the used field names because a field name cannot contain everything one might put in a table cell (although we can offer the option for the simpler cases?). A separate header row also allows shorter field names and doesn't force one to rewrite the whole table when the header text changes. How it the header separated from the table? A transition (``-----``) would look good (I think) but is not allowed in this position by the current document parser (which is not entirely prohibitive - it's not a change to the document model because it will not be left in the document as a transition). I showed a ``:header:`` directive option which is simple but perhaps sub-optimal. Other ideas would be welcome. Why there is a bullet under ``:header:``? Recall that a table's header can consist of several rows. We can make it optional for the common case. How is column order determined? From the order of fields in the first header row. Field order in all other rows is ignored. As a side-effect, this allows trivial re-arrangement of columns. Spans ----- Column-spans are easy: just specify several field names together, separated by, say, a comma:: - :foo: abc :bar: def :baz: ghi - :foo, bar: quux :baz: qux In non-adjacent columns are specified in this way, we should either report an error or duplicate the value into each span of adjacent columns. I think I like the later more - a "logical span" approach. For big column-spans, it might be convenient to specify only the first and last fields:: - :foo-baz: quuux By using named fields, it becomes possible to omit fields in some rows without losing track of things, which is important if we want to allow row-spans (anybody who edited an HTML table with spans will know what I mean ;-). One possible syntax for row-spans is to simply treat any row where a field is missing as a row-span from the last row where it appeared. Leaving a field empty is still possible by writing a field with empty content. But perhaps this is too implicit. Another way would be to require an explicit continuation marker (``...``/``-"-``/``"``?) in all but the first row of a spanned field. If implemented, the same marker should also be supported in simple tables, which lack on row-spanning abilities. Header column idea ------------------ Another natural variant is to allow a description list with field lists as descriptions:: .. field-list-table:: :header: Treat :quantity: Quantity :descr: Description Albatross! :quantity: 299 :descr: On a stick! Crunchy Frog! :quantity: 1499 :descr: If we took the bones out, it wouldn't be crunchy, now would it? which would make the whole first column a header column. This has just as many rights to existance as a header row, but I don't think it should be introduced unless we find a syntax for it in ascii-art tables first... Besides, such syntax has drawbacks: it's limited to a single column and a single paragraph fitting on one source line. -- Beni Cherniavsky Note that I can only read emails on week-ends. From goodger at python.org Sun Jun 6 13:06:44 2004 From: goodger at python.org (David Goodger) Date: Sun Jun 6 13:06:52 2004 Subject: [Doc-SIG] field-list-table better idea than list-table In-Reply-To: References: Message-ID: <40C34F24.8030902@python.org> Beni Cherniavsky wrote: > With reference to the `list-table`__ directive idea:: ... > __ http://docutils.sourceforge.net/docs/dev/todo.html#body-list-table > > I think it's a sub-optimal idea because it tries to find an > alternative representation for a table's *layout* instead of > representing its *meaning*. I'd say it's an alternative representation of a table's structure. A table is a 2D matrix, equivalent to a list of lists. There's no semantic meaning in the ASCII-art table syntax either. I just thought of an alternative: use enumerated lists instead of bulleted lists for the table cells:: .. list-table:: * 1. Treat 2. Quantity 3. Description * 1. Albatross! 2. 299 3. On a stick! * 1. Crunchy Frog! 2. 1499 3. If we took the bones out, it wouldn't be crunchy, now would it? That gives much better correspondence between cells in the same column. I think that were only field-list-tables available, a lot of users would use the equivalent degenerate case:: .. field-list-table:: :header: - :1: Treat :2: Quantity :3: Description ... > There is a natural way in reST to provide such clues: field lists! > I therefore propose a field-list-table directive. It's a good idea. A bit verbose, but much more readable. > Why have a separate header row? We cannot in general extract it from > the used field names because a field name cannot contain everything > one might put in a table cell (although we can offer the option for > the simpler cases?). Best not to put the header data under the ":header:" directive option. The ":header:" option could contain either an integer (the number of header rows, default 1), or some flag like "fields". Then the table data looks much more consistent (all data at one level). So these two tables would be equivalent:: .. field-list-table:: :header: 1 - :treat: Treat :quantity: Quantity :descr: Description - :treat: Albatross! :quantity: 299 :descr: On a stick! .. field-list-table:: :header: fields - :Treat: Albatross! :Quantity: 299 :Description: On a stick! > A separate header row also allows shorter field names and doesn't > force one to rewrite the whole table when the header text changes. Good point. > How is the header separated from the table? Could use multiple lists to obviate the need for a ":header:" option:: .. field-list-table:: * :treat: Treat :quantity: Quantity :descr: Description - :treat: Albatross! :quantity: 299 :descr: On a stick! > How is column order determined? From the order of fields in the > first header row. What if there's no header? I'd say the first row's field list (regardless whether it's a header or body row) should determine the field names and column order. > Field order in all other rows is ignored. As a side-effect, this > allows trivial re-arrangement of columns. That's neat. > Column-spans are easy: just specify several field names together, > separated by, say, a comma:: Range syntax is better than list syntax (IOW, no commas). > For big column-spans, it might be convenient to specify only the > first and last fields:: > > - :foo-baz: quuux For small ones also, I think. Probably " - " (space dash space) as a separator would be better, since "foo-baz" could be a legitimate field name. Or " ... " (space ellipsis space). > In non-adjacent columns are specified in this way, we should either > report an error or duplicate the value into each span of adjacent > columns. I think I like the later more - a "logical span" approach. Too clever, I think. Would duplicate cells ever be used? Sometimes in a table, the first header row contains spans. It may be necessary to provide a way to specify the column field names independently of data rows. A directive option would do it. > By using named fields, it becomes possible to omit fields in some > rows without losing track of things, which is important if we want > to allow row-spans (anybody who edited an HTML table with spans will > know what I mean ;-). Yes, that would work. > One possible syntax for row-spans is to simply treat any row where a > field is missing as a row-span from the last row where it appeared. > Leaving a field empty is still possible by writing a field with > empty content. But perhaps this is too implicit. Too implicit. > Another way would be to require an explicit continuation marker > (``...``/``-"-``/``"``?) in all but the first row of a spanned > field. Empty comments could work (".."). > If implemented, the same marker should also be supported in simple > tables, which lack on row-spanning abilities. Interesting. > Another natural variant is to allow a description list with field > lists as descriptions:: > > .. field-list-table:: > :header: > Treat > :quantity: Quantity > :descr: Description > > Albatross! > :quantity: 299 > :descr: On a stick! > > Crunchy Frog! > :quantity: 1499 > :descr: If we took the bones out, it wouldn't be crunchy, > now would it? > > which would make the whole first column a header column. That wouldn't allow for empty cells or row spans in the first column though. But it's a limitation that we could live with, like those of simple tables. > This has just as many rights to existance as a header row, There's a name for a header column: "stub". > but I don't think it should be introduced unless we find a syntax > for it in ascii-art tables first... Easy to make one up: +------------------------++------------+----------+----------+ | Header row, column 1 || Header 2 | Header 3 | Header 4 | | (header rows optional) || | | | +========================++============+==========+==========+ | body row 1, column 1 || column 2 | column 3 | column 4 | +------------------------++------------+----------+----------+ | body row 2 || Cells may span columns. | +------------------------++------------+---------------------+ | body row 3 || Cells may | - Table cells | +------------------------++ span rows. | - contain | | body row 4 || | - body elements. | +------------------------++------------+----------+----------+ | body row 5 || Cells may also be | | | || empty: ``-->`` | | +------------------------++-----------------------+----------+ > Besides, such syntax has drawbacks: it's limited to a > single column and a single paragraph fitting on one source line. But that suits the vast majority of tables written. Not a big issue, just another limitation. Good ideas! -- David Goodger From priest at sfu.ca Sun Jun 6 13:20:45 2004 From: priest at sfu.ca (David Priest) Date: Sun Jun 6 13:20:06 2004 Subject: [Doc-SIG] field-list-table better idea than list-table In-Reply-To: <40C34F24.8030902@python.org> References: <40C34F24.8030902@python.org> Message-ID: On Sun, 06 Jun 2004 13:06:44 -0400, David Goodger wrote: > I just thought of an alternative: use enumerated lists instead of > bulleted lists for the table cells:: > > .. list-table:: > > * 1. Treat > 2. Quantity > 3. Description > * 1. Albatross! > 2. 299 > 3. On a stick! > * 1. Crunchy Frog! > 2. 1499 > 3. If we took the bones out, it wouldn't be crunchy, > now would it? IMO, too wordy. The numbers don't add any structure to the endeavour. At best, make them optional; I can see how they'd be handy in an immense table, if only for the (human) reader's convienence. Mostly what I want to mention here, though, is that the above list could also be written as .. list-table:: * Treat * Albatross! * Gannet! * Crunchy Frog! * Quantity * 299 * 199 * 1499 * Description * On a stick! * On a stick! * If we took the bones out... It depends on what we want to emphasize when we cluster the data. In the former, we've packed the data for each treat into one set; in the latter, we've packed the data for each category into one set. So we should be able to specify "column-wise" or "row-wise" ordering. From goodger at python.org Sun Jun 6 14:01:28 2004 From: goodger at python.org (David Goodger) Date: Sun Jun 6 14:01:33 2004 Subject: [Doc-SIG] field-list-table better idea than list-table In-Reply-To: References: <40C34F24.8030902@python.org> Message-ID: <40C35BF8.401@python.org> David Priest wrote: > IMO, too wordy. The numbers don't add any structure to the > endeavour. Obviously a difference of opinion. > At best, make them optional; I can see how they'd be handy in an > immense table, if only for the (human) reader's convienence. The human reader's (and writer's) convenience is the whole point. > Mostly what I want to mention here, though, is that the above list > could also be written as > > .. list-table:: > > * Treat > * Albatross! > * Gannet! > * Crunchy Frog! > > * Quantity > * 299 > * 199 > * 1499 > > * Description > * On a stick! > * On a stick! > * If we took the bones out... Note, however, that the above is a single list of 12 items. The blank lines are not significant to the markup. You'd have to specify how many columns or rows to use. > It depends on what we want to emphasize when we cluster the data. > In the former, we've packed the data for each treat into one set; in > the latter, we've packed the data for each category into one set. > > So we should be able to specify "column-wise" or "row-wise" > ordering. Yes, that's potentially useful. Seems to me that a list-driven table is a feature that could be done in many ways. Each user will have their preferred usage. Perhaps a single "list-table" directive could handle them all, depending on which options and content are present. -- David Goodger From Felix.Wiemann at gmx.net Sun Jun 6 14:47:59 2004 From: Felix.Wiemann at gmx.net (Felix Wiemann) Date: Sun Jun 6 14:47:19 2004 Subject: [Doc-SIG] Re: field-list-table better idea than list-table References: <40C34F24.8030902@python.org> Message-ID: <87hdtobk0w.fsf@news2.ososo.de> David Goodger wrote: > Beni Cherniavsky wrote: > >> How is the header separated from the table? > > Could use multiple lists to obviate the need for a ":header:" option:: > > .. field-list-table:: > > * :treat: Treat > :quantity: Quantity > :descr: Description > > - :treat: Albatross! > :quantity: 299 > :descr: On a stick! IMO that's a little bit unobious. >> Column-spans are easy: just specify several field names together, >> separated by, say, a comma:: > > Range syntax is better than list syntax (IOW, no commas). Comma syntax should be allowed, too, in order to allow the user to avoid trouble when changing the column order. > Probably " - " (space dash space) as a separator would be better, > since "foo-baz" could be a legitimate field name. Or " ... " (space > ellipsis space). Or maybe both. (Maybe also ' .. '. I've seen this somewhere, just don't recall now.) > Sometimes in a table, the first header row contains spans. It may be > necessary to provide a way to specify the column field names > independently of data rows. A directive option would do it. Or some text to indicate that there is a colspan. E.g.: +-------+---------+ | Input | Output | +---+---+---------+ | A | B | A and B | +===+===+=========+ | 0 | 0 | 0 | +---+---+ | | 0 | 1 | | +---+---+ | | 1 | 0 | | +---+---+---------+ | 1 | 1 | 1 | +---+---+---------+ would be rendered as: .. field-list-table:: :header: 2 - :a: Input :b: :colspan: :and: Output - :a: A :b: B :and: A and B - :a: 0 :b: 0 :and: 0 - :a: 0 :b: 1 :and: :rowspan: - :a: 1 :b: 0 :and: :rowspan: - :a: 1 :b: 1 :and: 1 >> Another way would be to require an explicit continuation marker >> (``...``/``-"-``/``"``?) in all but the first row of a spanned >> field. > > Empty comments could work (".."). It's a little bit hackish. I'd prefer something like :colspan: or :rowspan:. >> Another natural variant is to allow a description list with field >> lists as descriptions:: >> >> .. field-list-table:: >> :header: >> Treat >> :quantity: Quantity >> :descr: Description >> >> Albatross! >> :quantity: 299 >> :descr: On a stick! >> >> Crunchy Frog! >> :quantity: 1499 >> :descr: If we took the bones out, it wouldn't be crunchy, >> now would it? Better ':header: 1', as David suggested. But apart from that it looks good. Agreed to all the rest of your and also David Priest's posting. Looks all very promising... -- When replying to my email address, ensure that the mail header contains 'Felix Wiemann'. Please don't send unrequested mails > 64 KB. From Felix.Wiemann at gmx.net Sun Jun 6 14:55:15 2004 From: Felix.Wiemann at gmx.net (Felix Wiemann) Date: Sun Jun 6 14:54:36 2004 Subject: [Doc-SIG] Re: field-list-table better idea than list-table References: <40C34F24.8030902@python.org> <40C35BF8.401@python.org> Message-ID: <87d64cbjos.fsf@news2.ososo.de> David Goodger wrote: > David Priest wrote: > >> IMO, too wordy. The numbers don't add any structure to the >> endeavour. At best, make them optional; I can see how they'd be handy >> in an immense table, if only for the (human) reader's convienence. > > The human reader's (and writer's) convenience is the whole point. I agree that numbers are rather useless. But in case they are really needed, one could also use fields (':1:', ':2:' etc.); no need for an extra syntax. >> Mostly what I want to mention here, though, is that the above list >> could also be written as >> >> .. list-table:: >> >> * Treat >> * Albatross! >> * Gannet! >> * Crunchy Frog! >> >> * Quantity >> * 299 >> * 199 >> * 1499 >> >> * Description >> * On a stick! >> * On a stick! >> * If we took the bones out... > > Note, however, that the above is a single list of 12 items. The blank > lines are not significant to the markup. You'd have to specify how > many columns or rows to use. Specifying the number of rows or columns is bad. Better have something like this: - * Treat * Albatross! * Gannet! * Crunchy Frog! - * Quantity * 299 etc. -- http://www.ososo.de/ From goodger at python.org Fri Jun 11 10:09:53 2004 From: goodger at python.org (David Goodger) Date: Fri Jun 11 10:09:55 2004 Subject: [Doc-SIG] field-list-table better idea than list-table In-Reply-To: References: Message-ID: <40C9BD31.5090201@python.org> This and earlier threads summarized here: -- David Goodger From fdrake at acm.org Thu Jun 17 13:26:46 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Sun Jun 20 23:31:01 2004 Subject: [Doc-SIG] Downloadable HTML from the trunk Message-ID: <200406171326.46254.fdrake@acm.org> I've changed the script I use to update the online version of the development docmentation so that when that's updated, a copy of the tarball is kept available for download. Both the online and downloadable forms of the development documentation are at: http://www.python.org/dev/doc/ -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From goodger at python.org Fri Jun 18 18:11:52 2004 From: goodger at python.org (David Goodger) Date: Sun Jun 20 23:31:09 2004 Subject: [Doc-SIG] "csv-table" directive added Message-ID: <40D368A8.4020306@python.org> David Priest's "csv-table" directive has been added to the reStructuredText parser. Thanks David! Docs here: http://docutils.sf.net/docs/ref/rst/directives.html#csv-table Native speakers, please update the language files in docutils/parsers/rst/languages/. -- David Goodger