Wewould also love to have both markdown and even more code view ! Especially as the inline editor sometimes get crazy when adding / deleting bullet points. It would be very very helpful to be able to cleanup the entry in html directly instead of using back and forth text copies to other softwares (mainly Notepad in this case) to simplify the underneath html.
You have a fantastic product otherwise and this is glaringly out of sync with the quality and thoughtfulness put into pretty much everything else, to the point that it detracts from the perception of everything.
Code formatting a paragraph is supported, but this is NOT as useful as simple markdown support, because it applies to a whole paragraph only. The more common approach is to highlight individual words within a paragraph.
However, Scrivener has a Markdown parser (is that the right word) built in, which is accessed through Compile. If you read the many threads in this forum, you will see that you can simply write the Markdown directly, or leverage the advantage of the styles in the editor to inject the Markdown codes as part of the Compile process.
Just write, the whole point of markdown is it is plain text, no need for anything other than plain text! Scrivener can work with markdown in the editor without issue. As Mark mentions, Scrivener does not syntax highlight markdown, but we have a better trick: use styles, so for example you see bold without the asterisks but when you compile it becomes **bold**, this is a hybrid markdown, where are markdown is not used when writing, but is used when compiling. That means less clutter in the editor and way more flexibility when outputting for many different scenarios.
I was working with trying to format responses and it appears that we can work around the lack of formatting within the tool by leveraging Markdown syntax in the responses from Flow which is super helpful for displaying sets of data. It is not truly a rich format yet, but it is getting better!
The other issue is finding something that works with all the channels that you want to support. For example, the table markdown wasn't supported by Teams. I had to play with the formating until I found something that worked with Web and Teams channels. I'm using Bold, URL's, and Unordered lists fine.
These markdown formating options do not appear to be working anymore in PVA response messages. I've tried the examples from this post, and they don't work anymore. Can someone confirm that they are still working for them?
I'm a relatively new R user and most of my usage is data manipulation and statistical analysis for social science research. In general, my work consists of one-off analyses using different datasets, rather than ongoing projects where data and results need to be updated or reported on a regular basis. Outputs of the analyses often consists of CSVs that I share with coworkers, but also sometimes are research briefs that I write.
Thus far, I've only used R scripts for my code, organizing the project so that each script does a manageable and specific chunk of the project. Sometime the projects are somewhat involved and may lead to 15+ scripts for a single project. It seems like many people prefer R Markdown, but I haven't made the jump yet, in part because I'm not totally clear on how this would help my workflow. I can see that using R Markdown for a report template that needs to be frequently updated with new data would be very useful, but I'm having trouble seeing the best way to integrate R Markdown into my work.
One of the main reasons that I have found RMarkdown helpful for writing reports that don't need constant updating or reporting out is simply that I find it very easy to make consistent reports. For my position I often do a variety of data analyses but they all need to be presented in the same format for consistency. I've used RMarkdown to create a template for myself so I only need to change the actual code doing the analysis and the write-up of said analysis.
Hi! I've been using RMarkdown for over a year now. Before that, for any given project I would have code scripts plus README text files plus handwritten notes plus JPG/Postscript files with graphs etc. At the beginning of the project everything would be more or less organized but as time went on I inevitably started losing track of things (I'm not very good at keeping a tidy mental image of a project).
For me, RMarkdown has now become a core component of every project. It not only helps me maintain order, it also ensures reproducibility and consistency (as already noted by @dlsweet). I can keep my code, notes and relevant links all in one place, easy to maintain -it's a text file after all- and if for some reason you need to keep code files separate (I often do), you can always source them into the notebook.
I love RMarkdown. I'm a senior in college and I use it for about 95% of my assignments. Any time I need to do data analysis, report writing, math homework, prototyping, etc.. I use Rmarkdown. Having the ability to knit to HTML or PDF and the markdown and LaTeX capabilities are really versatile and make working on any kind of deliverable so much easier. I also definitely stand out among my peers in the 'quality' of my work because I'm able to turn in a polished document as opposed to transferring everything to Word (Rmarkdown can knit to word too )
One projection organization question I have is, do you use a single R Markdown file for your whole project? For example, is all your data import, cleaning, merging, manipulation, etc. in the same file as your modeling and visualizations? If so, I'm thinkin that my R Markdown file could be 1000s of lines and maybe tricky to find specific parts of the project I'm interested in revisiting. In this case, would it be appropriate to develop separate R scripts for different each step of the project and then use the R Markdown document to pull everything together?
Anyways, I haven't used bookdown, which I believe builds on RMarkdown, but from my understanding it can compile multiple .Rmd files into one book (or report). That might be something worth looking into if you'd like to separate out all the different aspects of the reports you compile.
For research projects, I use R Markdown documents versus R scripts for different purposes. I will typically use R scripts to do things like importing the data, cleaning up variables, typecasting variables, doing any tidying, etc. I have separate scripts for each tasks, named:
These scripts are short and focused, and named according to the specific thing they do so that I can trouble-shoot more easily when something goes wrong (if you use R Markdown for this, your file could not knit, and it can sometimes take awhile to figure out what went wrong if you have tons of lines of code all in one long file).
Sometimes these scripts include plots so I can refine my code when I am actively working on the script, but typically once I get the code how I want it, the plots are not useful so they don't tend to appear in these R scripts (I use the RStudio IDE during my interactive work sessions).
These scripts typically have some comments in the code using # this is the problem this next chunk of code addresses, but these scripts don't need any narrative to be useful- they just need to work so I can move on.
Next, I make R Markdown documents. Some are primarily visualizations and results of analyses where all code chunks are hidden using global chunk options at the top of the Rmd file (because my collaborators don't know R and will be confused when they see code) like this:
By only changing the above global chunk option to TRUE, I then have a complete printout of all my analyses and results, including the R code used to produce each analysis/plot, and the complete output. This is good for my collaborators that know R and can parse the code. The great thing is I don't have to create a different R Markdown files for each audience! Because I can annotate and include more narrative in the R Markdown files, I include explaining/teaching/discussion-provoking thoughts in those documents in between the R chunks.
For teaching statistics, I ask students to submit R Markdown files and a knitted version with echo = TRUE as a global option. This has made grading assignments so much easier, and the students can work in one document to analyze AND interpret data (rather than working in R console, and copying/pasting R code and output into a text editor or Word document, then adding narrative).
I have been using RMarkdown a little over a year. At first, I was so excited! I am not what you call an "A type personality" and it looked like .rmd would really help me keep all my data, code, and analysis together - another tool in my fight against my inherent chaos!
But the longer I worked on an analysis, the more my R notebook would become a complete and ugly monster. Scrolling, scrolling, scrolling. . .code, figures, text, tibbles, figures, code. . . I dreaded opening these things up. I quit R Notebooks and went back to scripts with labeled code chunks and comments. Then some one asked to see what I'm working on and I copied and pasted everything into .rmd and by this time my GitHub repo looks as bad as my kitchen counter.
So, if people who are here to argue for the use RMarkdown could at the same time provide more direction for best practices as intended, including some examples to emulate, this would go a longs ways into getting me back on the proper .rmd track.
I only started using RMarkdown (and github, github pages) about a month ago. I'm a experimental psychology postdoc who works remotely, and my lab and supervisor both are 8 time zones behind me. My job is mainly to analyze and test loads of eye tracking and behavioral psychology datasets, so I needed a way to share data reports with my lab.
RMarkdown and R Notebooks to the rescue!! I'm convinced it's the easiest way to communicate my work with my lab team. I write out data science narratives interspersed with code blocks (always hidden...I don't think anyone in my lab reads the code, but it's there!) and charts. I can quickly whip out participant demographic tables, show boxplots, print output from regression models, all in one document. My lab loves it, and when I update it, I always email my team with specific links (usually to H1 headings) and explain what changed.
3a8082e126