Re: Upstreaming org-element-ast (was: Improving Emacs' iCalendar support)

[Richard Lawrence <rwl@recursewithless.net>]

Ihor Radchenko <yantar92@posteo.net> writes:

> That's not what you did.
> You did not replicate the calling convention
>  (org-element-create 'type properties '(<child1> <child2> ...))
>
>   (ical:make-ast-node 'test nil '("a" "b" "c"))
>
> will have CHILDREN = '(("a" "b" "c"))
> and pass this argument to `org-element-create' that will faithfully
> create a node with a single child - anonymous node ("a" "b" "c").
>
> You should do
>
>   (apply #'org-element-create type full-props children)

D'oh. You're right; sorry for the noise.

In fact, I had already tried that in a previous iteration, but it didn't
fix the issue(s) I was seeing in the tests and so I had already
backpedaled on it by the time I wrote my previous email. 

I think this bit of the docstring had convinced me by that time that
calling org-element-create via apply wasn't necessary:

> When CHILDREN is a single anonymous node, use its contents as children
> nodes.  

In any case, the issue with passing nil as the &rest argument is what
causes most of the tests to fail. This remains so even once I change the
call to use (apply #'org-element-create ...) as you suggested. This *is*
documented in the Elisp manual, and I guess it makes sense, but I still
find it somewhat unintuitive to reason about.  

So again, at least for all my uses, an additional/alternative interface
to org-element-create that doesn't make children a &rest argument would
be useful. I had hoped I could just make ical:make-ast-node an alias of
org-element-create, but for now I will leave it as a wrapper around
org-element-create with a different calling convention. Otherwise, I
haven't run into anything that would prevent me from using
org-element-ast and I'd be happy to use a more general version of it in
icalendar-ast.el.

Thanks for your help!

Best,
Richard