Aaron Ecay writes:
> Let’s back up a step. The representation I am targeting with my change
> is what babel uses to ship a list off as input to code in a babel block.
> This code could be emacs lisp, but it could also be R, python, etc. So
> the question is, how to provide a consistent language
Aaron Ecay writes:
Hi Aaron,
> So the question is, how to provide a consistent language-agnostic view
> of org structure to other languages.
well, that would be the parse-tree normally, its a nested list
containing all info about org structure.
I tried to make two Lisps talk to each other (E
Hi Nicolas,
2014ko irailak 26an, Nicolas Goaziou-ek idatzi zuen:
>
>> Why? Babel’s representation is for babel.
>
> Which I strongly frown upon.
Let’s back up a step. The representation I am targeting with my change
is what babel uses to ship a list off as input to code in a babel block.
This
Hello,
Aaron Ecay 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
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-li
Hello,
Aaron Ecay 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 nee
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
Hello,
Aaron Ecay writes:
> The attached patch makes babel read description lists as lists of the
> following format: (("term" "description") ...). The present default is
> to simply read in the text of each list item, yielding:
> ("term :: description" ...).
Thank you.
> Of course, it’s poss
Aaron Ecay gmail.com> writes:
>
>
> Hello all,
>
> The attached patch makes babel read description lists as lists of the
> following format: (("term" "description") ...). The present default is
> to simply read in the text of each list item, yielding:
> ("term :: description" ...).
>
> Of co
Hello all,
The attached patch makes babel read description lists as lists of the
following format: (("term" "description") ...). The present default is
to simply read in the text of each list item, yielding:
("term :: description" ...).
Of course, it’s possible to interconvert between the two f
10 matches
Mail list logo