emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ANN] lisp/ob-tangle-sync.el


From: Ihor Radchenko
Subject: Re: [ANN] lisp/ob-tangle-sync.el
Date: Sat, 05 Aug 2023 08:48:24 +0000

Mehmet Tekman <mtekman89@gmail.com> writes:

> * Under vanilla `org-babel-merge-params', any number of :tangle header
>   values are permitted and concatenated together.
>
>   e.g 4:
>   __________
>   ´
>     (should  ;; 4.
> override-document-and-parent-header-with-local-tfile-and-action
>      (equal '(:tangle "randomfile sync")
>             (org-test-with-temp-text
>                 "\
>   #+PROPERTY: header-args :tangle /tmp/default_tangle.txt
>   * Four
>   :PROPERTIES:
>   :header-args: :tangle \"newfile.txt\" import
>   :END:
>   ** A
>   #+begin_src conf :tangle randomfile sync
>   #+end_src"
>               (test-ob/get-src-block-property :tangle))))
>   `-----------
>
>   This result of "randomfile sync" for the :tangle header is seen as
>   valid.... but it shouldn't, should it? Tangle can only take one value,
>   so the action of `:any` should also just output one value?
>
>   From the docstring text:
>
>   > Symbol `:any' in the value list implies that any value is allowed.
>
>   It's not clear to me if this means that `:any' or `:any :any` or
>   `":any :any"` is permitted.
>
>   In my rewrite, I very much take the `:any` or `":any :any"` single
>   value interpretation when merging the headers together.

It is not possible to distinguish between `:any' and `:any any' without
reading the user's mind :)
So, we can choose arbitrarily.

Since the previous version of the code used split-string and
unconditionally split the arguments at whitespace, I am inclined to
prefer `:any :any' over greedy version.

So,

#+begin_src lang :tangle yes foo no bar baz "foo bar"

should yield

'("yes" "foo" "no" "bar" "baz" #("foo bar" 0 7 (org-babel-quote t)))

We will allow using quotes to include whitespace.

> * Sometimes the value of another header is caught in the value of
>   another
>
>   e.g 8: "wrap" is caught in the output of `:results' despite it not being
>          a valid results keyword in `org-babel-common-header-args-w-values'.
>
>    __________
>   ´
>     (should  ;; 8. test-results-and-exports
>      (equal '(:results "wrap file replace" :exports "code")
>             (org-test-with-temp-text
>                 "\
>   * Eight
>   #+begin_src sh :results file wrap
>   #+end_src"
>               (test-ob/get-src-block-property '(:results :exports)))))
>     (should  ;; 9. do-not-tangle-this-block --
>   `-----------
>
>   This test results in "true" for both my rewrite, and the vanilla
>   function, but I'm not sure how accurate or value this is.

This is basically a question about what to do when user supplies
incorrect value of a header arg.

In such scenarios, we still capture this unknown value.
This is useful for some third-party backends that extend standard header
args with new possible values.

Hope the above makes sense.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
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>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]