Christian Moe <[email protected]> writes: Sorry for delay in response. Just got to this thread in my todo list.
>> Hmm. What about other greater elements? > > Plain lists and their items are already supported, as are tables, and > they can be indexed into. Dynamic blocks are addressed in the patch. > That leaves > > - greater blocks (center, quote, and special blocks) :: > > These are all already supported: they can be referenced by NAME, and > the full text content is passed. One cannot index into them, but they > can contain NAMEd contents, which can be referenced from Babel. > > - drawers :: Also addressed in my last patch, but I now think that > approach was wrong, and that they should be handled like greater > blocks: full text only. If one wants to reference a specific element > inside a drawer, one can NAME it. Crucially, turning drawer export off > with the =d:nil= option does not make a drawer's contents invisible to > Babel. Ok. And if we ever want to implement indexing, it should not be a blocker. > - footnote definitions :: Could be handled, but why would a Babel user > want to use a footnote as data? I suppose someone would sometimes put > a table or list into a footnote, but then, again, those elements can > themselves be NAMEd. Well. Footnote definitions cannot have affiliated keywords, so they cannot be named. > - inlinetasks :: Semantically, even less reason why they should be used > for Babel data sources. But if they should be handled, I guess they > should treated like other entries. (Confusingly, in my testing, if I > set a =CUSTOM_ID= on an inline task, then =:var x=inlinetask= returns the > text of the whole parent entry, not just the inline task.) Sounds like a bug. > - property drawers :: These are tightly connected with the entries they > belong to and the other planning metadata that is also available as > properties of the entry. Maybe we don't need to handle property > drawers specifically (though something would need to be done for > zeroth-section property drawers). Since metadata can be collected via > columnview we don't strictly need to handle it directly at all. But > for an idea on how to reference entry metadata from Babel more > generally, see below. Right. And they cannot be named. > : #+begin_src elisp :var x=block_name(:eval yes)[0] > > I think you mean: > > : #+begin_src elisp :var x=block_name[:eval yes]()[0] Yes. > This raises the question whether a buffer- or tree-wide :eval setting > with a header-arg property should apply to updating dblocks if the > dblock reference does not specify an :eval setting itself. I think not; > since dblocks are not src blocks, there might be some user confusion > either way, but this way would be worse. +1 > For the same reason, the approach in my last patch, of setting an > :update argument on the referencing src block, was misguided. Yours is > better. > > For clarity, though, it might still be worth giving the argument a > different name (=:update= or =:update-dblock=) from existing Babel args > like =:eval= or =:cache=. I am inclined to agree. Maybe :eval-block to keep the terminology while not creating potential confusion between src blocks and dynamic blocks. >>>> As another data point, :var x=heading-id will return all the text past >>>> metadata (`org-babel-ref-headline-body'). >>> >>> While we're at it, we might want to consider whether it should also read >>> the metadata (and we could do all of the above in one big >>> org-babel-ref-greater-element function). :) OTOH, people can get the >>> metadata via a dblock, which they can now access with this patch. >> >> Do you mean including metadata verbatim? Or via index, akin to what you >> do for dynamic blocks? I guess that points to handling other greater >> elements. > > Does it? I think entry metadata are a specific case, including both > planning information and property drawers, all available as properties, > and we may be interested in all of them, not the property drawer > specifically. Idea for a feature: A specific bracket syntax for > accessing entry properties or lists of properties, with property names > as keys rather than a numeric index, e.g.: > > :var x=entry_id - As now: full text after metadata > :var x=entry_id[CATEGORY] - a named property > :var x=entry_id[CUSTOM_ID,CATEGORY,TAGS,DEADLINE] - multiple > maybe: :var x=entry_id["CATEGORY"] - would we need quotes? > maybe: :var x=entry_id[*] - all properties > maybe: :var x=entry_od[ ] - full text including metadata I see. Yes, sounds useful in theory. But probably an overkill unless we find a use case in practice. Maybe we can alternatively use org-element-like naming - :CATEGORY :CUSTOM_ID, etc. That might be easier to parse. Also, maybe not "*" but something like ALLPROPERTIES (akin ALLTAGS). > I can see this being occasionally useful, though more for doing fun > things with Org documents than for working with data. > > But I don't think it's /necessary/. For Babel purposes, once we are able > to reference a columnview table, we will already be able to reference > entry properties, and planning data can be referenced indirectly via > columnviews. +1 >> This reminds me that lists are special when reading - only the top level >> is considered. (which is awkward, but intentional) > > Yes, why was that, actually? I didn't follow discussions at the time. Looks like it was simply easier to implement. And an attempt to implement nested lists lead to various bugs. So, no specific reason apart from implementation details. https://list.orgmode.org/orgmode/[email protected]/ -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
