From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Org-mode <emacs-orgmode@gnu.org>
Subject: Re: [RFC] [PATCH] [babel] read description lists as lists of lists
Date: Fri, 26 Sep 2014 11:03:50 +0200 [thread overview]
Message-ID: <877g0qeosp.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <87oau4my5o.fsf@gmail.com> (Aaron Ecay's message of "Wed, 24 Sep 2014 18:49:55 -0400")
Hello,
Aaron Ecay <aaronecay@gmail.com> writes:
> Isn’t the org-element format also easy to work on? It requires a bit
> more than just car and cdr, but it’s well documented and used in many
> places across the code base (= cognitive burden to use is lower). It’s
> also easy to produce in the sense that org-element.el already exists for
> independent reasons; we just have to use it.
It is not as easy to produce ex nihilo, i.e., without any Org syntax
under point. But, really, I do not mind if both radio lists and Babel
move to this internal syntax. It will require much more work, though.
Also, it doesn't mean we can remove or replace `org-list-parse-list' and
`org-list-to-generic'.
> Radio lists is a feature, org-list-to-generic is an implementation. We
> can change the implementation without changing the user-visible aspects
> of the feature. IOW, nothing about the user-facing functionality of
> org-list-to-generic requires it to accept a particular type of argument
> (as long as that arg is some representation or other of a list).
I agree.
> One approach would be to detect when it’s called from a non-org-mode
> buffer, and copy the text into a temporary org-mode buffer for parsing.
> Then org-element would be available.
Of course, if the internal representation is changed to Elements', that
is probably the way to go.
> IDK. You’re probably in a better position to know that than I am. There’s
> only one message even mentioning them (very tangentially) in my 2-ish years
> of messages from the list: <http://mid.gmane.org/87obc6scty.fsf@pank.eu>.
> I’m not advocating their removal or deprecation, but they certainly seem
> like the tail and not the dog when considering what parts of org ought to
> wag what others.
I think you are missing my point.
Again, I'm fine with any improvement needed for Babel, but other, even
remotely, related parts should be moved along. This is about
consistency. I certainly don't want to see various parts of Org drift
away. Or, to put it differently: mind the tail, do not act as if the dog
had none.
> Why? Babel’s representation is for babel.
Which I strongly frown upon.
> 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.
> I dunno if I’d call my proposal an “internal plain list representation,”
> but rather “babel’s interpretation of plain lists.”
See above.
> Ordered and unordered lists are lists of strings (exactly as now).
> Description lists are lists of 2-element lists, each of the form
> (“TERM” “DESCRIPTION”) (unlike now, when they are lists of strings of
> the form “TERM :: DESCRIPTION”).
>
> It might be nice to handle nested lists somehow, if a sensible design
> can be created, but it looks like babel just discards them currently.
> So I propose to leave this unchanged, for the present at least:
`org-list-parse-list' handles nested lists just fine. Another advantage
of not re-inventing the wheel in every part of Org.
Regards,
--
Nicolas Goaziou 0x80A93738
next prev parent reply other threads:[~2014-09-26 9:03 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 [this message]
2014-09-28 5:55 ` Aaron Ecay
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=877g0qeosp.fsf@nicolasgoaziou.fr \
--to=mail@nicolasgoaziou.fr \
--cc=emacs-orgmode@gnu.org \
/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).