emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
To: Jonas Bernoulli <jonas@bernoul.li>
Cc: emacs-orgmode@gnu.org
Subject: Re: Post-process table without changing result for empty table(/list)
Date: Wed, 05 Oct 2022 15:37:36 +0800	[thread overview]
Message-ID: <87y1tu90vz.fsf@localhost> (raw)
In-Reply-To: <87sfk3u1sc.fsf@bernoul.li>

Jonas Bernoulli <jonas@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


  reply	other threads:[~2022-10-05  7:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-03 19:29 Post-process table without changing result for empty table(/list) Jonas Bernoulli
2022-10-04  2:55 ` Ihor Radchenko
2022-10-04 14:00   ` Jonas Bernoulli
2022-10-05  7:37     ` Ihor Radchenko [this message]
2022-10-05 13:21   ` [PATCH 0/1] Allow returning empty list from post-processing block Jonas Bernoulli
2022-10-05 13:21     ` [PATCH 1/1] " Jonas Bernoulli
2022-10-06  3:15       ` Ihor Radchenko
2022-10-06 11:11         ` [PATCH v1] " Jonas Bernoulli
2022-10-07  4:09           ` Ihor Radchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y1tu90vz.fsf@localhost \
    --to=yantar92@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=jonas@bernoul.li \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).