-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Evaluate inline code #18
Comments
Hi @arnold-c, We are really happy that 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 codeIdentify inline code should be a rather straightforward process using regex. We can use the same methods implemented by At this point, we can easily substitute the inline code with some tags, for example, Pros: this would allow avoiding that collaborators inadvertently chance the inline code. Evalaute inline codeAs 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 Pros: this would allow avoiding that collaborators inadvertently chance the inline code and will enhance text interpretability as well. At the moment 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 SummarisingSubstitute 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 |
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 |
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 |
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 For these reasons, I would prefer to stay with the core functionality of |
Just a note on
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) |
This is a great package with lots of potential, so thanks for making it. I'm using this package is to write a scientific manuscript with non-R users, and at present, inline code is printed in the Google Doc file. In my workflow, and I suspect in many others, I use inline code to print numbers within the text (often in the methods and results sections) to avoid errors from manually calculating and transcribing them. The results of this inline code is therefore very important to surrounding inferences and text, so it would be very helpful if
{trackdown}
was able to evaluate inline R code, and perhaps highlight the output to indicate that it should not be edited. Whilst a workaround is to create the output document at the same time, it would be a far smoother experience to not have to switch between documents.Thanks again for this package!
The text was updated successfully, but these errors were encountered: