What are your recommendations for thesis writing with RStudio and Rmarkdown?

rmarkdown
bookdown

#1

I have been using RStudio and Rmarkdown for the past couple of years and I love them! Now that I am writing my Ph.D. dissertation, I'm seriously considering leaving MS Word and switching to Rmarkdown.

The main reason for ditching Word is that I've noticed that drafting a long document with different objects (e.g. tables, equations, figures, etc.) makes the document unstable. It behaves differently on other machines and tables leave their places. Secondly, I want my work to be reproducible. It is not common in my field (civil engineering) and I want to change that.

My current workflow is to write individual scripts for each task (data cleaning and tidying, exploration, modeling, plots, etc.) and then, once I know what my final set of analyses is, combine all in one master script with only necessary components. However, I haven't used Rmarkdown (or bookdown) for drafting any manuscript before.

What are your recommendations for thesis writing using RStudio and Rmarkdown? What should be my first steps? How can I make sure that I could use one set of analysis (maybe in a script) later in a presentation or a separate journal article as well?

Thank you for your time.


#2

For a thesis I would go Latex instead of Rmarkdown, this gives you a lot more flexibility. Sure, latex has a learning curve and is much more involved then markdown, but it's really neat for scientfic documents. If you are writing a PHD thesis, its large enough project to learn Latex just for that (I learned it for my Masters thesis, and that was ok).

Learning Latex also teaches you a lot about structured documents, typesetting and layout. A lot of stuff that's easy in word but actually a really bad idea is kinda awkward to do in latex, while producing awesome looking documents is (kinda) easy.

The downpart is you loose the html output option, but I have the impression that in practice it is not possible to author large documents in Rmarkdown that look good in several output formats anyways.

For organising your code, you should consider making a package for your thesis. If your data is not to large, the canoncal form would be to put your parsed data in rda format in ./data, your raw data in ./inst/extdata and your scripts for going from raw to parsed data in ./data-raw.

I cannot help you with how to organise your analysis and modeling scripts, but I would try to keep the compile time for the thesis document to a minimum and see that it focuses on the text.


#3

Are you considering Rmarkdown with BookDown? You can see which of the features there are included in what you're doing with Markdown vs Latex and decide what works the best for you. I've been using R Markdown for a while and would also recommend it instead of Latex. IMO you'll get more mileage out of learning how to use Markdown and BookDown in the future rather than Latex.


#4

I am of the opinion this is a very good idea. I have not done a PhD dissertation but I've done a master's and I am through the first draft of a book for O'Reilly using RMarkdown and Bookdown for all of the book. I'll share a few thoughts that may or may not apply to your situation.

You'll get input to write in LaTex. Ignore that input. You should write in Markdown or R Markdown because it's simple and not overly distracting. If you want control of your document in ways that are not easy or possible in R Markdown, you can always knit to LaTex and then edit the LaTex there... or more likely you can include raw tex in your R Markdown document to get the results you want. Using rmd for all your writing keeps you from getting distracted by the endless tweaking of formatting.

Which brings me my second point Focus on writing, not layout: It's tempting to be distracted in the writing process by resizing figures, editing layout, managing page breaks and all that junk. Ignore that crap. That's total distraction from your singular goal: get your ideas in writing. All that other garbage gets fixed in editing which is a totally different process. Don't spend 4 hours coercing a plot to be perfect only to have that plot edited out of the final version. I've done that. It's a waste.

structure: Structure your document so it can build in 15 minutes or less: Ok, 15 minutes is totally arbitrary, but the concept is you want your junk to build in a short amount of time. If you have some complicated malarky like stochastic simulations or GPU intense 3D rendering, pull that bit out into a subproject, make a reproducible script that produces summary tables (or graphs or whatever). Then read the summary info into your main document and report on it. IMO, anything that takes longer than 10 mins gets a subproject. Keep those subprojects in the same directory tree and git repo, of course.

which brings us to version control: use git and github: If you want to be reproducible and also prevent calamity, use version control. git integrates well with RStudio and is well documented. Github is great, but the other hosted git solutions are super too. Pick one and use it. Commit multiple times a day when you are writing and never go home without pushing to the cloud. I push every time I commit when I'm writing text (as opposed to code). There's no good reason not to push every commit when you're writing.

directory structure: Don't take this literally prescriptively. You're project may need a different structure, and that's fine. Here's a possibility assuming you are doing Bookdown (I recommend it):

My_Dissertation
   normal bookdown files go here
   every chapter gets an rmd:
   1_Intro.Rmd
   2_lit-review.Rmd
   3_methods.Rmd
   4....etc.Rmd
   --4_supporting_analysis_of_bridges_or_whatever
       --Data
     4_supporting_analysis_of_bridges_or_whatever.Rmd
     --Output
   5_conclusions.Rmd
   --Images
   XX_required_packages.R

I'm using -- to mean subdirectory here... The guiding principle is that the whole thing can get loaded on to another machine and run. Nothing lives outside the My_Dissertation. I really recommend reading Jenny Bryan's "How to name things" presentation https://speakerdeck.com/jennybc/how-to-name-files

I like adding something like XX_required_packages.R which is the install script that installs all needed packages to run everything in the book. Not a big deal if you only use 3 packages, but by the time you get to 15 packages, you'll be glad you kept track of them.

Feel free to ask questions and debate me on anything asserted here. I'm a big fan of "strong beliefs loosely held" so I have a reason for everything I pitch here, but that doesn't mean it's the singularly best idea.

Good luck with your dissertation. And, btw, you should be writing right now! :slight_smile:


#5

I am also working on my dissertation paper. There is definitely no need to use words. Latex is more flexible than markdown, especially in academia many scholars use it. However, it takes some time to learn how to write Latex code, and sometimes it is difficult to debug your code. You should use Lyx, which feels like words but actually is Latex, and you do not need to learn anything about Latex. Just get your table and regression results in R converted into Latex code using xtable or stargazer, then copy them to Lyx.


#6

It's a joy to work with rmarkdown and you can produce a .tex file. You may use this .tex file in case you want to use latex for final touches or for publication purposes.
Moreover, check the package rticles which allows you to write articles for journals published by several major publishers.


#7

After the other peoples comments I just have to write a bit more of a defense on Latex (then Ill leave you all alone :wink: )

you can always knit to LaTex and then edit the LaTex there...

to me this sounds like a really impractical. What if you have to reknit, do you do all your edits all over again?

or more likely you can include raw tex in your R Markdown document to get the results you want.

This is definitely true and I do this a lot. The problem is, if you are not already really good at latex you will have no idea what is actually going on in your document. Many of the more complex Latex snippets you find on the net will not work directly in Markdown documents. Combining Markdown and Latex is a convenient way to produce great looking documents, but this is definitely more advanced writing pure Latex from the beginning.

Structure your document so it can build in 15 minutes or less

This sounds really extreme to me, I would more aim for a max of 1 minute and have my computations in some other script. However, you can also use the caching feature for R chunks (though I am not a big fan of that)

All other recommendations by @jdlong are totally on point IMHO

You should use Lyx, which feels like words but

You do not WANT your editor to feel like word. As @jdlong recommend, you do not want to think about layout and content and the same time. Think about "this feels like excel, but it's actually R" :confounded:

One more unrelated addition: I don't know how you manage your literary sources, but I wholeheartedly recommend Mendeley as a literature management software. Sure, it's a commercial product but the free version already as all the features you might need.


#8

R Markdown hands down. I wrote my entire dissertation using R Markdown and truly can't imagine the process without it.

There are a number of packages that build off of bookdown for writing theses/dissertations. I worked off of thesisdown and huskydown to build gauchodown (get the theme yet?) to write my dissertation. Take a look, all of them have pretty detailed instructions on getting started.

Here's why R Markdown specifically

  1. When you inevitably catch a bug in your code the week before it's due, re-producing the final document is a piece of cake

  2. R Markdown + bookdown allows for adaptive cross referencing of figures, tables, equations, you name it, along with complete support for automated citations using your favorite reference manager (I personally prefer zotero)

  3. The PDF is dead. Long live the PDF! While most of us aren't printing out PDFs anymore, there's still obviously a need for producing a nice looking PDF document. But, writing your thesis/dissertation in R Markdown allows you to, in about 4 lines of code, go from outputting a PDF version that most likely will be read by your relatives and hopefully your committee, to a great looking webpage that you can use to get your work out there more easily (you can view mine here)

Lastly, it's important to point out the distinction isn't really R Markdown or latex. You can add latex directly to R Markdown documents, and pass in .tex and ..cls files. For example, UC Santa Barbara has a very specific set of formatting requirements for the final PDF dissertation, all of which I included in mine through the appropriate .tex and .cls files, while still doing absolutely all of the actual writing in R Markdown, which is just cleaner and allows for actual code integration. Plus then you can easily export to not only PDF, which is where you're stuck if you write it directly in latex, but through the magic of knitr you get the full capabilities of latex, along with export to html and word.

Do it in R Markdown. Your current and future self will thank you. I'll be putting out a post on the general process of writing a dissertation in R Markdown over at weirdfishes.blog soon


#9

I use RMarkdown and I'm pretty happy with it, but in hindsight I'd probably go with pure Markdown (one of my colleagues has a Pandoc template that works well), because I don't use RMarkdown chunks a whole lot (like some others, I do my analysis separately and just want to drop figures and tables in) and I think Knitr introduces some complexity that a lot of Markdown use-cases could do without.

Which isn't to say that I don't like RMarkdown—I think it's spectacular for a lot of use cases!—but if I could use pure Markdown with maybe a couple of extra filters to do things like tables from CSVs, I'd probably go for that instead. Although I do like being able to pipe CSV files into formatted tables with kableExtra :slight_smile:

EDIT: it looks like Pandoc does have a few filters able to turn CSVs into tables. This one looks like the most flexible, including both a basic syntax identical to embedding images (which makes sense to me, since I think consistent syntax is a big plus for readability) and a more complex one for if you want your tables formatted in a specific way.


#10

I think this is a great question. I'm a professor in the social sciences, so I'll try to keep my advice general and note where I think disciplinary differences might come up. I'm also assuming you're at an American institution.

I agree 100% that Word can be tedious, unstable, and difficult to use - I had similar experiences writing my own dissertation before I had ever learned how to use R. I also think wanting a reproducible dissertation is commendable and it is what we need to see so much more of! @jdlong's advice is really good as is @dano's. Whatever you ultimately choose for writing your dissertation, you need to remember a couple of things.

One, like @jdlong mentioned, you need to focus on content first. I advise my students to start writing in something simple like Byword. Just get the ideas down. The specific tool is less important than having a distraction free space - don't spend time worrying about formatting, figures, etc. Byword is nice because it is a Markdown based editor, but really any distraction free environment will do.

I don't know what disciplinary norms are in civil engineering. In the social sciences, half the chapters in a diss will not have any analyses in them that you would need RMarkdown for (typically). Your intro, lit review, methods, and discussion/conclusion chapters will not likely benefit from RMarkdown as much as other chapters. So unless you really like writing in RStudio, at the minimum find another markdown editor to use as well!

Another thing to keep in mind, which you hint at, is that dissertations live on in a variety of ways. You will use the same analyses for your chapters, publications that come out of those chapters, your defense, job market presentations (assuming you're going the academic route), and conference presentations. Having your analyses so tightly linked to your writing may ultimately mean reinventing the wheel when it comes to converting chapters into other products.

Your committee members are not going to want to get markdown documents, .tex files, or anything similar from you. They will almost certainly want word documents. You can try to show them the light, and there is a lot to criticize about this, but it is the nature of academic writing still and I don't think it is a hill worth dying on for PhD students. Learning pandoc or using knitr to knit to word will be your friend.

The same is true for some journals - they will not accept anything other than word document manuscripts. So keep both of these things in mind - your workflow is going to need to build in room for both of these eventualities. Again, disciplinary boundaries will dictate the extent to which this is true.

Speaking of formatting, you absolutely need to follow @dano's advice in particular about formatting your final dissertation. I do not use RMarkdown templates, so I can't give specific advice here, other than to say that you will have to follow an exacting format. Most institutions have someone designated to check this formatting before you defend. Their job is to make sure it is right, and there usually isn't a lot of flexibility. Ultimately, you will need a .pdf file that you can submit to ProQuest.

Finally, in terms of general advice, the best dissertation is a done dissertation. I do not think that spending a lot of time learning new tools is always the best route for students who need to get job market papers out and defend. I've watched students spend more time learning LaTeX than actually producing a good dissertation. In academia, you will get few bonus points for writing in RMarkdown or using other tools. You absolutely will need a good product (which goes back to @jdlong's point about content).

So what is best? My advice to students is to write their text in an easy to use, distraction free environment. Use plain text so you can track changes using git (@jdlong's advice!). Instead of writing the entire document in R Markdown, focus on having clear analysis R Markdown documents that can be easily tweaked regardless of what their final destination is (chapter, paper, defense presentation, etc). Once you have gone through editing and your committee has signed off on your content, then worry about typesetting. Decide how much time you have and what the best use of it is - learning LaTeX, developing something like what @dano used, or just using Word. Remember - the best dissertation is a done dissertation.


#11

Tons of fantastic advice here already, but also being a PhD student who is on the cusp of writing a dissertation and is a big fan of RMarkdown, I'll chime in too. My own trajectory might shed some helpful light as well, as I went from using Word >> LaTex >> Knitr with .Rnw >> RMarkdown and now am absolutely happy with RMarkdown and will not turn back. My happiness rests in the following reasons:

  • +1 to RMarkdown for being able to knit to .docx: I have a supervisor who wants drafts in Word. After a bit of back and forth with him and his ultimate hard stance to refuse to mark up PDFs, I settled on knitting .Rmd to .docx files to send him as drafts. So far this has been a happy compromise. Originally, when I was writing in LaTeX, I found having to do a second conversion (.tex >> .pdf, then pdf >> .docx in Pandoc) to be a big annoyance for me personally (more seasoned LaTeX users may have better systems in place for this).
  • -1 to LaTeX for its steep learning curve: While arguably worth learning LaTeX for many reasons (it IS more powerful with regards to getting into nitty gritty formatting/styling, and also if you need to use lots of math equations or the international phonetic alphabet), I found learning LaTeX to be a steep learning curve. Despite the fact that many argue it allows you to "focus on writing, not layout", I found this not to be the case for me. Especially in my early stages of learning, I spent a lot of what felt like wasted time trying to figure out which of my n00b errors were preventing the whole thing from compiling.
  • +1 for RStudio/RMarkdown for actually allowing me to focus on writing, not layout: Since Markdown is much simpler, I actually found I could focus on writing. Actually, even when I'm not writing markdown, I find myself using markdown styling (e.g., even in raw typed notes to myself that will never be compiled to anything greater, I still use #, ##, etc for headers and * for emphasis). To those who suggest using another markdown editor to just "get the words out" and avoid distractions: I did this for awhile, but find I'm ultimately just as happy writing in RStudio, really. If you want even fewer distractions, you can pop out the source pane and write solely in that.
  • +1 for RMarkdown for allowing integration of LaTeX syntax: sure you can't get the full LaTeX functionality, but you can use lots of its features, as many above have mentioned. I personally find this to be enough, though obviously that depends on what you need it for.
  • +1 to RMarkdown for integration with Bibtex: For referencing in RMarkdown, I always include my master .bib file and a .csl file in the YAML of my main .Rmd file. For reference management, I use JabRef. I like JabRef because it has a very simple interface and allows me to directly manage my .bib files (I say fileS, but really I actually just keep one master .bib file for almost everything and rely on that 99% of the time). Mendeley is great too (most of my colleagues use it), but I do believe you have to export a new .bib file whenever you've updated your Mendeley library (maybe there is a way to auto update, but I'm not aware of it). I also like that with JabRef, I can easily manage my Bibtex keys, which are used when you're referencing anything in RMarkdown. I don't think you can directly edit keys in Mendeley. The reason I like this is that I always use the same naming schema (firstauthorYear, e.g., smith1999, and an optional additional keyword if there are multiples, e.g., smith1999meta), so I rarely have to look up what the key is when I'm writing. There are addins that allow you to select the references you want to add from a dropdown menu associated with a library, but I like the simplicity of just being able to type continuously. I use the same naming scheme for the names of my articles, which makes it easy to search + open them if I want to double check something while writing.
  • +1 to Bookdown for existing. Okay, I haven't actually used Bookdown myself yet, but absolutely plan to when I'm truly in the dissertation writing stage as I've heard it's incredibly useful for chapter integration and a bazillion other features.

In preparation for the writing stage, I've also been compiling a list of resources related to exactly this topic for my own eventual use. Here are some of the resources I've curated for myself (in relative order of how often I refer to them):

EDIT1: apparently as a new user I can only post 2 links :frowning:... I'll try to post this list in a follow-up.

EDIT2: Still unable to post more than two links per post (I guess as a means to prohibit spam bots from joining), so I just posted them on my personal website (probably an easier way to manage as the list grows anyways, and only uses one link!): http://theaknowles.com/post/ongoing-curated-list-of-useful-resources-for-writing-articles-theses-in-rmarkdown/


#12

I think @thealk's post is full of great thoughts, but this one really resonates. My advice to academics who want to learn LaTeX is to pick something small and manageable for their first project. I think a dissertation or a CV (which is what I did) is probably not the right project, IHMO. If you're still early going in a PhD and think that LaTeX is how you want to write, take the time on an article manuscript or term paper to get your LaTeX workflow sussed out. I do think LaTeX is the best format for a dissertation in the end, but don't think that the benefits outweigh the learning curve for PhD candidates who pick the dissertation as their first foray into LaTeX.

I've also had the same response to LaTeX - I think I actually spent more time thinking about layout than I did when writing in Word at first. That isn't my experience now, but it was when I was learning. Markdown is really the only markup language where I've really expressed freedom from concern about formatting.

The way I read @dano's post is that, while you can write in RMarkdown, you'll still need some LaTeX skills to tweak the .tex and .cls files needed to meet your institutions formatting requirements. Again, if you're still early in your PhD, finding some likeminded peers to build an version of what @dano describes that is specific to your institution could be an amazing way to develop LaTeX+GitHub+R skills.

Speaking of packages...

I feel very conflicted about this advise from @hoelk. Like LaTeX, I am not sure the dissertation should be a place where you try and develop new skills like package development. If you want to package up your code, awesome, but build a package first before the dissertation so you understand how things work and how to do it well.

The tricky part of a dissertation is you are often figuring things out as you go, and the code you ultimately produce is going to reflect those iterations. It also is going to be very specific to your data and problem. I'm not sure most PhD students have the time or perspective to really grasp how their code can generalize to other projects, and I don't think I would advise students to put time into making a full fledged package (with testing, error messages, sample data) even if they did have a solid idea. I also think that packages should be very specific in terms of the problem that they solve, and a dissertation may really be better expressed in multiple packages depending on its complexity and breadth.

Case in point - I am now 3 years and 2 days out from graduation. I am just now really grasping how a technique I developed for my dissertation can be generalized and expressed in package form. This is only one piece of the code that my dissertation evolved from. One package for my entire dissertation project would not be appropriate.


#13

@chris.prener I totally agree with your critisism and it probably was a bit of a communication failure on my part... I did not mean he should make a general, reusable, CRAN-ready package out of his thesis. I like to abuse packages as project-folders on steroids. The effort for setting up a package is basically zero once you've done it a few times, and you get a nice place to specify your dependencies (DESCRIPTION), manage a NAMESPACE for your project, and you can work with all the awesome package development tools like testthat and usethis. As soon as you do something like sourcing a functions.R file, you are imho much better advised to just to make a package. That does not mean it has to be something you would want to publish (or even other people to see ;)).


#14

got yah @hoelk - perhaps a misinterpretation on my part as well! I think you're right - these are all great tools by themselves. I think my earlier advice is still what I would tell a PhD student like @durraniu - if you already know what a NAMESPACE is and have used tools like devtools, usethis, etc - this could be an excellent way to keep your work organized. If, however, this is your first rodeo, better to leave packaging for a post-graduation exercise. Just my two cents here.


#15

Wow! I wasn't expecting so many responses in a day. But this is all great advice, thank you, everyone.

One major (and unintended) side effect of my question was the LaTeX vs Rmarkdown debate. Personally, I have tried learning LaTeX a few times but not pursued it due to two reasons:

  1. It is not used in the engineering faculty at my institute, University of Windsor. So, my supervisor and other students are not familiar with it. Everyone uses MS Word.
  2. I have no idea how others focus on writing with all the backslashes on the page. This issue alone was enough for me to not keep learning LaTeX.

So, I will go with the Rmarkdown option.

Considering all the advice in your great responses, here's my new plan:

  • I'll explore bookdown and the recommended variants e.g. thesisdown in detail

  • I'm going to keep all of the analysis steps in separate script files. Additionally, I'd create plots/tables in a separate script. So, if I re-run any analysis file, I'd also re-run the plots script to get the updated figures. And if only a little tweak is required (e.g. plot theme) I'd simply modify the plots script. This will be the only script that I'll source in the R chunk in my thesis chapter(s)

  • For my supervisor's review, I'd knit to .docx. One issue would be handling the changes that he makes with version control in Word turned on. But I guess there is no automatic solution to that.

  • I'm definitely going to check out the rticles package documentation. I know that right now it does not have any templates for journals in my field (my research is in transportation engineering, a branch of civil engineering). So, I might need to create my own.

  • I've been using git and github in RStudio. Currently, I only know about commit, add, and push, which have been mostly what I needed. But it is definitely worthwhile to dig in more

Please let me know if there's anything you'd add onto the above list.

I have never created an R package. And at this point, I don't feel very comfortable to do that for my analysis. But I do try to follow Hadley's advice on creating a function if the same analysis is repeated more than three times.

I use Mendeley for bibliography, which works well. One thing that I like more in Word is to be able to easily resize figures using mouse. I know that I can provide fig.height and fig.width in global chunk options in Rmarkdown, but sometimes custom changes are required. Are there better options to handle size of tables and figures? Please let me know.

I'd love to see a real thesis repository that used Rmarkdown. Once again, thank you everyone who has responded.


#16

I read the good advice given here and I don't want to repeat them, but my formula was:

  • Bitbucket: a large repo that got so large at one point that I had to learn about reducing repo size. So one of the things I kept thinking was whether it is better to have one repo per chapter or one big repo. Depending on the size of your files and thesis that might be an issue to think about.

  • Rmarkdown, because I use R a lot. Each chapter was a subfolder with their own /data, /R /output sub-sub-folders. Remedy is a great RStudio addin to assist during writing.

  • One nice word template, in my case @jhollis 's (https://github.com/jhollist/rmd_word_manuscript and hereby I thank him for it) that I modified according to my needs. This is because coauthors, advisor, and school were expecting a word document to revise.

A problem I found was with tables that needed better formatting, and sections in word that needed to be horizontal - I had no choice but to format them -and introduce page numbers- manually but that's pretty much the only part of the word document that I formatted manually.
I control figure size by saving the file and including it later, manually either with ![]() or with knitr::include().

  • References were directly formatted in rmarkdown - I prefer zotero and love its new option of saving automatically a .bib file from a collection in the repo folder, and cite using [@xx] (I guess that's pandoc + knitr)

#17

All sounds great, but I think I'd caution you against only sourcing your plots file - one of the great things about RMarkdown is not only integrating figures, but also summary variables, coefficient values, p-values, etc. via variables in your environment too. You want whatever scripts you're sourcing to give you access to those so that, whenever you have to update any aspect of your analysis, all your reported values get updated as well. I like the idea of having your scripts modular, but I wouldn't want to sacrifice access to other variables relevant to your analysis report. One option, to keep it modular, might be to source the analysis script within the plot script to maintain access to all your analysis variables. Others may have better ideas too.

EDIT: Also, as an afterthought, regarding better formatting for tables - I just had a discussion about this with a colleague, and she recommended looking into the flextable package in combination with captioner for better control over table formatting when compiling to .docx.


#18

Its worth reading this thread on organizing documents in a data science project... I suspect there are concepts which are very helpful for you as well.


#19

Oof, yeah.

FWIW, I learned LaTeX for my honours thesis and that was a Bad Idea. I'm already an okay coder, so I was comfortable learning new languages, but tearing your hair out three weeks before submission because your thesis won't compile sucks. LaTeX (or even, to some extent, RMarkdown/Markdown) is for people who don't puke when they hear the question, "What if writing was more like programming?"

On the other side, I've written manuscripts in Word because that's what my colleagues were using, and sending references from Zotero was a bit of a struggle, especially with revisions (and that's before you bring extremely variable journal submission systems into it). I'd say learning to use a good reference manager is a pretty universally important skill in academia.

I think pure Markdown based on Pandoc is a good compromise in terms of readability and "getting straight into writing"—once it's set up—but I think there's a lot of room for tools that abstract the learning curve away specifically in academic contexts (thesis, papers, etc.).

Services like Overleaf and Authorea are also trying to solve that problem, but they have their own limits and often ongoing pricing. I think Authroea's a solid choice for papers, but it had some limits around thesis structure when I last tried it (though that might've changed). It does allow 1 private document at a time for free and has git integration underneath, which is pretty rad.

EDIT: it looks like Authorea is thinking about how to better accommodate a thesis, but they're not quite there yet (and they want you to publish each chapter as a separate article, which either means coughing up for a sub or being able to make your chapters public as you finish each one).


#20

I will never get into the debate of Latex vs markdown. However, as I mentioned, you really should try Lyx, it will make your academic life much much easier.