At the beginning of this year, I announced I was jumping into the Linux ecosystem, full steam ahead.

It’s been about eight months, and I’m still here, with the one exception of video calls, which I’ve never pulled off to my liking on Linux. (The problem is the recording calls part, combined with the good-noise-cancellation part. Any thoughts? I’m all ears!) Anyway, consider this one of those periodic updates I’ve been doing.

I’m enjoying my experience and finding it getting better over time. And no show-stopping crashes of late, either. (Next time I write one of these, I need to tell you all about how great the PaperWM scrolling window manager is. There’s nothing quite like it, and I think other operating systems could learn from the GNOME extension.)

But I’m starting to realize that there are some elements of what I am doing that are not working, and I think it comes down to how I manage my writing.

What my editor setup looks like in VS Code.

See, here’s the issue: I am extremely picky about text editors, particularly when it comes to my tools of choice for writing. And when I started in the Linux ecosystem, I didn’t really find an editor I loved. Some had downsides I couldn’t look past (slow or lacking internal file management, the decision to auto-convert Markdown to rich text), and others just felt a bit half-baked. So, I decided to use a code editor to manage my writing, landing on Visual Studio Code because of its flexibility and solid integration with Docker and GitHub, which mattered to me for coding and server maintenance. I wanted something that was cross-platform and relatively malleable, and it seemed to fit the bill.

My thinking was simple: Hey, code tools are pretty hackable. I can make this work for writing, no problem. To get started, I pulled elements of code tools I liked—I transferred over my preferred fonts from iA Writer and made the theme more minimalist. And I learned to appreciate having access to a top menu of options at the press of a key combination.

For months, this more or less worked for me. I added spell check via a local LanguageTool server, and to manage my files in a somewhat organized way, I moved away from Syncthing for articles and used a self-hosted Joplin server. (I didn’t love Joplin as an editor, but I thought its sync server, which could be self-hosted, was pretty cool.)

But over time, things about this setup started to bug me. I started to notice I was making more spelling/grammatical errors that I was having to correct on the backend. In part, this is a side effect of the fact that VS Code (and Linux in general) doesn’t have an autocorrect function. That’s a feature from MacOS I didn’t realize I was quite so reliant on until I no longer had it. I added some additional steps as a backstop, including an extra self-edit step on longer pieces that I do in Google Docs, which has more robust grammar-editing tools. But, ultimately, it wasn’t quite the same and added additional work to my process.

And my decision to use Joplin sync, while on the surface a good idea, meant that I needed to keep Joplin open as a background app. And it wasn’t always loaded at startup, which meant that when I loaded VS Code, if a file was open and unsaved, that open file lost its connection with the original document I wrote. The result was that I experienced a small amount of data loss because of some open tabs I didn’t realize were no longer connected to the sync server. Oh, it was nothing major—only a few text files that exist elsewhere. But that was clearly a huge bummer and a potential long-term risk, and the result of taping together one too many tools.

My current setup in Obsidian, in case you’re curious.

When I realized this was happening, I suddenly second-guessed my approach and decided to dig into editor options, and ended up going with a tool I had largely discarded because of what I saw as its organizational complexity—Obsidian. Having played with it some more, I have decided that I can ignore some of those complexities (I have absolutely zero need for mind-mapping) in exchange for a consistent cross-platform writing experience.

While it doesn’t have autocorrect, either, it plugs into tools I already use (the aforementioned LanguageTool). Additionally, its extensions, including an excellent autocomplete function available as a third-party extension, feel like they were built for writers, rather than programmers. And rather than messing with an unreliable approach to syncing, I decided to go back to the tried-and-true Syncthing.

To be clear, I’m not dropping VS Code in general—I find it an exceptional tool for managing remote servers and working on code-based projects. But I think, after about six months of writing in a code editor, I’m kind of happy to be back writing in a dedicated writing tool once again. (Even if I will continue to hold the torch for a possible iA Writer Linux version.)

No tool will ever be perfect, even something as awesome as Syncthing, a peer-to-peer Dropbox replacement that I consider the best single tool I have come across in the past five-plus years. I have been using it to sync my Obsidian vaults on my phone, only for a glitch to hit me there. (Essentially, the app makes the folder read-only at random, something I can only fix by using Syncthing’s secondary web interface. Y’know, wonky.)

But I think that this reflects the not-often-discussed nature of switching operating systems. In so many ways, a small feature I never even really thought about on MacOS, built-in autocorrect, turned out to be kind of an albatross in my Linux setup.

That’s the nagging 10% that can be the difference between a great experience and a frustrating one.