Christian Moe <[email protected]> writes:
>> Note that a block may contain multiple elements. Those elements may or
>> may not be tables.
>
>> Let's think about it more generally. What if we talk about something
>> like drawer rather than dynamic block. What would be the most sensible
>> way to include drawer contents?
>
> This patch supports multiple elements, and drawers as well as dblocks.
Hmm. What about other greater elements?
>> What we can do, is allowing
>> block_name[] -> full contents
> Implemented.
>
>> block_name[0] -> first element
>> block_name[0:2] -> first two elements
>> for first two rows of table inside block -> block_name[0,-2:-1]
> ^^^^^
> last
>
> Implemented.
>
> I have included the default case
>
> block_name -> first element (equal to block_name[0])
>
> This is to simplify things for people accessing the basic built-in
> dblock types (colview, clocktable), which only have one element.
> However, unlike my previous patch, they still have to add 0 as the first
> dimension if they /want/ to index into the clocktable via the variable
> reference, the clocktable will have a 3D index. We might want to make it
> more intuitive still by making the value an element if there's only one,
> and a list if there are several, so that indexing into the clocktable
> with a 2D index works as one might expect. (But I only thought of that
> after preparing everything for this mail, so I leave that for another
> iteration.) WDYT?
Sounds excessive. I'd rather keep things simple in the code and only add
features if people request such additional simplification.
> About whether or not to update the referenced dblock:
>
>>> Maybe block_name(:eval yes), block_name(:eval no),
>>> block_name(:eval auto) == block_name
>
> I'm not sure it's a good idea to use the :eval header. What about
> wanting a buffer-wide :eval setting, but wanting src blocks and dblocks
> to behave differently?
> In the patch I've introduced an :update pseudo-header ('pseudo' because
> dynamic blocks don't have babel headers) and code to update the dblock
> if it is present, regardless of value. But we may want to discuss these
> choices further. Maybe we need a more specific name (:update-dblock?),
> or a choice of yes|no|auto values as you suggested.
Buffer-wide settings do not affect reference resolution, AFAIU. Or do I
miss something?
Another possible name is :cache yes/no.
>> 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.
> + ,#+NAME: drawer-example
> + ,:DETAILS:
> + This drawer contains a paragraph, a table, and a list.
> + | 1 | 2 |
> + - a
> + - b
> + ,:END:
> +
> + ,#+BEGIN_SRC emacs-lisp :var x=drawer-example[2,1]
> + (format "The second item in the list is %s" x)
> + ,#+END_SRC
> +
> + ,#+RESULTS:
> + : The second item in the list is b
> +#+end_example
This reminds me that lists are special when reading - only the top level
is considered. (which is awkward, but intentional)
--
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>
