From: martin f k. <ma...@ma...> - 2006-03-05 11:41:09
|
I can write lists without empty lines between items: * A * B * C However, if I nest a list, I have to keep an empty line before and after: * A * B - 1 - 2 * C If I do not do that, the rst2html script produces e.g. "<li>B - 1 - 2</li>". That is: it does not recognise the nested list as a list. Is there a reason this is required? Would it be difficult to extend the parser to work with compact lists too? --=20 martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck =20 invalid/expired pgp (sub)keys? use subkeys.pgp.net as keyserver! spamtraps: mad...@ma... =20 why do they sterilise the needle for lethal injections? |
From: David G. <go...@py...> - 2006-03-06 16:07:08
Attachments:
signature.asc
|
[martin f krafft] > I can write lists without empty lines between items: > > * A > * B > * C > > However, if I nest a list, I have to keep an empty line before and > after: > > * A > * B > > - 1 > - 2 > > * C > > If I do not do that, the rst2html script produces e.g. "<li>B > - 1 - 2</li>". That is: it does not recognise the nested list as > a list. > > Is there a reason this is required? Yes. There is too much ambiguity otherwise: For example, a paragraph could contain an equation like "2 - 1 =3D 1". Such an accidental line wrapping would have unfortunate and unintended results. I'm sure there are other, better examples out there (check the docs & list archives), but this is the core. You're actually approaching this from the wrong direction. Blank lines between list items *may* be omitted as a *convenience*. Not even that is 100% unambiguous, but the convenience is worth the ambiguity. In the example you provide the "omitted blank line" would be between a paragraph and a (sub)list following the paragraph, and that's just too much. The cost of the ambiguity is too high here, far outweighing any convenience. > Would it be difficult to extend the parser to work with compact > lists too? I'd say it would be close to impossible. The reST parser operates in a 2-dimensional way. When the "*" marker for a bullet list item is seen, the item contents are extracted as a rectangle, and then parsed recursively. Look at your example in that way, and you'll see the difficulty. The syntax diagram illustrates this: +------+-----------------------+ | "- " | list item | +------| (body elements)+ | +-----------------------+ -- http://docutils.sf.net/docs/ref/rst/restructuredtext.html#bullet-l= ists --=20 David Goodger <http://python.net/~goodger> |
From: martin f k. <ma...@ma...> - 2006-03-07 11:58:02
|
also sprach David Goodger <go...@py...> [2006.03.06.1502 +0100]: > > Is there a reason this is required? >=20 > Yes. There is too much ambiguity otherwise: I should have known you guys already considered all of this. Sorry for the noise and thanks for the explanation. --=20 martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck =20 invalid/expired pgp (sub)keys? use subkeys.pgp.net as keyserver! spamtraps: mad...@ma... =20 "a scientist once wrote that all truth passes through three stages: first it is ridiculed, then violently opposed and eventually, accepted as self-evident." -- schopenhauer |
From: Felix W. <Fel...@gm...> - 2006-04-01 21:26:24
|
David Goodger wrote: > [ > - foo > - A > - B > - bar > ] > > In the example you provide the "omitted blank line" would be between a > paragraph and a (sub)list following the paragraph, and that's just too > much. The cost of the ambiguity is too high here, far outweighing any > convenience. I guess that this is something new users run into very often, and it's not particularly WYSIWYG because in the HTML rendering you do *not* have a blank line in between. I certainly see that it's logical to disallow such nested lists because of the 2-dimensional parsing, but maybe, just as it's possible to allow omitting the blank line between list items, it could be possible to allow omitting the blank lines around nested lists. I would *not* allow this:: * This is a wrapped line. - Sublist. But as long as we stick to single-line list items, like this ... :: * This is a list item. - This is a nested list. ..., I think it *might* be OK to recognize this (probably implemented as a special syntax construct). After all, if a nested list is not intended, the first character can still be escaped. I haven't considered all implications, but at a first glance I think it would be a nice thing to have. -- For private mail please ensure that the header contains 'Felix Wiemann'. "the number of contributors [...] is strongly and inversely correlated with the number of hoops each project makes a contributing user go through." -- ESR |
From: David G. <go...@py...> - 2006-04-01 23:25:09
Attachments:
signature.asc
|
[Felix Wiemann] > I guess that this is something new users run into very often, and it's > not particularly WYSIWYG because in the HTML rendering you do *not* hav= e > a blank line in between. Too bad. New users just have to learn a little discipline. > I certainly see that it's logical to disallow such nested lists because= > of the 2-dimensional parsing, but maybe, just as it's possible to allow= > omitting the blank line between list items, it could be possible to > allow omitting the blank lines around nested lists. The two cases are not comparable; they're completely different. > I would *not* allow this:: >=20 > * This is a wrapped > line. > - Sublist. >=20 > But as long as we stick to single-line list items, like this ... :: >=20 > * This is a list item. > - This is a nested list. If you allow the latter, you must also allow the former. If you don't, it's just an arbitrary restriction. > ..., I think it *might* be OK to recognize this (probably implemented a= s > a special syntax construct). After all, if a nested list is not > intended, the first character can still be escaped. Escaping should be for exceptional cases only. > I haven't considered all implications, but at a first glance I think it= > would be a nice thing to have. I have considered all the implications: -1. --=20 David Goodger <http://python.net/~goodger> |