From: <po...@or...> - 2003-02-19 14:43:07
|
I need to produce output that looks like the following example: ///BOXOUT/// ///BOXOUT HEAD/// Notable Quote ///BOXOUT SUBHEAD/// From an Open Source legend ///BOX BODY/// "Python is good." -- Some Pythonista ///END BOX BODY/// I think it might make sense to specify the input using a directive: .. box:: :head: Notable Quote :subhead: From an Open Source legend "Python is good." -- Some Pythonista Does that seem sensible? What's the shortest path to something like this? A custom directive? A variation on an admonition? I read the docs on directives and creating a custom directive, but I'd like a reality check before I'm knee deep in code. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- |
From: <po...@or...> - 2003-02-19 14:50:56
|
po...@or... (Patrick K. O'Brien) writes: > I need to produce output that looks like the following example: > > ///BOXOUT/// > ///BOXOUT HEAD/// > Notable Quote > ///BOXOUT SUBHEAD/// > >From an Open Source legend ^--- Ignore that ">" character, I don't know how he got there. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- |
From: Benja F. <b.f...@gm...> - 2003-02-19 14:56:53
|
Patrick K. O'Brien wrote: > po...@or... (Patrick K. O'Brien) writes: > > >>I need to produce output that looks like the following example: >> >>///BOXOUT/// >>///BOXOUT HEAD/// >>Notable Quote >>///BOXOUT SUBHEAD/// >>>From an Open Source legend > > > ^--- Ignore that ">" character, I don't know how he got there. Your mailer uses the mbox format and puts a ">" in front of each "From[space]" sequence at the beginning of a line. (At least, most certainly.) -b. |
From: <po...@or...> - 2003-02-19 15:27:50
|
Benja Fallenstein <b.f...@gm...> writes: > Your mailer uses the mbox format and puts a ">" in front of each > "From[space]" sequence at the beginning of a line. That makes sense. Thanks for the explanation. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- |
From: Fred L. D. Jr. <fd...@ac...> - 2003-02-19 14:59:49
|
Patrick K. O'Brien writes: > ^--- Ignore that ">" character, I don't know how he got there. That's an "email thing." In the traditional Unix "mbox" mailbox format, "From " lines (lines that start with "From ", note the leading space) are used as delimiters. Some processing tools were not really smart about checking the format of the rest of the line, so lines that begin with "From " in the message body got escaped by inserting a ">" character (why that character, I don't know). Its a nuissance, since it's a one way transformation (there's no way to be sure the line didn't start with ">From " to begin with). -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation |
From: <po...@or...> - 2003-02-19 15:26:17
|
"Fred L. Drake, Jr." <fd...@ac...> writes: > Patrick K. O'Brien writes: > > ^--- Ignore that ">" character, I don't know how he got there. > > That's an "email thing." In the traditional Unix "mbox" mailbox > format, "From " lines (lines that start with "From ", note the leading > space) are used as delimiters. Some processing tools were not really > smart about checking the format of the rest of the line, so lines that > begin with "From " in the message body got escaped by inserting a ">" > character (why that character, I don't know). > > Its a nuissance, since it's a one way transformation (there's no way > to be sure the line didn't start with ">From " to begin with). Learn something new every day. I recently switched from KMail to Gnus, which must be why I never noticed this before. Thanks. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- |
From: David G. <go...@py...> - 2003-02-19 15:29:41
|
Patrick K. O'Brien wrote: > I need to produce output that looks like the following example: > > ///BOXOUT/// > ///BOXOUT HEAD/// > Notable Quote > ///BOXOUT SUBHEAD/// > From an Open Source legend > ///BOX BODY/// > "Python is good." -- Some Pythonista > ///END BOX BODY/// Please elaborate. What should this produce? I'd guess it should be rendered as some text surrounded by a rectangle. But what is the underlying concept or object? Can you relate it to some existing document construct, or point us to an existing example? How should it behave (what are its properties)? What is the output format we're seeing? If this is output-specific, perhaps it could simply be the way that one Writer renders a "topic" or "admonition"? "Topic" elements currently don't have subheads, but they could be added (depending on requirements). A new element would need doctree support. Although this can be of a limited output-specific form, if the construct is useful enough it ought to have general support. > I think it might make sense to specify the input using a directive: ... > Does that seem sensible? I need to know more before I can answer. -- David Goodger http://starship.python.net/~goodger Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv |
From: <po...@or...> - 2003-02-19 15:43:53
|
David Goodger <go...@py...> writes: > Patrick K. O'Brien wrote: > > I need to produce output that looks like the following example: > > > > ///BOXOUT/// > > ///BOXOUT HEAD/// > > Notable Quote > > ///BOXOUT SUBHEAD/// > > From an Open Source legend > > ///BOX BODY/// > > "Python is good." -- Some Pythonista > > ///END BOX BODY/// > > Please elaborate. What should this produce? I'd guess it should be > rendered as some text surrounded by a rectangle. But what is the underlying > concept or object? Can you relate it to some existing document construct, > or point us to an existing example? How should it behave (what are its > properties)? What is the output format we're seeing? That's up to the publisher. This is what Linux Format magazine requires for items that I want to appear in a callout box thingie. They do put the text into a rectangle, but the layout people decide where the rectangle appears on the page. As far as I'm concerned it's magic. ;-) > If this is output-specific, perhaps it could simply be the way that one > Writer renders a "topic" or "admonition"? "Topic" elements currently don't > have subheads, but they could be added (depending on requirements). This convention was dictated to me by Linux Format magazine. So I have no control over the tags. I simply need to be able to produce this exact form of text (tags are on their own line, most of the tags don't have closing tags, etc.) > A new element would need doctree support. Although this can be of a limited > output-specific form, if the construct is useful enough it ought to have > general support. > > > I think it might make sense to specify the input using a directive: > ... > > Does that seem sensible? > > I need to know more before I can answer. Did I tell you enough? -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- |
From: David G. <go...@py...> - 2003-02-19 15:52:06
|
I suspect you want a "sidebar" construct or variation. Are there articles online that display this construct? If there are, please point me to them. [Patrick K. O'Brien] > This convention was dictated to me by Linux Format magazine. Understood. I need to know what the underlying construct *is*, not just how it is to be rendered in code. Looking at a concrete example would help. -- David Goodger http://starship.python.net/~goodger Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv |
From: <po...@or...> - 2003-02-19 16:17:30
|
David Goodger <go...@py...> writes: > I suspect you want a "sidebar" construct or variation. Are there articles > online that display this construct? If there are, please point me to them. Take a look at this pdf: http://www.linuxformat.co.uk/modules.php?op=modload&name=Archives&file=request&arc_request=LXF34.tut_doxy.pdf On page 4 you'll see a box with a head and subhead. One page 1 you'll see the title with description and strap. Those would appear like this in the source text file: ///DESCRIPTION/// Code Commenting ///TITLE/// Fair comment ///STRAP/// Wishing to be understood, Jono Bacon gets help from Doxygen in providing well commented code. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- |
From: David G. <go...@py...> - 2003-02-19 17:28:58
|
[David Goodger] >> I suspect you want a "sidebar" construct or variation. Are there articl= es >> online that display this construct? If there are, please point me to th= em. [Patrick K. O'Brien] > Take a look at this pdf: >=20 >=20 http://www.linuxformat.co.uk/modules.php?op=3Dmodload&name=3DArchives&file=3Drequ= e st&arc_request=3DLXF34.tut_doxy.pdf >=20 > On page 4 you'll see a box with a head and subhead. That's definitely a "sidebar". According to `DocBook: The Definitive Guide <http://www.docbook.org/tdg/en/html/docbook-x.html>`_, sidebar =8B A portion of a document that is isolated from the main narrative flow The DocBook sidebar has a title, but no subtitle. Off the top of my head, = I would suggest an element structure like this (for addition to spec/docutils.dtd):: <!ELEMENT sidebar (title, subtitle?, (%body.elements;)+)> <!ATTLIST sidebar %basic.atts;> The sidebar element would be included in %structure.model as an alternative to body elements and topics:: <!ENTITY % structure.model " ( ( (%body.elements; | topic | sidebar)+, ... A simple directive could be used to implement it, similar to "topic" or admonitions:: .. sidebar:: Mandatory Title Text Goes Here :subtitle: Is Optional Regular body elements follow. This should be added to Docutils itself for general use. Please feel free to take a first crack at implementing it. I'll be glad to help. -- David Goodger http://starship.python.net/~goodger Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv |
From: Beni C. <cb...@te...> - 2003-02-19 18:25:18
|
On 2003-02-19, David Goodger wrote: > That's definitely a "sidebar". According to `DocBook: The Definitive Gui= de > <http://www.docbook.org/tdg/en/html/docbook-x.html>`_, > > sidebar =8B A portion of a document that is isolated from the main > narrative flow > Quoting below that: A Sidebar is a short piece of text, rarely longer than a single column or page, that is presented outside the narrative flow of the main text. and further: DocBook does not specify the location of the Sidebar within the final displayed flow of text. The wrapper may float or remain where it is located. >[snip] > > A simple directive could be used to implement it, similar to "topic" or > admonitions:: > > .. sidebar:: Mandatory Title Text Goes Here > :subtitle: Is Optional > > Regular body elements follow. > > This should be added to Docutils itself for general use. Please feel fre= e > to take a first crack at implementing it. I'll be glad to help. > It feel a little bit too limited; I feel similarly about "topic". Currently reST has no general way to specify that something (e.g. table) should be floated. While this is a presentation issue, it is sits on top of a content issue: most things are intended to be presented in-line while some things are well suited to be floated (some writers can fall back on putting the later inline too). I think a generic "float" directive, with arbitrary content should be added. I don't mind the name but I want generic semantics - it would wrap arbitrary content, without a requirement that it has 1-2 titles, contians no topics, etc. That brings me to the deeper question. Why can't a topic/blockquote/etc. contain headings? My feeling for a blockquote or any other contstruct delimited by increased indentation is that it should be able to contain whatever the top-level document can contain: Document Title =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This is a document. It quotes another: Quoted document's title ----------------------- - True, this is rare that you need complex things inside blockquotes. It's not the intened use. But sometimes you need just that. And for some things, like titles [1]_, nesting would be more natural than adding specific options (that you must remember!) to every directive... - Disclaimer: I haven't tried out how much these constructs work. I just talk from my understanding of the spec which seems to imply that the document consists of 4 levels, so that lower levels can't contain higher-level constructs: 1. sections/transitions 2. body elements 3. physical paragraphs 4. inline markup I can live with the restrictions on 2 in 3 and 3 and 4 but I don't see much point in forbidding 1 inside 2. .. [1] Perhaps it even makes sense to make the mapping from heading style to level inside each blockquote independent from the mapping of the outer document. --=20 Beni Cherniavsky <cb...@tx...> Do not feed the Bugzillas. |
From: <po...@or...> - 2003-02-19 20:20:29
|
Beni Cherniavsky <cb...@te...> writes: > That brings me to the deeper question. Why can't a topic/blockquote/etc. > contain headings? My feeling for a blockquote or any other contstruct > delimited by increased indentation is that it should be able to contain > whatever the top-level document can contain: Thank you for articulating some of the same questions I was having. I agree that it makes more sense to use the same reST conventions in a "subdocument" as in the main document, rather than adding fields, such as :title: and :subtitle: and so forth. I'm curious to see how David feels about this. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- |
From: David G. <go...@py...> - 2003-02-19 23:16:27
|
[David Goodger] >> That's definitely a "sidebar". According to `DocBook: The >> Definitive Guide >> <http://www.docbook.org/tdg/en/html/docbook-x.html>`_, >> >> sidebar =8B A portion of a document that is isolated from the >> main narrative flow [Beni Cherniavsky] > Quoting below that: What's your point, with the extra quoting? > DocBook does not specify the location of the Sidebar within the > final displayed flow of text. The wrapper may float or remain > where it is located. The "sidebar" directive could grow "float" and/or "fixed" options if necessary. > It feel a little bit too limited; I feel similarly about "topic". >=20 > Currently reST has no general way to specify that something (e.g. > table) should be floated. While this is a presentation issue, it is > sits on top of a content issue: most things are intended to be > presented in-line while some things are well suited to be floated > (some writers can fall back on putting the later inline too). I > think a generic "float" directive, with arbitrary content should be > added. I don't mind the name but I want generic semantics - it would > wrap arbitrary content, without a requirement that it has 1-2 > titles, contians no topics, etc. I think that individual directives should grow "float" options if and when required. Alternatively, setting objects "afloat" could be a presentation decision of the Writer or the target software. A directive with arbitrary content seems too complex to me. Assume it contained three paragraphs; would each grow a "float" attribute or would they have to be wrapped by an auxiliary floatable container? I think the latter. In which case, just tack a "float" option/attribute onto the container and allow *it* to have (reasonably) arbitrary content. Not all objects *can* float. In the publishing environments I've used, only "formal" objects (those with titles and/or numbers, such as "Table 1" or "Figure 2") are floated; referring to floating "informal" (untitled/unnumbered) objects from the main text would be problematic. I remember one publishing environment where *all* formal objects were floated -- to the top or bottom of the page, usually -- for aesthetic reasons. -- David Goodger http://starship.python.net/~goodger Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv |
From: Beni C. <cb...@te...> - 2003-02-20 11:46:22
|
On 2003-02-19, David Goodger wrote: > [David Goodger] > >> That's definitely a "sidebar". According to `DocBook: The > >> Definitive Guide > >> <http://www.docbook.org/tdg/en/html/docbook-x.html>`_, > >> > >> sidebar =8B A portion of a document that is isolated from the > >> main narrative flow > > [Beni Cherniavsky] > > Quoting below that: > > What's your point, with the extra quoting? > To highlight some extra nuances of the definition that you refered to, in contrast to which I wanted to put my ideas, for those that didn't read it. I guess now it could be omited with no harm. > > DocBook does not specify the location of the Sidebar within the > > final displayed flow of text. The wrapper may float or remain > > where it is located. > > The "sidebar" directive could grow "float" and/or "fixed" options > if necessary. > > > It feel a little bit too limited; I feel similarly about "topic". > > > > Currently reST has no general way to specify that something (e.g. > > table) should be floated. While this is a presentation issue, it is > > sits on top of a content issue: most things are intended to be > > presented in-line while some things are well suited to be floated > > (some writers can fall back on putting the later inline too). I > > think a generic "float" directive, with arbitrary content should be > > added. I don't mind the name but I want generic semantics - it would > > wrap arbitrary content, without a requirement that it has 1-2 > > titles, contians no topics, etc. > > I think that individual directives should grow "float" options if and > when required. Alternatively, setting objects "afloat" could be a > presentation decision of the Writer or the target software. > If you go this way, then you don't really need "topic"/"sidebar" distinction. A sidebar becomes a topic with a float option. > A directive with arbitrary content seems too complex to me. Assume it > contained three paragraphs; would each grow a "float" attribute or > would they have to be wrapped by an auxiliary floatable container? I > think the latter. Definitely the later. > In which case, just tack a "float" option/attribute onto the container > and allow *it* to have (reasonably) arbitrary content. > > Not all objects *can* float. In the publishing environments I've > used, only "formal" objects (those with titles and/or numbers, such as > "Table 1" or "Figure 2") are floated; referring to floating "informal" > (untitled/unnumbered) objects from the main text would be problematic. > I remember one publishing environment where *all* formal objects were > floated -- to the top or bottom of the page, usually -- for aesthetic > reasons. > Good point, didn't consider the issue of refering well enough. --=20 Beni Cherniavsky <cb...@tx...> Do not feed the Bugzillas. |
From: David G. <go...@py...> - 2003-02-19 23:17:04
|
[Beni Cherniavsky] > That brings me to the deeper question. Why can't a > topic/blockquote/etc. contain headings? Quick answer: complexity and precedence. It would make the document model too complex. And I know of no serious document model that allows such a construct. I don't consider HTML "serious": it is (or has become) a loose presentation markup. > My feeling for a blockquote or any other contstruct delimited by > increased indentation is that it should be able to contain whatever > the top-level document can contain: The entire point of the "topic" element is that it is a terminal structural node; it can't contain further structure (sections, topics, etc.). "Topic" is analogous to DocBook's "simplesect", but actually usable in more places: "simplesect" can only be the last elements of a structural container. The case of a "sidebar" is a bit different: [David Goodger] > I would suggest an element structure like this (for addition to > spec/docutils.dtd):: > > <!ELEMENT sidebar (title, subtitle?, (%body.elements;)+)> > <!ATTLIST sidebar %basic.atts;> Sidebars are like mini-documents within a document. I almost added something like "sidebars may eventually expand to allow structural elements", but thought "keep it simple for now". Even if we do allow structural elements, I can't see adding more than one level, which may rule out adding "section" to the model (it's recursive). In any case, I'd rather start simple and wait for a valid use case before making it complex. [Beni Cherniavsky] > - True, this is rare that you need complex things inside > blockquotes. It's not the intened use. But sometimes you > need just that. And for some things, like titles [1]_, > nesting would be more natural than adding specific options > (that you must remember!) to every directive... ... > .. [1] Perhaps it even makes sense to make the mapping from > heading style to level inside each blockquote > independent from the mapping of the outer document. You begin to see some of the complexity issues! Are they worth it? > - Disclaimer: I haven't tried out how much these constructs > work. I just talk from my understanding of the spec which > seems to imply that the document consists of 4 levels, so > that lower levels can't contain higher-level constructs: > > 1. sections/transitions > 2. body elements > 3. physical paragraphs > 4. inline markup That's fair. I call (1) "structural elements", and consider paragraphs (3) to be just one instance of (2). I divide body elements into two types: simple, and compound (contain other body elements or subelements). And the spec doesn't just imply this; it's explicit. See <http://docutils.sf.net/spec/doctree.html#element-hierarchy> (the diagram needs to be updated a bit). > I can live with the restrictions on 2 in 3 and 3 and 4 but I > don't see much point in forbidding 1 inside 2. Where do we draw the line? Do we allow sections inside tables? Although being an "organic" invention and therefore potentially riddled with exceptions, documents do tend to follow the structural-body-inline hierarchy. I want to keep the Docutils document model as simple as possible. -- David Goodger http://starship.python.net/~goodger Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv |
From: <po...@or...> - 2003-02-19 21:01:49
|
David Goodger <go...@py...> writes: > The DocBook sidebar has a title, but no subtitle. Off the top of my head, I > would suggest an element structure like this (for addition to > spec/docutils.dtd):: > > <!ELEMENT sidebar (title, subtitle?, (%body.elements;)+)> > <!ATTLIST sidebar %basic.atts;> > > The sidebar element would be included in %structure.model as an alternative > to body elements and topics:: > > <!ENTITY % structure.model > " ( ( (%body.elements; | topic | sidebar)+, > ... > > A simple directive could be used to implement it, similar to "topic" or > admonitions:: > > .. sidebar:: Mandatory Title Text Goes Here > :subtitle: Is Optional > > Regular body elements follow. What do you think of Beni's idea to have something like this:: .. sidebar:: ====================== Title Text Goes Here ====================== ------------------- Optional Subtitle ------------------- Regular body elements follow. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- |
From: David G. <go...@py...> - 2003-02-19 23:17:15
|
Patrick K. O'Brien wrote: > What do you think of Beni's idea to have something like this:: > > .. sidebar:: > > ====================== > Title Text Goes Here > ====================== > > ------------------- > Optional Subtitle > ------------------- > > Regular body elements follow. I actually did consider that form originally, and although it's possible, it would be tricky to program and potentially confusing to readers of the plaintext. How would the sidebar title adornment styles relate to those of the master document? Since a sidebar always has a title, no adornment of the title is necessary: it can be the directive's argument. The subtitle could be an adorned title, or a directive option, or even extracted from the second line of the directive argument:: .. sidebar:: Title Text Here Subtitle Text Here That may be too subtle though. If we do allow structural elements inside a sidebar, it would make sense for the title & subtitle to be adorned also. -- David Goodger http://starship.python.net/~goodger Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv |
From: <po...@or...> - 2003-02-19 23:35:02
|
David Goodger <go...@py...> writes: > Patrick K. O'Brien wrote: > > What do you think of Beni's idea to have something like this:: > > > > .. sidebar:: > > > > ====================== > > Title Text Goes Here > > ====================== > > > > ------------------- > > Optional Subtitle > > ------------------- > > > > Regular body elements follow. > > I actually did consider that form originally, and although it's > possible, it would be tricky to program and potentially confusing to > readers of the plaintext. How would the sidebar title adornment > styles relate to those of the master document? > > Since a sidebar always has a title, no adornment of the title is > necessary: it can be the directive's argument. The subtitle could be > an adorned title, or a directive option, or even extracted from the > second line of the directive argument:: > > .. sidebar:: Title Text Here > Subtitle Text Here > > That may be too subtle though. > > If we do allow structural elements inside a sidebar, it would > make sense for the title & subtitle to be adorned also. I'm prepared for you to make a BDFL pronouncement so I can start implementing the solution you think best at this point in time. And I'd just as soon avoid anything that required tricky programming. So is your original recommendation still the way to proceed? -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- |
From: David G. <go...@py...> - 2003-02-19 23:44:08
|
Patrick K. O'Brien wrote: > I'm prepared for you to make a BDFL pronouncement so I can start > implementing the solution you think best at this point in time. I prefer "For Now" to "For Life". ;-) > And I'd just as soon avoid anything that required tricky programming. > So is your original recommendation still the way to proceed? Sure; go for it. We can change our minds later. -- David Goodger http://starship.python.net/~goodger Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv |
From: <po...@or...> - 2003-02-20 01:32:18
|
David Goodger <go...@py...> writes: > A simple directive could be used to implement it, similar to "topic" or > admonitions:: > > .. sidebar:: Mandatory Title Text Goes Here > :subtitle: Is Optional > > Regular body elements follow. > > This should be added to Docutils itself for general use. Please feel free > to take a first crack at implementing it. I'll be glad to help. I started this and find that I'm mimicking topic quite a bit. Then I realized that I don't understand what topic is for, or why we couldn't just add an optional subtitle to the existing topic directive. Thoughts? -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- |
From: <po...@or...> - 2003-02-20 02:00:29
|
po...@or... (Patrick K. O'Brien) writes: > David Goodger <go...@py...> writes: > > > A simple directive could be used to implement it, similar to "topic" or > > admonitions:: > > > > .. sidebar:: Mandatory Title Text Goes Here > > :subtitle: Is Optional > > > > Regular body elements follow. > > > > This should be added to Docutils itself for general use. Please feel free > > to take a first crack at implementing it. I'll be glad to help. > > I started this and find that I'm mimicking topic quite a bit. Then I > realized that I don't understand what topic is for, or why we couldn't > just add an optional subtitle to the existing topic > directive. Thoughts? This message seems to confirm my suspicions: http://mail.python.org/pipermail/doc-sig/2002-March/002498.html David? -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- |
From: David G. <go...@py...> - 2003-02-20 02:06:21
|
Patrick K. O'Brien wrote: > This message seems to confirm my suspicions: > > http://mail.python.org/pipermail/doc-sig/2002-March/002498.html I think they're different enough to warrant separate existence. -- David Goodger http://starship.python.net/~goodger Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv |
From: David G. <go...@py...> - 2003-02-20 02:03:21
|
Patrick K. O'Brien wrote: > I started this and find that I'm mimicking topic quite a bit. Yes, they're very similar. By all means, refactor the code so it doesn't need to be duplicated. Add a "sidebar" function to docutils.parsers.rst.directives.body, which calls "topic"; refer to "parsed_literal" in the same module. > Then I realized that I don't understand what topic is for, or why we couldn't > just add an optional subtitle to the existing topic directive. Thoughts? Topics and sidebars are different animals. Sidebar has a subtitle; topic doesn't need one. And sidebars float, requiring a different element for different processing. -- David Goodger http://starship.python.net/~goodger Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv |
From: <eng...@ss...> - 2003-02-20 07:29:07
|
On Thu, 19 Feb 2003, Patrick K. O'Brien wrote: > po...@or... (Patrick K. O'Brien) writes: > > > David Goodger <go...@py...> writes: > > > > > A simple directive could be used to implement it, similar to "topic" or > > > admonitions:: > > > > > > .. sidebar:: Mandatory Title Text Goes Here > > > :subtitle: Is Optional > > > > > > Regular body elements follow. could one use .. topic:: the title :class: sidebar might need no change in the parser ? -- BINGO: end to end Eskalation --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6410 Telfs Untermarkt 9 / Tel. ++43-5262-64727 ----+ |