Aaron Ecay <aarone...@gmail.com> writes:
> I don’t think we should unit-test only public API functions.
I didn't say that. However, I wouldn't write tests for "--" functions.
> Indeed, I find it easier to write unit tests for small functions,
> since I don’t have to construct a lot of extra context to exercise all
> the corner cases.
That's not my point. However I'd rather spent my time elsewhere than
writing tests for worker functions.
>>> In view of this, do you think it would be desirable in the long term to
>>> refactor code like this into top-level functions?
>>
>> No, I don't. I see no reason to pollute name space with these very
>> specific functions.
>
> I’m not sure I get it – interned symbols are cheap, and with the new-ish
> double-dash convention for private functions users/downstream developers
> can be pretty sure they don’t need to worry about them.
I see no reason to define at top level a worker function with a very
limited scope. Much like let bindings I find it much clearer to keep the
scope of a function as close as possible to its real use, as long as the
function isn't too large. If one day, it is deemed useful in another
function, then it can be lifted to top level.
Anyway, this we're really nitpicking. There's nothing fundamentally
wrong in either choice.
>> - change `org-list-parse-list' to provide a simpler output and update
>> Babel should to use that new output.
So the new output could be
plain-list = (type item+)
type = ordered | unordered | descriptive
item = ((text|plain-list)+)
Thus,
1. first item
+ sub-item one
+ [X] sub-item two
more text in first item
2. [@3] last item
is parsed as
(ordered
("first item"
(unordered
("sub-item one")
("[X] sub-item two"))
"more text in first item")
("[@3] last item"))
The slightly tricky part is taking care of the indentation when text
contains more than one line.
Also, for completeness, a descriptive list, e.g.,
- tag :: text
would be simply parsed as
(descriptive ("tag :: text"))
The objective is to make this syntax easy to create programmatically,
e.g. for Babel. Making something out of it would be the goal of
`org-list-to-generic'.
WDYT?
>> - re-implement `org-list-to-subtree' using directly Elements, or even
>> string massaging.
>
> OK, these both sound do-able.
Meanwhile, I fixed the current issue. It is as ugly as before, but at
least, no error is thrown anymore.
>> - start a poll on the ML to guess the potential user base for radio
>> lists. Depending on the results, we might either deprecate the whole
>> thing, as you suggest, or implement in a more powerful and clean
>> way. Note that first item implies `org-list-to-generic' should be
>> updated to handle new output for `org-list-parse-list'.
Having slept over the idea, I think we could simply update
`org-list-to-generic' to be more robust and be done with it. I can
implement it in a couple of hours (and debug it in a couple of
months...).
Regards,
