[-- Attachment #1: Type: text/plain, Size: 1501 bytes --] Hi Carsten, During the weekend, I found and fixed two bugs that exist in HTML/DocBook exporters (see the following descriptions). I am attaching a patch for the fixes at the end of this email. 1. Bug One: two consecutive lists with different list types at the same level are exported as *one* list. For example, the following two lists 1. Ordered List Item 1 2. Ordered List Item 2 - Itemized List Item 1 - Itemized List Item 2 - Itemized List Item 3 are exported as one ordered list in HTML (see below, similar problem also exist in DocBook). : <ol> : <li> : Ordered List Item 1 : </li> : <li> : Ordered List Item 2 : : </li> : <li> : Itemized List Item 1 : </li> : <li> : Itemized List Item 2 : </li> : <li> : Itemized List Item 3 : : </li> : </ol> 2. Bug Two: a paragraph *immediately* after a block like quote, verse, centered block, example, etc. is not wrapped into paragraph tags (<p>...</p> in HTML or <para>...</para> in DocBook). While it is not a big deal for HTML exporter, this bug makes exported DocBook XML document invalid. The following lines can reproduce this bug: : Code line one : Code line two This is a paragraph immediately after the above code block without an empty line before it, and it is NOT wrapped in a paragraph (<p> in HTML or <para> in DocBook) in exported format. Please let me know if you see any problems in the fix. Thanks, Baoqiu [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: consecutive-lists.diff --] [-- Type: text/x-patch, Size: 3782 bytes --] diff --git a/lisp/org-docbook.el b/lisp/org-docbook.el index 3739181..0b87ada 100644 --- a/lisp/org-docbook.el +++ b/lisp/org-docbook.el @@ -606,6 +606,7 @@ publishing directory." ;; End of quote section? (when (and inquote (string-match "^\\*+ " line)) (insert "]]>\n</programlisting>\n") + (org-export-docbook-open-para) (setq inquote nil)) ;; Inside a quote section? (when inquote @@ -624,7 +625,8 @@ publishing directory." (not (string-match "^[ \t]*\\(:.*\\)" (car lines)))) (setq infixed nil) - (insert "]]>\n</programlisting>\n")) + (insert "]]>\n</programlisting>\n") + (org-export-docbook-open-para)) (throw 'nextline nil)) ;; Protected HTML @@ -681,12 +683,14 @@ publishing directory." (when (equal "ORG-BLOCKQUOTE-END" line) (org-export-docbook-close-para-maybe) (insert "</blockquote>\n") + (org-export-docbook-open-para) (throw 'nextline nil)) ;; End of verses (when (equal "ORG-VERSE-END" line) (insert "</literallayout>\n</blockquote>\n") (setq inverse nil) + (org-export-docbook-open-para) (throw 'nextline nil)) ;; Text centering. Element <para role="centered"> does not @@ -704,6 +708,7 @@ publishing directory." (org-export-docbook-close-para-maybe) (insert "</entry></row></tbody>\n" "</tgroup>\n</informaltable>\n") + (org-export-docbook-open-para) (throw 'nextline nil)) ;; Make targets to anchors. Note that currently FOP does not @@ -969,7 +974,9 @@ publishing directory." (setq didclose nil) (while (and in-local-list (or (and (= ind (car local-list-indent)) - (not starter)) + (or (not starter) + (not (equal item-type + (car local-list-type))))) (< ind (car local-list-indent)))) (setq didclose t) (let ((listtype (car local-list-type))) diff --git a/lisp/org-exp.el b/lisp/org-exp.el index df5c6a5..a8a3dfc 100644 --- a/lisp/org-exp.el +++ b/lisp/org-exp.el @@ -3687,6 +3687,7 @@ lang=\"%s\" xml:lang=\"%s\"> ;; end of quote section? (when (and inquote (string-match "^\\*+ " line)) (insert "</pre>\n") + (org-open-par) (setq inquote nil)) ;; inside a quote section? (when inquote @@ -3706,7 +3707,8 @@ lang=\"%s\" xml:lang=\"%s\"> (not (string-match "^[ \t]*:\\(\\([ \t]\\|$\\)\\(.*\\)\\)" (car lines)))) (setq infixed nil) - (insert "</pre>\n")) + (insert "</pre>\n") + (org-open-par)) (throw 'nextline nil)) ;; Protected HTML @@ -3740,6 +3742,7 @@ lang=\"%s\" xml:lang=\"%s\"> (when (equal "ORG-BLOCKQUOTE-END" line) (org-close-par-maybe) (insert "\n</blockquote>\n") + (org-open-par) (throw 'nextline nil)) (when (equal "ORG-VERSE-START" line) (org-close-par-maybe) @@ -3749,6 +3752,7 @@ lang=\"%s\" xml:lang=\"%s\"> (when (equal "ORG-VERSE-END" line) (insert "</p>\n") (setq inverse nil) + (org-open-par) (throw 'nextline nil)) (when (equal "ORG-CENTER-START" line) (org-close-par-maybe) @@ -3758,6 +3762,7 @@ lang=\"%s\" xml:lang=\"%s\"> (when (equal "ORG-CENTER-END" line) (org-close-par-maybe) (insert "\n</div>") + (org-open-par) (throw 'nextline nil)) (when inverse (let ((i (org-get-string-indentation line))) @@ -4066,7 +4071,9 @@ lang=\"%s\" xml:lang=\"%s\"> (setq didclose nil) (while (and in-local-list (or (and (= ind (car local-list-indent)) - (not starter)) + (or (not starter) + (not (equal item-type + (car local-list-type))))) (< ind (car local-list-indent)))) (setq didclose t) (org-close-li (car local-list-type)) [-- Attachment #3: Type: text/plain, Size: 204 bytes --] _______________________________________________ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Hi Baoqiu, On Apr 6, 2009, at 11:37 PM, Baoqiu Cui wrote: > Hi Carsten, > > During the weekend, I found and fixed two bugs that exist in > HTML/DocBook exporters (see the following descriptions). I am > attaching > a patch for the fixes at the end of this email. > > 1. Bug One: two consecutive lists with different list types at the > same > level are exported as *one* list. For example, the following two > lists > > 1. Ordered List Item 1 > 2. Ordered List Item 2 > > - Itemized List Item 1 > - Itemized List Item 2 > - Itemized List Item 3 This is, actually, not a bug but on purpose. List boundaries are set by indentation, and the list type is set by the first item. I prefer to keep it that way. In the same way, the actual numbers in an ordered list are ignored and the list is renumbered on export. > > are exported as one ordered list in HTML (see below, similar problem > also exist in DocBook). > > : <ol> > : <li> > : Ordered List Item 1 > : </li> > : <li> > : Ordered List Item 2 > : > : </li> > : <li> > : Itemized List Item 1 > : </li> > : <li> > : Itemized List Item 2 > : </li> > : <li> > : Itemized List Item 3 > : > : </li> > : </ol> > > 2. Bug Two: a paragraph *immediately* after a block like quote, verse, > centered block, example, etc. is not wrapped into paragraph tags > (<p>...</p> in HTML or <para>...</para> in DocBook). While it is > not > a big deal for HTML exporter, this bug makes exported DocBook XML > document invalid. > > The following lines can reproduce this bug: > > : Code line one > : Code line two > This is a paragraph immediately after the above code block without > an > empty line before it, and it is NOT wrapped in a paragraph (<p> in > HTML or <para> in DocBook) in exported format. > > Please let me know if you see any problems in the fix. I would like to fix this bug, and if you send me a patch just for this, I'd be happy to apply it. - Carsten
[-- Attachment #1: Type: text/plain, Size: 1835 bytes --] Carsten Dominik <carsten.dominik@gmail.com> writes: >> 1. Bug One: two consecutive lists with different list types at the >> same >> level are exported as *one* list. For example, the following two >> lists >> >> 1. Ordered List Item 1 >> 2. Ordered List Item 2 >> >> - Itemized List Item 1 >> - Itemized List Item 2 >> - Itemized List Item 3 > > This is, actually, not a bug but on purpose. > List boundaries are set by indentation, and the > list type is set by the first item. I prefer to keep it that way. > In the same way, the actual numbers in an ordered list are ignored > and the list is renumbered on export. Thanks for the explanation, Carsten! This makes perfect sense to me. No wonder I found the same "problem" in function `org-beginning-of-item-list'. :-) If a lot of people like to mix different list types together in the way I showed above, I would prefer that Org mode has finer support for this. But for now, I think we should keep the existing way. >> 2. Bug Two: a paragraph *immediately* after a block like quote, verse, >> centered block, example, etc. is not wrapped into paragraph tags >> (<p>...</p> in HTML or <para>...</para> in DocBook). While it is >> not >> a big deal for HTML exporter, this bug makes exported DocBook XML >> document invalid. >> >> The following lines can reproduce this bug: >> >> : Code line one >> : Code line two >> This is a paragraph immediately after the above code block without >> an >> empty line before it, and it is NOT wrapped in a paragraph (<p> in >> HTML or <para> in DocBook) in exported format. >> >> Please let me know if you see any problems in the fix. > > I would like to fix this bug, and if you send me a patch just > for this, I'd be happy to apply it. OK. I am attaching the new patch at the end. Thanks, Baoqiu [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: para-after-block.diff --] [-- Type: text/x-patch, Size: 2950 bytes --] diff --git a/lisp/org-docbook.el b/lisp/org-docbook.el index 70a707b..13b46ed 100644 --- a/lisp/org-docbook.el +++ b/lisp/org-docbook.el @@ -607,6 +607,7 @@ publishing directory." ;; End of quote section? (when (and inquote (string-match "^\\*+ " line)) (insert "]]>\n</programlisting>\n") + (org-export-docbook-open-para) (setq inquote nil)) ;; Inside a quote section? (when inquote @@ -625,7 +626,8 @@ publishing directory." (not (string-match "^[ \t]*\\(:.*\\)" (car lines)))) (setq infixed nil) - (insert "]]>\n</programlisting>\n")) + (insert "]]>\n</programlisting>\n") + (org-export-docbook-open-para)) (throw 'nextline nil)) ;; Protected HTML @@ -682,11 +684,13 @@ publishing directory." (when (equal "ORG-BLOCKQUOTE-END" line) (org-export-docbook-close-para-maybe) (insert "</blockquote>\n") + (org-export-docbook-open-para) (throw 'nextline nil)) ;; End of verses (when (equal "ORG-VERSE-END" line) (insert "</literallayout>\n</blockquote>\n") + (org-export-docbook-open-para) (setq inverse nil) (throw 'nextline nil)) @@ -705,6 +709,7 @@ publishing directory." (org-export-docbook-close-para-maybe) (insert "</entry></row></tbody>\n" "</tgroup>\n</informaltable>\n") + (org-export-docbook-open-para) (throw 'nextline nil)) ;; Make targets to anchors. Note that currently FOP does not diff --git a/lisp/org-html.el b/lisp/org-html.el index b422066..b41ef3b 100644 --- a/lisp/org-html.el +++ b/lisp/org-html.el @@ -761,6 +761,7 @@ lang=\"%s\" xml:lang=\"%s\"> ;; end of quote section? (when (and inquote (string-match "^\\*+ " line)) (insert "</pre>\n") + (org-open-par) (setq inquote nil)) ;; inside a quote section? (when inquote @@ -780,7 +781,8 @@ lang=\"%s\" xml:lang=\"%s\"> (not (string-match "^[ \t]*:\\(\\([ \t]\\|$\\)\\(.*\\)\\)" (car lines)))) (setq infixed nil) - (insert "</pre>\n")) + (insert "</pre>\n") + (org-open-par)) (throw 'nextline nil)) ;; Protected HTML @@ -814,6 +816,7 @@ lang=\"%s\" xml:lang=\"%s\"> (when (equal "ORG-BLOCKQUOTE-END" line) (org-close-par-maybe) (insert "\n</blockquote>\n") + (org-open-par) (throw 'nextline nil)) (when (equal "ORG-VERSE-START" line) (org-close-par-maybe) @@ -822,6 +825,7 @@ lang=\"%s\" xml:lang=\"%s\"> (throw 'nextline nil)) (when (equal "ORG-VERSE-END" line) (insert "</p>\n") + (org-open-par) (setq inverse nil) (throw 'nextline nil)) (when (equal "ORG-CENTER-START" line) @@ -832,6 +836,7 @@ lang=\"%s\" xml:lang=\"%s\"> (when (equal "ORG-CENTER-END" line) (org-close-par-maybe) (insert "\n</div>") + (org-open-par) (throw 'nextline nil)) (when inverse (let ((i (org-get-string-indentation line))) [-- Attachment #3: Type: text/plain, Size: 204 bytes --] _______________________________________________ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
On 2009-04-09 06:27 +0100, Baoqiu Cui wrote:
>>> level are exported as *one* list. For example, the following two
>>> lists
>>>
>>> 1. Ordered List Item 1
>>> 2. Ordered List Item 2
>>>
>>> - Itemized List Item 1
>>> - Itemized List Item 2
>>> - Itemized List Item 3
>>
>> This is, actually, not a bug but on purpose.
>> List boundaries are set by indentation, and the
>> list type is set by the first item. I prefer to keep it that way.
>> In the same way, the actual numbers in an ordered list are ignored
>> and the list is renumbered on export.
>
> Thanks for the explanation, Carsten! This makes perfect sense to me.
> No wonder I found the same "problem" in function
> `org-beginning-of-item-list'. :-)
>
> If a lot of people like to mix different list types together in the
> way I showed above, I would prefer that Org mode has finer support for
> this. But for now, I think we should keep the existing way.
mixing lists is easy to do. Just use Alt + <left/right> to
decrease/increase the item's indentation.
I think a way to terminate list is quite important, particularly when
embedding list inside an article. I always found it difficult to start a
new paragrah after a list because when you type TAB on the first line of
the new paragraph it indents it to the level that shows it is part of
the last list item.
How about making double blank line do that?
Cheers,
--
.: Leo :. [ sdl.web AT gmail.com ] .: I use Emacs :.
Hi Leo, Leo <sdl.web@gmail.com> writes: >>>> 1. Ordered List Item 1 >>>> 2. Ordered List Item 2 >>>> >>>> - Itemized List Item 1 >>>> - Itemized List Item 2 >>>> - Itemized List Item 3 > mixing lists is easy to do. Just use Alt + <left/right> to > decrease/increase the item's indentation. Increasing the indentation of the 2nd list (itemized list) makes it part of item 2 of the ordered list, doesn't it? So, instead of having two lists at the same level, we will end up having only one list -- the ordered list. If these two lists are not nested in another outer, higher level list, decreasing the indentation of 2nd list would work, but it won't look very good. > I think a way to terminate list is quite important, particularly when > embedding list inside an article. I always found it difficult to start a > new paragrah after a list because when you type TAB on the first line of > the new paragraph it indents it to the level that shows it is part of > the last list item. > > How about making double blank line do that? I don't have the habit of hitting TAB to start a new paragraph, so I don't have this problem. :-) Nevertheless, having an option to disable indentation based on a list two-blank line above seems useful. Baoqiu
On Apr 9, 2009, at 7:27 AM, Baoqiu Cui wrote: > Carsten Dominik <carsten.dominik@gmail.com> writes: > >>> 1. Bug One: two consecutive lists with different list types at the >>> same >>> level are exported as *one* list. For example, the following two >>> lists >>> >>> 1. Ordered List Item 1 >>> 2. Ordered List Item 2 >>> >>> - Itemized List Item 1 >>> - Itemized List Item 2 >>> - Itemized List Item 3 >> >> This is, actually, not a bug but on purpose. >> List boundaries are set by indentation, and the >> list type is set by the first item. I prefer to keep it that way. >> In the same way, the actual numbers in an ordered list are ignored >> and the list is renumbered on export. > > Thanks for the explanation, Carsten! This makes perfect sense to me. > No wonder I found the same "problem" in function > `org-beginning-of-item-list'. :-) > > If a lot of people like to mix different list types together in the > way > I showed above, I would prefer that Org mode has finer support for > this. Hi Baoqiu, I really don't see why. Under what circumstances would you want to mix list types like this, without at least on little transition sentence between the lists? I cannot remember any occasion when I would have wanted this to be possible. > But for now, I think we should keep the existing way. > >>> 2. Bug Two: a paragraph *immediately* after a block like quote, >>> verse, >>> centered block, example, etc. is not wrapped into paragraph tags >>> (<p>...</p> in HTML or <para>...</para> in DocBook). While it is >>> not >>> a big deal for HTML exporter, this bug makes exported DocBook XML >>> document invalid. >>> >>> The following lines can reproduce this bug: >>> >>> : Code line one >>> : Code line two >>> This is a paragraph immediately after the above code block without >>> an >>> empty line before it, and it is NOT wrapped in a paragraph (<p> in >>> HTML or <para> in DocBook) in exported format. >>> >>> Please let me know if you see any problems in the fix. >> >> I would like to fix this bug, and if you send me a patch just >> for this, I'd be happy to apply it. > > OK. I am attaching the new patch at the end. Thanks, in particular also for preparing the patch against the new file org-html.el. I have applied it. - Carsten
Carsten Dominik <carsten.dominik@gmail.com> writes: > Hi Baoqiu, > > I really don't see why. Under what circumstances would you > want to mix list types like this, without at least on little > transition sentence between the lists? I cannot remember any > occasion when I would have wanted this to be possible. This may be something that occasionally happens to me: I sometimes mix list types (at the same indentation level) when I take *very* quick notes during brainstorming discussions or when watching Google Tech Talks. There is no time to add a little transition sentence between the lists. I was surprised once or twice when two different lists were merged into one after I hit M-<RET> at the end of one item in the second list. Don't know if other people feel this little inconvenience too. If there is no much demand, there is no point to support this feature. > Thanks, in particular also for preparing the patch > against the new file org-html.el. I have applied > it. Thanks for applying the patch, and for restructuring the exporter code! Baoqiu
On Thu, 9 Apr 2009 12:33:55 +0200
Carsten Dominik <carsten.dominik@gmail.com> wrote:
> I really don't see why. Under what circumstances would you
> want to mix list types like this, without at least on little
> transition sentence between the lists? I cannot remember any
> occasion when I would have wanted this to be possible.
>
I can't resist a challenge like that!
I often write quick lists summarising the advantages and disadvantages
of a proposed solution to a problem, eg:
+ It is faster
- It is more expensive
+ It uses less memory
- It is a horrible colour
But I don't think it is worth trying to support something like this.
On Apr 9, 2009, at 8:29 PM, Baoqiu Cui wrote: > Carsten Dominik <carsten.dominik@gmail.com> writes: > >> Hi Baoqiu, >> >> I really don't see why. Under what circumstances would you >> want to mix list types like this, without at least on little >> transition sentence between the lists? I cannot remember any >> occasion when I would have wanted this to be possible. > > This may be something that occasionally happens to me: I sometimes mix > list types (at the same indentation level) when I take *very* quick > notes during brainstorming discussions or when watching Google Tech > Talks. There is no time to add a little transition sentence between > the > lists. I see how this can happen during taking notes. However, I still think that the current behavior is the right one, and I think that changing things already during a M-RET is better than waiting for publishing to merge them silently. - Carsten > > I was surprised once or twice when two different lists were merged > into > one after I hit M-<RET> at the end of one item in the second list. > > Don't know if other people feel this little inconvenience too. If > there > is no much demand, there is no point to support this feature. > >> Thanks, in particular also for preparing the patch >> against the new file org-html.el. I have applied >> it. > > Thanks for applying the patch, and for restructuring the exporter > code! > > Baoqiu > > > > _______________________________________________ > Emacs-orgmode mailing list > Remember: use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode
On Apr 9, 2009, at 11:03 PM, Mike Newman wrote: > > > On Thu, 9 Apr 2009 12:33:55 +0200 > Carsten Dominik <carsten.dominik@gmail.com> wrote: > >> I really don't see why. Under what circumstances would you >> want to mix list types like this, without at least on little >> transition sentence between the lists? I cannot remember any >> occasion when I would have wanted this to be possible. >> > > I can't resist a challenge like that! > > I often write quick lists summarising the advantages and disadvantages > of a proposed solution to a problem, eg: > > + It is faster > - It is more expensive > + It uses less memory > - It is a horrible colour This is a good application, I use - + It is faster - - It is more expensive - + It uses less memory - - It is a horrible colour for things like this. - Carsten > > But I don't think it is worth trying to support something like this. > > > _______________________________________________ > Emacs-orgmode mailing list > Remember: use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode