Open maelle opened 1 year ago
or, in the XML, we store the inchunk options as... YAML string? :thinking:
It might help us with the parsing. Now it might make users' life a bit more difficult if we don't provide some functionality to go with this?
It'd be nice to have a function operating on code chunks that would present chunk options as a tibble, with for each option a row with
Then there'd be a function to carry edits to this tibble to the code chunk XML.
@zkamvar how would that sound? what would this feature be, code chunks as objects?
one might first need a method to get all code chunks? :thinking:
In #28 you had mentioned the extraction of features such as code chunks @zkamvar
one might first need a method to get all code chunks? :thinking:
This is a good point. We've been able to get away with parsing the code chunks because they've always been generally linear and not very complex. With the new nested complexity that YAML introduces, It would definitely make sense for us to have options to store and access the chunk options consistently.
I'm wondering if we should just be opinionated on how code chunks are treated on output (e.g. users can choose to use curly, hashpipe-list, or hashpipe-yaml, but no mixing).
@zkamvar what would be a good target for this PR? Happy to do more work on it / follow-up PRs :grin:
@zkamvar what would be a good target for this PR? Happy to do more work on it / follow-up PRs grin
Ugh, I'm so sorry. We were doing this when things got really hectic for me and I had to drop it. I'm going to come back to this probably after May (that's when we transition all of our lessons)
No worry and good luck with the lessons transition! :rocket:
Fix #55
For now this writes all in-chunk options back to YAML format so if we go with this the README will need a note about this.