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

[Aaron Ecay]

Hi Nicolas,

Thanks for the discussion.

2014ko irailak 24an, Nicolas Goaziou-ek idatzi zuen:
> 
> 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). 

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.

> `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.

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).

> 
> 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).

...doesn’t using ox.el entail using elements?

> 
> 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.

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.

> 
>> 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.

Hmm.  I had missed that, you are correct.

> 
>> 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?

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/address@hidden>.
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’d hope their usefulness would eventually naturally wane as org
becomes compelling enough that people commit to it wholesale, rather
than relying just on the list editing features while living in another
document composition regime.  Whether it’s worth keeping them around
as a sort of training wheels I don’t really have an opinion on.)

> 
>> 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.

Why?  Babel’s representation is for babel.
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.).

> 
> Could you detail the exact specifications of the suggested internal
> plain list representation?

I dunno if I’d call my proposal an “internal plain list representation,”
but rather “babel’s interpretation of plain lists.”

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:

#+name: data
- foo
- bar
  - baz
  - quux
- abc

#+begin_src emacs-lisp :var data=data
(pp-to-string data)
#+end_src

#+RESULTS:
: ("foo" "bar" "abc")

-- 
Aaron Ecay