Bastien <b...@gnu.org> writes: > Nicolas Goaziou <n.goaz...@gmail.com> writes: >> 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.
Yes, a hook, as I suggested: (defun my-comment-removal (backend) (delete-matching-lines "^[ \t]*#\\( \\|$\\)")) (add-hook 'org-export-before-parsing-hook 'my-comment-removal) I maintain it is dangerous to make it a default (or even make it easier than that) because it will cause a discrepancy between the real buffer contents and what is really parsed. It can create strange things, really. > I didn't suggest to redefine comments. Of course you did. You said comments should be available anywhere but in source blocks, didn't you? It isn't possible without redefining them in Org. >> 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. What you want here is to give comments a special meaning just before export, even though they don't have it otherwise. As an example, you can remove the comment here just before export: text # comment text but `org-element-at-point' will still see two paragraphs and a comment between them nonetheless. But, IIUC, the problem the OP wants to solve is different: he wants the example above to be treated as a paragraph, not as two of them. In fact this is more about paragraphs than comments (i.e. paragraphs definition in targeted back-ends is different than Org's). > So again, what prevents us to make it easy for users to treat comments > as no-line before parsing and exporting? It is already easy, see hook above. Nothing prevents you from making it easier. But this is wrong. Regards, -- Nicolas Goaziou