Hello, Rainer M Krug <rai...@krugs.de> writes:
> I see comments as "entities which do not have any impact on the final > product". > > If you regard the org file as the final product, then I > completely agree (I use org mainly for literate programming, and I don't > use any comments unless in linger code blocks, but that is not in > org). But if I use org for writing e.g. presentations in beamer, I might want > to add comments which should not be on the product (slides, article, > handout, ...) but which contain info in the org file. > > So we are talking different levels here. Comments do not alter the final product: they are ignored during export. But there are places where you cannot have comments, at all. If we look at the following example, similar to OP's: Some text # comment Some other text comment do not split the paragraph: there were two paragraphs since the beginning (but still no spoon). It's only disturbing if you think comments can be inserted within paragraphs, which is not the case. This may not be perfect, but, as for me, it's good enough. Another option would be to remove every comment line before parsing the buffer (which is, IIRC, what previous exporter did), but it would only hide the situation for a while. After all I could expect to have comments anywhere, including some places like * Headline # Between an headline and planning info. Update org-agenda.el. SCHEDULED: <2013-07-16 Tue> - item 1 # Some comment between items. Update org-list.el - item 2 #+HEADER: var=2 # A comment between affiliated keywords and true data. Update ob-core.el. #+RESULTS: some-table | a | | a | b | # Comments within rows. Update org-table.el | c | d | And then, the situation would appear again: it's not just about the parser or the exporter. Every part of Org would have to handle comments differently. Again, I think comments are acceptable, once you are aware about their limitations. But, I don't prevent you from opening that can of worms. Regards, -- Nicolas Goaziou
