Hi Ihor! Ihor Radchenko <[email protected]> writes:
> Daniel Bausch <[email protected]> writes: > >> I simply removed variant (2) entirely. A `:var` keyword now always >> takes exactly two arguments, a NAME string and the VALUE, of which the >> VALUE is used as-is, so a keyword is no longer a problem there either: >> >> (org-babel-call "foo" :var "a" :some-keyword) >> >> If someone wants to define a variable using a resolved reference, >> e.g. to read from a table, they can still use `org-babel-ref-resolve` >> explicitly (positionally or named). I mentioned that in the docstring. >> >> (org-babel-call "foo" :var "a" (org-babel-ref-resolve "tbl[1,1]")) > > What if someone wants to pass two variables? Obviously :var can be repeated (as in the header args). (org-babel-call "foo" pos1 pos2 :var "a" "bar" :var "b" 12345) Or did I miss anything that would disallow such an API? Keyword :var is just a marker followed by two items, NAME and VALUE. The &rest after the initial block name is scanned for every occurrence of positional or named arguments or any header keyword that shall be overridden. I can imagine two scanning strategies regarding positional args: 1. Python way (implemented in v4): No positional arguments after the first named variable or header argument override. 2. CLI way (not implemented yet): Any item of &rest which is not following a keyword is treated as a positional arg. CLI way is a superset of Python way, so allowing CLI way would allow maximum flexibility and suit any taste. Keyword :var captures two following items, any other keyword is treated as a header argument and captures a single following item. Captured items can be keywords themselves. Because of fixed arity capturing, it is unambiguous which items are associated with the keyword and so they can be any lisp value. >> Regarding your comments on the complementary function >> `org-babel-result`: >> >>> Why not just :var hello=hello[:cache yes]() + >>> (setq org-babel-update-intermediate 'cache)? >> >> I checked this and I don't think it's a substitute for my proposed >> function. The idea of `org-babel-result` is to have something that >> obviously and reliably never modifies or re-executes the producing block >> (regardless of any settings). > >> Let's say, the referenced block took an hour to run (I happen to have >> such queries) or even is a one-shot thing whose result isn't >> reproducible at all. Now with the result already in the buffer, I want >> to consume the result in another block. >> >> With the proposed `org-babel-result` I can do that in an elisp body or >> in a variable assignment in the header. > > Could you elaborate on what you expect to happen when there is no cached > result in buffer? Then it returns nil. It's meant to be really very intuitive. Contract: Just take the currently materialized result of a named source block as it is from the buffer/file. > Before we go too far with LLM-generated patches, please note that GNU > projects, including Emacs, cannot accept LLM-generated patches as of > now. This is a temporary policy that will be in place while GNU is > consulting with lawyers on the implications of LLM code on GPLv3 > license. I hope that GNU can produce the final policy in the coming > months. I got this and I'm in the process of re-writing everything from scratch by hand. I feel, not having a good option for non-trivial orchestration is a serious gap in Babel, which is why I'm committed to substantially invest time in that project. As I worked solely spec-driven and test-driven up to v4, I really never looked closely on the generated code. The most intense "conversation" I had with the model about the code was on the comments and docstrings. So, my plan is to deliver a clean-room implementation of the functions' contract soon. I will run the AI generated tests against it, to reassure that I did at least as well as the AI, if that's ok. I will deliver clean-room hand-written tests in the patch though. Would that meet Emacs' policies? I already asked for FSF assigments but did not get a reply yet. Kind regards, Daniel
