bug#74994: Upstreaming org-element-ast (was: Improving Emacs' iCalendar support)

[Richard Lawrence <rwl@recursewithless.net>]

Richard Lawrence <rwl@recursewithless.net> writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> In bug#74994, Richard made a decision not to use org-element-ast and
>> instead implement a custom parser generator.
>>
>> Richard, is there any specific reason why you had to make things from
>> scratch? May org-element-ast be changed to fit your needs?
>>
>> If org-element-ast is not going to be useful outside Org mode, I see no
>> good reason to invest time into upstreaming it, after all.
>
> No, it was more that, as things stood, I wanted to wait and see what
> would happen with upstreaming org-element-ast. My idea was to make it
> easy to switch once that happened, but not to wait to make progress in
> the meantime, that's all.

Ah, looking over this again, there was one thing that I felt didn't fit
very well with org-element-ast: in iCalendar, "properties" can have both
a "value" and a list of "parameters". These are different types of
objects and it's most natural and useful not to lump them together, but
in the Org element AST they would probably both just be "contents" of a
property node (i.e., child nodes). Thus, in my draft icalendar-ast.el,
instead of using

(TYPE PROPERTIES CONTENTS)

as the basic representation for a node, I used

(TYPE META VALUE CHILDREN).

The org-element-ast representation is obviously capable of making the
distinction between values and parameters in some other way; but it's
pretty much the only example I can think of where I felt the
org-element-ast representation might not be the best for the needs of
iCalendar.

Best,
Richard