Re: Should comments break paragraphs?

[Bastien <bzg@gnu.org>]

Nicolas Goaziou <n.goaziou@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