Jonas Bernoulli <jo...@bernoul.li> writes:
>>> In the long run you might want to consider not turning any symbols
>>> into strings, at least not when the "regular" block as well as the
>>> post-processing block both use elisp.
>>
>> This may be tricky. Introducing any kind of special case will make the
>> code fragile. We should better make things as generic as possible.
>
> By "special case", do you mean "just for elisp", or "if both use the
> same language, whatever that might be"? IMO it would be best if as much
> information were preserved between the two code blocks, and when they
> use the same language, that should be "all of it", or nearly.
Either way. It's not like I am against the idea. Rather (1) afraid to
over-complicate the already complex babel code; (2) afraid to break
something non-trivial.
If we do it, I'd prefer same language / same language. Basically, as
generic as possible approach that will be easier to maintain.
> If they use the same language that might be fairly easy to do (bypass
> the code that previously prevented it), but of course it would be
> preferable if all type information were preserved between any two block.
>
> But that would be harder, which is why I would suggest to first/only do
> it if the same language is used by both blocks. The actual suggestion
> to do it only if both block use elisp, was more about first trying it
> with the language we are most familiar with. I wasn't trying to imply
> it should only be done for that language. Of course, if initially only
> doing for elisp actually makes it harder, then doing it for all
> languages at once, would be preferable.
I do no like to make things elisp-specific, unless you can fit it into
ob-emacs-lisp.el. For more generic things, we also need to be careful
and not break anything.
> Speaking of other languages, when I investigated the above issue, I
> tried whether the issue was maybe limited to post-processing blocks that
> use elisp. So I also tried doing it using python, but it turned out
> that that had the same issue, and additionally there was a somewhat
> related, python specific, bug:
>
> `org-babel-script-escape' doesn't handle an empty python list correctly:
> "['a']" => ("a")
> but
> "[]" => []
> I.e., an empty python list is turned into an empty lisp vector instead
> of an empty lisp list. At least for python, (> (length str) 2) should
> probably be changed to use >=.
Patches welcome. But please change the subject in the email containing
the patch for easier tracking.
> ---
>
> And while reproducing that issue just now, I ran into an additional,
> unrelated issue. I didn't have python installed and when I tried to
> evaluate a python block directly, that resulted in an error as expected.
> However, when I evaluated a elisp block, which uses a post-processing
> block that uses python, that failed silently.
It would help if you can provide a reproducer. Also in a branched
thread.
--
Ihor Radchenko,
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
