Evaluate inline code about trackdown HOT 5 OPEN

Hi @arnold-c,

We are really happy that trackdown is useful for your work!

Thanks for your great suggestion. Evaluating inline code is an interesting feature that would surely improve the package. When developing the package, we decided to first focus on the chunks, but now it's time to consider the inline code as well😉.

I will use this issue to discuss the best way to implement this feature.

Substitute inline code

Identify inline code should be a rather straightforward process using regex. We can use the same methods implemented by knitr to be sure we use the best solution. Here are the patterns used link and this is the actual function to parse inline code link.

At this point, we can easily substitute the inline code with some tags, for example, [[inline-code-##]], following the same hide-restore process used with chunks

Pros: this would allow avoiding that collaborators inadvertently chance the inline code.
Cons: this would not improve interpretability. It could be difficult to implement some restore procedure for corrupted/deleted tags (we could just report them in the console with a warning).

Evalaute inline code

As suggested by @arnold-c , we could actually substitute the in-line code with the evaluated output. Tags are still required to allow the restore process. Thus, something like [[inline-output: <actual-output>]] could be used.

Pros: this would allow avoiding that collaborators inadvertently chance the inline code and will enhance text interpretability as well.
Cons: we should run the code.

At the moment trackdown does not compile the document (we used the already compiled output) neither run code chunks. I think this is a very delicate process as things could break easily: the document has to be compiled in a separate r session in the same way as knitr does to avoid corrupted path etc.; compilation could take really long; in extreme cases, we could have to deal also with variables defined in the YAML header.

I mean, we should definitely work towards this direction, but evaluating code is not as straightforward as it seems. Things could go wrong very easily. However, this could be a "experimental feature" that hopefully will work smoothly for most of the documents. A good starting point is the knitr::purl() function, link. This allows extracting all R code from a document (there is an option for inline code as well knitr.purl.inline).

Summarising

Substitute inline code is easy and there should be fewer problems. Thus, I guess is the first step to implement. Subsequently, we should work on evaluating inline code that will require a little bit more work but it is definitely the way to go.

If other authors have other suggestions we can look for different solutions

from trackdown.

Hi @ClaudioZandonella

Thanks for such a quick response and thinking about implementing it. Based on what you've said, would it be useful to require users to keep the intermediate .md files, and the output could be converted into .txt before being uploaded to Google Docs? I'm afraid I'm not familiar with the way {trackdown} works in practice, so please feel free to ignore, as I suspect there would be likely be issues trying to identify code chunks using this method.

from trackdown.

Thank you @arnold-c for the suggestion! I would like to add a minor thing to @ClaudioZandonella answer. Code chunks are isolated from the narrative part of the document and so are easy to manage. Inline codes are strictly related to the text. Maybe using what Claudio suggested [[inline-output: <actual-output>]] is an interesting solution. At the same time, authors should not change or delete the inline code but if someone wants to change/delete or rewrite an entire paragraph is very likely to break something. Furthermore, often the inline code produces some kinds of formatting (like equations, statistical results and so on) that could be not so readable in plain text format.
In general, I think that inline code is one of the most interesting future features, but a little bit critical especially from the actual usability in google docs.

from trackdown.

Hi all, I can see how adding the rendered text to the document as suggested by @arnold-c would be helpful to (some) users. But I can also see the concerns that @filippogambarota and @ClaudioZandonella raise. No matter how hard we try, we won't be able to add all kinds of rendered in-text (like in-line equations). And I don't know whether we can just assume an environment in which we should render the document. While most people might use the R Markdown file self-contained (i.e., have all code needed to render chunks and inline code in the R Markdown file itself), others (like me) only call objects from the global environment in code chunks and inline code and render the document from the global environment (or through a drake workflow) using rmarkdown::render() instead of clicking the "Knit" button.

For these reasons, I would prefer to stay with the core functionality of trackdown, i.e., providing a collaborative editor for R Markdown files and stay away from compiling the R Markdown ourselves. Even if we would implement the feature, co-authors will still have to reference the output document (e.g., the PDF uploaded to Google Drive) to see the rendered code chunks (and the inline code we cannot reproduce as text). I feel like it is thus better to ingrain this separation between R Markdown and rendered document and might even be more beneficial for people to understand how R Markdown works.

from trackdown.

Just a note on

Identify inline code should be a rather straightforward process using regex.

I think it might be more robust to use parsing to identify the inline code (parsing with Pandoc, or commonmark as used in https://github.com/ropensci/tinkr)

from trackdown.