Ihor Radchenko <[email protected]> writes: > Christian Moe <[email protected]> writes: >> I submit a patch with one way to solve it: Get org-babel-ref-resolve to >> check if we're at a dynamic block. If so, update it, then move one line >> forward and resolve the first element in the content of the dynamic >> block instead. Then the existing machinery of org-babel-ref-resolve and >> org-babel-read-element can handle it depending on whether it's a table, >> a paragraph with a time stamp, a list, or something else. > > Note that a block may contain multiple elements. > Those elements may or may not be tables.
Yes, I did take that into account. You made me think of a maybe better approach that I sketch below, but let me explain the thinking behind the patch first: As for different kinds of elements, this patch should work not only for tables but for all element types that Babel can read: tables, lists, paragraphs, src blocks, which is more types than are written by the built-in block types (or the examples in the docs). As for multiple elements in a block, I'd argue that reading the first element should do, because: 1. Reading one element suffices for clocktable, columnview, and block-update-time. 2. When Babel references a named block it always reads just (part of) one data structure anyway. 3. The constraints on users are reasonable: if you want to use dynamic blocks as arguments to src blocks, use a write function that places the data you want first; if you want more than one data structure, use several dynamic blocks. That said, we could also think about reading a multi-element dblock as a list of lists. This might be helpful for some hypothetical dblocks, but would be cumbersome for the built-in types with only one element and might introduce some ambiguities in the edge case of srcblock() and srcblock[] references. > 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? Good point, and it got me thinking. If you want to reference a table inside a drawer, you can just name that table manually and reference it. The only point of referencing a whole drawer, I think, would be to get its full text contents verbatim. With dynamic blocks, we primarily need to support clocktables and columnviews. The problem with referencing them is that any NAME added manually is overwritten on update, and the write functions themselves don't add NAME lines. But they could. So instead of my patch, we could: 1. Simply add a :name parameter to the clocktable and columnview write functions; given =:name x= they should insert =#+NAME: x= for Babel blocks to reference. Users can do the same for their bespoke dynamic blocks. 2. Make org-babel-read-element handle named drawers and named dynamic blocks by returning the full verbatim text contents, as it already does for quotes. This is the only use left for naming these containers when we can name their contents. This seems a simpler, cleaner solution, except maybe for the question of updating. The solution in point (1) doesn't know that the named element is in a dynamic block, so it won't update it, and Babel users would have to be responsible for any updating they want themselves. >> - It seems like a good idea that Babel should update a dynamic block >> before reading it, so I have made it so here. This will however change >> contents elsewhere in the buffer while executing a src block, and with >> remote references it may open a file and and leave the buffer open >> with changed contents. Is this acceptable behavior? Or should it be >> made optional, and what should be the default? > > We have similar dilemma for src blocks. That dillema is solved by > src_name() vs src_name[] syntax. Isn't that different? The () syntax gets the results of evaluation and the [] syntax gets the code, but the RESULTS below the referenced src block don't get updated in either case; the buffer changes are only to the results of the block that does the referencing. Regards, Christian
