From: Aaron Ecay <aaronecay@gmail.com>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>,
Org-mode <emacs-orgmode@gnu.org>
Subject: Re: [RFC] [PATCH] [babel] read description lists as lists of lists
Date: Sun, 28 Sep 2014 01:55:51 -0400 [thread overview]
Message-ID: <87tx3sl254.fsf@gmail.com> (raw)
In-Reply-To: <877g0qeosp.fsf@nicolasgoaziou.fr>
Hi Nicolas,
2014ko irailak 26an, Nicolas Goaziou-ek idatzi zuen:
>
>> Why? Babel’s representation is for babel.
>
> Which I strongly frown upon.
Let’s back up a step. The representation I am targeting with my change
is what babel uses to ship a list off as input to code in a babel block.
This code could be emacs lisp, but it could also be R, python, etc. So
the question is, how to provide a consistent language-agnostic view of
org structure to other languages. The resultant structure doesn’t hang
around inside babel, it just gets handed off to a code block.
>
>> org-list-parse-list/-to-generic’s is for radio lists (although as I’ve
>> said this connection seems accidental rather than essential). Babel
>> calls org-list-parse-list, but I don’t see why it should be forbidden
>> from doing more processing on the result before passing it along
>> (indeed, it already does some processing to remove the list type
>> indicators, remove nested structure, etc.).
>
> It is best to use as much common ground as possible. We should strive to
> decrease need for such processing, not the other way.
>
> As I already stated in my first answer, in the long run, it is the only
> sane way to proceed. I agree it is less work to simply tweak Babel right
> now and ignore the whole Org ecosystem, but it does no good to Org as
> a whole.
It’s not work that I’m afraid of: I offered to rewrite both babel and
radio lists in terms of org-elements. Maybe I am insane, as you imply.
What I’m afraid of is old and disused sort-of-APIs like
org-list-parse-list calcifying and preventing good things from happening
to parts of org that people actually use.
What if I rewrote org-babel-read-list in terms of org-elements? That
would satisfy me wrt. babel, and wouldn’t necessitate disturbing
org-list-parse-list, radio lists, or indeed anything outside of babel.
>
> `org-list-parse-list' handles nested lists just fine. Another advantage
> of not re-inventing the wheel in every part of Org.
I know. But babel’s processing of parse-list’s output strips the nested
structure:
#+name: a-list
- foo
- bar
- abc
- def
- baz
#+begin_src emacs-lisp :var lst=a-list
(pp-to-string lst)
#+end_src
#+RESULTS:
: ("foo" "bar" "baz")
That’s because it’s hard to come up with a good representation of a nested
list in a language-agnostic way. “List of strings” is a straightforward
datatype in every language babel supports, but not all of them have a
convenient “labeled n-ary tree with string leaves” (which you’d need for
arbitrarily nested lists).
Thanks,
--
Aaron Ecay
next prev parent reply other threads:[~2014-09-28 5:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-19 19:17 [RFC] [PATCH] [babel] read description lists as lists of lists Aaron Ecay
2014-09-20 0:30 ` Charles Berry
2014-09-20 11:52 ` Nicolas Goaziou
2014-09-23 4:02 ` Aaron Ecay
2014-09-24 19:56 ` Nicolas Goaziou
2014-09-24 22:49 ` Aaron Ecay
2014-09-26 9:03 ` Nicolas Goaziou
2014-09-28 5:55 ` Aaron Ecay [this message]
2014-09-28 10:49 ` Thorsten Jolitz
2014-09-28 22:09 ` Nicolas Goaziou
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=87tx3sl254.fsf@gmail.com \
--to=aaronecay@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=mail@nicolasgoaziou.fr \
/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).