Nicolas Goaziou <n.goaz...@gmail.com> writes: > 1. an item > # a normal line breaking the list > 1. an item in another list > > but, upon exporting, both items will belong to the same list. This is > just nonsensical.
Users who want comments to be equivalent to empty lines will not write the above. If they do, it's their responsability. >> A simple (setq org-export-ignore-comments t) would put the user in >> the second situation, where comments are deleted before parsing and >> exporting, and treated as standard citizens when manipulating or >> buffers. (Eric's patch goes into that direction.) > > And the direction is wrong... Parsing shouldn't modify the buffer being > parsed, ever. But you can use a hook for that purpose. I didn't suggest that parsing should modify the before: I said "where comments are deleted before parsing and exporting". There should be an easy solution for that. >> Then (setq org-export-ignore-comments nil) would put us in the first >> situation, which is the current one, where comments are defines as >> elements within Org syntax, with some constraints when parsing or >> exporting them (such as separating a paragraph.) >> >> What do you think? > > I still think the same. Comments belong to Org syntax (if they don't, > you can't even fill them correctly, for example). If you redefine them, > there's no easy workaround. I didn't suggest to redefine comments. > You have to change every part of Org that > assumes there will be no comment in its way (lists, agenda, babel, > parser and probably more I can't think of). > > If it's an HTML/ODT export issue, it's far easier to patch the export > back-ends instead. 10 lines of code in each one, maybe. This is a general pre-export issue, it does not depend on the exporters themselves. So again, what prevents us to make it easy for users to treat comments as no-line before parsing and exporting? -- Bastien
