Most babel packages are rather lax on yes/no. Often, something like
:header-arg (lisp-expr ...), when evaluates to non-nil and not "no", is
treated as "yes". So, what you do is fine. But it should be documented.
I've documented it accordingly and wrote a test for it here:
https://codeberg.org/buoso/csharp-babel/src/commit/308f45d724b2f5cca896706acfb5fd7c0fc7f50f/test-ob-csharp.el#L94-L115
There is now also a "proper" test for
`org-babel-csharp-additional-project-flags` and updated documentation
for the intended use of this customization:
https://codeberg.org/buoso/csharp-babel/src/commit/308f45d724b2f5cca896706acfb5fd7c0fc7f50f/test-ob-csharp.el#L304-L321
On 06.05.25 20:37, Ihor Radchenko wrote:
poverobuosodonati <poverobuosodon...@gmail.com> writes:
Consider header argument set for a subtree:
This actually works without an explicit "yes" (or similar) option. This
is because `org-babel-default-header-args:csharp' checks for "no" and
only if that is given as a header-arg, it will omit the main function in
expanding the code block. Anything other than "no" (including no ":main"
header-argument at all) will result in `main-p' evaluating to `t' and
result in an expanded code block that has a main function.
But yes, there should be a test for this "implicit behavior". There I'd
have another question though: I understand that this implicit assumption
is not exactly /elegant/. Should we transition to an explicit check for
either "yes" or "no"? I am a bit undecided here tbh. I will however
adapt the code accordingly and add an appropriate test.
Most babel packages are rather lax on yes/no. Often, something like
:header-arg (lisp-expr ...), when evaluates to non-nil and not "no", is
treated as "yes". So, what you do is fine. But it should be documented.
