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

[Richard Lawrence <rwl@recursewithless.net>]

Hi Ihor,

Ihor Radchenko <yantar92@posteo.net> writes:

> The main question is making things usable outside Org mode.
> And that's where your work is the most valuable.
> So, it was me who is waiting for your input before upstreaming :)

Got it! I sat down yesterday and tried to convert to using
org-element-ast, and I've run into a couple of questions:

1) Is there any way to use my own list of standard-properties? In
   particular, besides :begin, :end, :contents-begin, :contents-end, I'd
   like to have :value-begin and :value-end as standard properties, and
   always include (:value) in :secondary. If there's no way to do that
   yet, I think it would be useful to add for use outside of org.
   
2) I'm finding org-element-create rather unintuitive to work with, I
   think because of its &rest argument for children and the handling of
   "anonymous" nodes.

   In all my use cases, I build up children as an explicit list of nodes
   before calling icalendar-make-ast-node, which stores the list in
   the children slot, and returns that list from icalendar-ast-node-children.

   An interface like
     (org-element-create type props children)
   would be sufficient for me, where children is a list of
   nodes (and hence can be nil).

   As it is, I can't figure out how to call org-element-create and
   org-element-contents in the right way to set the contents of a node
   to a list of other nodes, and return that list from
   org-element-contents.

   I always seem to end up with an extra level of nesting. 
   e.g. Instead of (child1 child2 child3 ...)
   org-element-contents returns ((child1 child2 child3 ...)).
   Likewise, if there are no children, instead of nil it returns (nil).
   I can't figure out why this happens; as far as I can tell, I'm
   calling both org-element-create and org-element-contents in the right
   way.

   I tried to write a wrapper for org-element-create using apply, with
   children as the last argument, like
     (apply #'org-element-create type props children)
   but that didn't help. I also tried just unconditionally unwrapping
   the list returned by org-element-contents by just taking its car. But
   (if I remember right) that seemed to create one level too *few* of
   nesting in at least some cases, such that org-element-contents would
   return stuff from the properties list.

   Can you help me understand what the right thing for me to do here is?
   All I want to do is store a list of child nodes at construction time,
   and get that list back later on, which seems like it should be a
   simple thing to do.

   In any case, it might be worth reviewing the interfaces and
   docstrings for these functions, because there is something about how
   they work that I clearly don't understand yet, and might be
   surprising to other library consumers.

Hope that's useful feedback!

Best,
Richard