One inconsistency with org-element parsers

One inconsistency with org-element parsers

[akater]

I want to make it easier for users to define custom non-inline blocks
(and operations on them). So I studied parsers in =org-element.el= and
stumbled upon the following seeming inconsistency:

Plists for =comment-block=, =example-block=, =export-block=, =src-block=
all have neither ~:contents-begin~ nor ~:contents-end~ in them, while
plists for =center-block=, =quote-block=, =verse-block= have both.

Parameters ~contents-begin~ and ~contents-end~ are defined almost
everywhere (the only exception is, =src-block= parser never defines
~contents-begin~) but are not returned in plists by four parsers
mentioned.

Should something be done about this? I'm removing some boilerplate from
the parsers and could reuse existing parameters to put them into plists
but I don't understand the semantics yet so won't necessarily be able to
add ~:contents-begin~ to src-blocks. Maybe they are simply unnecessary
in these plists?

Re: One inconsistency with org-element parsers

[Nicolas Goaziou]

Hello,

akater <nuclearspace@gmail.com> writes:

> I want to make it easier for users to define custom non-inline blocks
> (and operations on them). So I studied parsers in =org-element.el= and
> stumbled upon the following seeming inconsistency:
>
> Plists for =comment-block=, =example-block=, =export-block=, =src-block=
> all have neither ~:contents-begin~ nor ~:contents-end~ in them, while
> plists for =center-block=, =quote-block=, =verse-block= have both.

:contents-begin and :contents-end means there is something to parse
in-between. It doesn't make sense for the block types in the first
category, where the contents are not meant to be Org syntax.

Regards,

-- 
Nicolas Goaziou