emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [RFC] [PATCH] [babel] read description lists as lists of lists


From: Aaron Ecay
Subject: Re: [O] [RFC] [PATCH] [babel] read description lists as lists of lists
Date: Tue, 23 Sep 2014 00:02:08 -0400
User-agent: Notmuch/0.18.1+51~gbbbdf04 (http://notmuchmail.org) Emacs/24.4.50.2 (x86_64-unknown-linux-gnu)

Hi Nicolas,

Thanks for your feedback.

2014ko irailak 20an, Nicolas Goaziou-ek idatzi zuen:
> 
> The problem I see here is that you're introducing yet another internal
> representation for lists (along with element's and
> org-list-parse-list's). Worse, it can only be discovered when reading
> the docstring of a Babel internal function and will only benefit to
> Babel.
> 
> If this new internal representation is better than current one, by all
> means, improve `org-list-parse-list', and document it in
> 
>   (info "(org) Radio lists")
> 
> This is more work, but, IMO, it is also the only sane way to proceed.

Indeed.  The internals of org-list are not pretty.  org-list-parse-list
has few callers:
- org-list-make-subtree
- org-babel-read-list
- org-toggle-heading

org-list-to-subtree has only two callers:
- org-list-make-subtree
- org-toggle-heading

org-list-to-generic also has only two callers:
- org-babel-insert-result
- org-list-to-subtree

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?

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.  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 really think it’s worth it (to me) to try and
engineer an improvement to it in order to enable the babel feature.

WDYT?

-- 
Aaron Ecay



reply via email to

[Prev in Thread] Current Thread [Next in Thread]