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: Wed, 24 Sep 2014 21:56:36 +0200 [thread overview]
Message-ID: <87tx3weqrv.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <87d2anougv.fsf@gmail.com> (Aaron Ecay's message of "Tue, 23 Sep 2014 00:02:08 -0400")
Hello,
Aaron Ecay <aaronecay@gmail.com> writes:
> I think I can remove these three functions (-parse-list, -to-subtree,
> and -to-generic), and rewrite their callers to use org-element. Thus,
> the org-list-parse-list format would be eradicated from the code base
> incl. contrib (AFAICT). Can I do that, or do I need to care about
> preserving backwards compatibility with external callers of these
> functions? If backwards compatibility must be preserved, may I mark
> these functions as deprecated and what is the minimum period (measured
> in calendar time and/or org versions) that should pass before their
> removal?
You cannot do that. This is not about backwards compatibility.
`org-list-parse-list' generates an easy to produce and work on internal
representation for lists (similar to what `org-table-to-lisp' does for
tables). `org-list-to-generic' is used for radio lists (similar to
`org-table-to-generic'): it is expected to consume
a `org-list-parse-list'-like return value.
IOW both functions are important and are not meant to be replaced by
Elements (however, at some point `org-list-to-generic' should use
"ox.el", but that's for another day).
Note that since `org-list-parse-list' is meant for extraneous buffer, it
cannot rely on Elements. It shouldn't even use `org-list-struct' because
I plan to make this function use Elements, too.
> The babel feature is compelling to me (and I guess Chuck) on its
> own. It’s familiar (e.g. in the case of tables) that babel gets to
> have its own data format for org elements.
It's the same for lists. Internal representation for lists should come
from "org-list.el", not from Babel. Internal representation for tables
comes from "org-table.el", too.
> I’m happy to undertake the above-described demolition job on
> org-list-parse-list in order to offset the added complexity from the
> babel change (we can call it a cap-and-trade system). But given that
> org-list-parse-list is a marginal part of the code base and perhaps
> moribund in the era of org-element
I don't consider radio lists moribund. Are they?
> I don’t really think it’s worth it (to me) to try and engineer an
> improvement to it in order to enable the babel feature.
It is not (or should not be) a Babel feature.
Anyway, it's not about rewriting `org-list-parse-list', but if Babel
understands a new representation for plain lists, this function should
be able to generate it and `org-list-to-generic' should be able to
interpret it.
Could you detail the exact specifications of the suggested internal
plain list representation?
Regards,
--
Nicolas Goaziou
next prev parent reply other threads:[~2014-09-24 19: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 [this message]
2014-09-24 22:49 ` Aaron Ecay
2014-09-26 9:03 ` Nicolas Goaziou
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=87tx3weqrv.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).