useful runtime error when .NET framework cannot be determined
would be preferred.
Sounds good, I added that here
https://codeberg.org/buoso/csharp-babel/src/commit/944c1a0c9106c52fd88e7631dd380adebcac90f7/ob-csharp.el#L261-L262
together with a test
https://codeberg.org/buoso/csharp-babel/src/commit/944c1a0c9106c52fd88e7631dd380adebcac90f7/test-ob-csharp.el#L311-L319
after addressing the above, could you
prepare a patch against org-mode repo?
If the above is ok with you, I would go ahead and follow this documentation
https://orgmode.org/worg/org-contribute.html#devs
adding it to the org-mode repo, prepare a documentation addition to the
worg repo, and add a news entry.
On 12.07.25 18:38, Ihor Radchenko wrote:
poverobuosodonati <poverobuosodon...@gmail.com> writes:
Unless I miss something, the new code will err on (require 'ob-csharp)
when dotnet command is not available.
Not quite. But not better either: if the dotnet command is not present,
the variable `org-babel-csharp-default-target-framework' would just be
set to "netnil.0" (as the list of available sdks provided by
`org-babel-csharp--find-dotnet-version' will be nil in this case). This
is a "bogus" value however and we would only recognize that when
evaluating (any) csharp code block. So with some nuance of "graceful
degradation" in mind I explicitly throw if the setup was not able to
find a .NET SDK on the host.
See
https://codeberg.org/buoso/csharp-babel/commit/345e1ea23f39971bdf844e54d94677c9560194de
Is that acceptable? Or would you do it differently?
Throwing an error on load is not acceptable.
That could ruin Emacs startup for no good reason.
Instead, a useful runtime error when .NET framework cannot be determined
would be preferred.
I think that your repository is getting good enough to be merged
upstream at this point. So, after addressing the above, could you
prepare a patch against org-mode repo?
