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

[Nicolas Goaziou]

Hello,

Aaron Ecay <address@hidden> 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