Re: One inconsistency with org-element parsers
Hello, akater 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
One inconsistency with org-element parsers
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?
