From: Jonas Bernoulli <jonas@bernoul.li>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Post-process table without changing result for empty table(/list)
Date: Tue, 04 Oct 2022 16:00:19 +0200 [thread overview]
Message-ID: <87sfk3u1sc.fsf@bernoul.li> (raw)
In-Reply-To: <874jwkwb4c.fsf@localhost>
Ihor Radchenko <yantar92@gmail.com> writes:
> Jonas Bernoulli <jonas@bernoul.li> writes:
>
>> It used to behave like that before 51a628bc5efc from 2009, which started
>> turning all symbols, including nil, into strings, but without giving any
>> reason why that should be done.
>>
>> It has worked like this for a long time now, so reverting that is
>> probably not feasible in the short run. However, I feel it would
>> make sense to change now how nil/'() is treated. Currently it is
>> being treated as the symbol nil, but IMO it would make more sense
>> to treat it as the empty list. That could be achieved with
>>
>> diff --git a/lisp/ob-ref.el b/lisp/ob-ref.el
>> index b79e47900..2b4a16aea 100644
>> --- a/lisp/ob-ref.el
>> +++ b/lisp/ob-ref.el
>> @@ -199,7 +199,7 @@ (defun org-babel-ref-resolve (ref)
>> (org-babel-execute-src-block nil info params))))
>> (error "Reference `%s' not found in this buffer" ref))))
>> (cond
>> - ((symbolp result) (format "%S" result))
>> + ((and result (symbolp result)) (format "%S" result))
>> ((and index (listp result))
>> (org-babel-ref-index-list index result))
>> (t result)))))))))
>
> Looks reasonable.
> Could you please prepare a patch and possibly also add a test that
> covers your use-case to testing/lisp/test-ob.el?
> See https://orgmode.org/worg/org-contribute.html
Will do.
>> 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.
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.
---
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 >=.
---
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.
next prev parent reply other threads:[~2022-10-04 14:45 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 [this message]
2022-10-05 7:37 ` Ihor Radchenko
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=87sfk3u1sc.fsf@bernoul.li \
--to=jonas@bernoul.li \
--cc=emacs-orgmode@gnu.org \
--cc=yantar92@gmail.com \
/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).