Another note here: you may probably use `unwind-protect' instead of
progn to be safe.
Oh yes, that makes sense. Applied an `undwind-protect' here to reset the
framework version to the "previous" one.
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.
On 27.04.25 13:40, Ihor Radchenko wrote:
poverobuosodonati<poverobuosodon...@gmail.com> writes:
Finally, `with-try-set-dotnet-version' is questionable. It is used once
so you may as well put the code directly inside `with-newest-dotnet'.
Agreed, I inlined this.
Another note here: you may probably use `unwind-protect' instead of
progn to be safe.
https://codeberg.org/buoso/csharp-babel/src/branch/dev/test-ob-csharp.el#L113
2. :main yes does not appear to be test-covered unless I miss something
I thought about that and came to the conclusion that I consider the
"yes" argument as bloat, so I removed that as an option completely.
Does it mean what an equivalent of a "yes" is now no header argument at
all? That's not a good idea. Consider header argument set for a subtree:
* Heading
:PROPERTIES:
:HEADER-ARGS:CSHARP: :main no
:END:
...
# :main yes just for this block
#+begin_src csharp :main yes
...
#+end_src
