Hello, Aaron Ecay <aarone...@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