Hello, Aaron Ecay <aarone...@gmail.com> writes:
> 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. It is not as easy to produce ex nihilo, i.e., without any Org syntax under point. But, really, I do not mind if both radio lists and Babel move to this internal syntax. It will require much more work, though. Also, it doesn't mean we can remove or replace `org-list-parse-list' and `org-list-to-generic'. > 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). I agree. > 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. Of course, if the internal representation is changed to Elements', that is probably the way to go. > 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/87obc6scty....@pank.eu>. > 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 think you are missing my point. Again, I'm fine with any improvement needed for Babel, but other, even remotely, related parts should be moved along. This is about consistency. I certainly don't want to see various parts of Org drift away. Or, to put it differently: mind the tail, do not act as if the dog had none. > Why? Babel’s representation is for babel. Which I strongly frown upon. > 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.). It is best to use as much common ground as possible. We should strive to decrease need for such processing, not the other way. As I already stated in my first answer, in the long run, it is the only sane way to proceed. I agree it is less work to simply tweak Babel right now and ignore the whole Org ecosystem, but it does no good to Org as a whole. > I dunno if I’d call my proposal an “internal plain list representation,” > but rather “babel’s interpretation of plain lists.” See above. > 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: `org-list-parse-list' handles nested lists just fine. Another advantage of not re-inventing the wheel in every part of Org. Regards, -- Nicolas Goaziou 0x80A93738
