Getting the Hang of LaTeX
In my previous post, I discussed how I overhauled my workflow when I started my PhD and used Scrivener to manage writing my thesis. While this streamlined my writing tremendously at first, by the end it was bogged down by the same frustrations that I was hoping to mitigate. Fully anticipating this, a friend of mine persuaded me to use LaTeX to write my thesis. While I was averse to making this immediately because of how messy it would have been to transition mid-way, I nevertheless practised using LaTeX for writing other documents so I could be ready to make the change once I started the next project. In this post, I will reflect on how I have set up my approach to writing and editing with LaTeX, what the remaining niggles are when I use it, and where I am hoping to take this workflow from here.
Like a Cross Between Writing and Programming
LaTeX, for anyone unfamiliar with it, is a typesetting platform in which documents are written through plain text source code and then compiled into a pdf by the software. This means the day-to-day experience of using LaTeX is a cross between writing and programming. And like with programming, there is something deeply satisfying about being able to manipulate source code to have such precise control over the outcome. The build I went with was a MiKTeX distribution for Windows, and TeXMaker as my LaTeX editor.
An advantage of writing documents as source code is that I can use Git for version control. A lot of this is essentially integrating techniques from a programming and software development workflow: using Git, I can track every single change I make between versions from the start of a project, I can compare versions and revert changes non-destructively, and I can create branched versions for different projects. In addition, what the branched versioning gives me is the flexibility to then split a project into different parts, and then re-combine them upstream when I need to. For example, if I am working on a chapter that I then split into a conference paper or article, I can create a separate branch without messing up the source, and then cherry pick any changes I make to that branch back to the main document in the future. Whilst most people I know normally host their code on GitHub, I already host my web site on a VPS, so I decided to run my own Git repository. It gives me a reliable source of on-line back-ups for my writing which accurately tracks changes and versioning.
But this created the added step of having to sync with Git. Git is usually something run via the system command line, and having to go into a terminal to synch updates after any writing is tedious. Ideally, I wanted a LaTeX editor that did all of this for me directly. So to really double down on the duality between programming and writing, I ended up using Visual Studio Code as my LaTeX editor, having installed the various TeX-related extensions (LaTeX Workshop, LaTeX Utilities, LaTeX Language Support, Spell Right, and Todo Tree). I was also able to add extensions to replicate features that came with more expensive, proprietary software, such as being able to create in-line to-do lists. VSCode has in-built Git features that allow me to sync my work with the online repository conveniently. This made it an incredibly powerful LaTeX editor, and one I was already familiar with using from other coding projects. There was a brief moment where I tried using Atom for my LaTex editing just so I could have some separation between programming and writing via the software platforms I use. Both editors are functionally very similar. But I found Atom to be far buggier when running the extensions I needed, so I decided to stick with VSCode.
Overall, this setup integrates really well with my writing habits and with my programming. My new web site and blog are based on Markdown, so I am well within my wheelhouse using VSCode to write both. All of this is based entirely on opensource software. It gives me the flexibility to work remotely, somewhat, although with some limitations. Overall, I am quite pleased with the set-up I have.
Bugs to Work Out
Of course, this workflow is not without its frustrations. To begin with, it makes collaborating with others somewhat difficult because I am not using a platform other colleagues of mine would be familiar with. And while I have some friends who have an evangelising zeal when it comes to getting others to adopt this workflow, I would never presume to talk others into it. Also, whenever something gets this modular, there become multiple points of failure that can cause complications. For instance, there has been an update to VSCode that has broken the spellcheck extension I use, and I now need to wait until that is fixed and updated.
Moreover, while Git allows me to work more remotely, there are technical limitations that this places on the kinds of devices I can synchronise with the Git repo from. I considered using Overleaf as a browser-based LaTeX editor, but I have generally preferred to work on native apps rather than cloud platforms. Moreover, self-hosting an instance of the Overleaf community server takes far more resources than my VPS has, and it does not feature the Git integration that I would have liked to have. So using Overleaf would make working with the Git workflow a lot trickier, and while Overleaf does have similar version control, I would much rather have my files more widely accessible on my computer and server than stored on Overleaf
Finally, there are some more minor quirks that I need to adapt to. This includes things like using line breaks after every sentence for ease of line-by-line change tracking, or needing to migrate to Zotero as my reference manager because it works more seamlessly with BibTeX than EndNote does. These will bring with them their own learning curves and the need to change habits. But the biggest challenge, and one which I still have not managed to get used to, is when I am hit by the double-whammy of writer’s block and frustration with bugs in the code at the same time. That can get really demotivating.
All things considered, though, I am really enjoying this new workflow. There is something about approaching writing like a programming challenge that makes the experience really satisfying, and I like how well the end results are typset. Having discussed what my new workflow is like, I think I might in subsequent posts reflect on why we need to talk more openly about how we manage research work and writing.