In May of 2021 I started a new job. On my first day of work I imaged my workstation with Fedora; I was coming into a sysadmin job in a primarily RHEL shop so this seemed appropriate. Upon getting my laptop I was informed that I could not install Linux on it – VPN access was Windows only.

"OK, no problem", I thought to myself. I'm not a huge Windows fan, and I hadn't interacted with it meaningfully since probably the early 00's, but I figured how bad could it be?

As it turns out – not too bad. I was surprised to find there was some basic native window tiling behavior in the window manager, and with the release of the WSL and some flashy new windows terminal apps, I was pretty excited about how familiar it would feel.

Unfortunately, I ran into a number of issues as I was exploring trying to get Windows to feel more Unix-y. I won't go into detail in this post (maybe another time), but I quickly discovered that there was a lot of muscle memory and UI workflows that just seemed unavailable to me in Windows (despite heroic community efforts to improve a lot of the Windows experience).

Before starting this new job, I'd been a long time Vim user, but unrelated to this new job I'd started exploring Common Lisp programming, and as such had setup Emacs/SLIME. As part of that foray into Emacs/SLIME I'd discovered eshell, and as I was struggling to get Windows to conform to my preferred workflows I started to explore how I could use Emacs, elisp, and it's packages ecosystem to make my Windows experience more Unix-y.

Initially I downloaded the Windows Emacs build and was pretty happy with the experience. I could use eshell to navigate the Windows file system in a familiar way, and had set up an Emacs Org mode file in my company OneDrive that I could easily update and track my work/notes in. When I was in the office on my Fedora workstation, I could easily update and keep notes in my Org file and then seamlessly access them on my laptop from home.

The problems started arising when I wanted to do development for Linux systems on my Windows laptop, and easily be able to edit and quickly iterate.

First, I tried setting up the WSL so that I could have a local Linux environment to do low stakes logic tests in. Unfortunately, the presence of a VPN tunnel seemed to cause a lot of problems for WSL and I couldn't get networking to work correctly in the WSL environment. This was kind of a non starter. I spent a decent amount of time trying to unravel it, but it quickly became a time sink that wasn't producing anything so I gave up.

See here for more details on this problem: https://github.com/microsoft/WSL/issues/5068

WSL not working, I tried using TRAMP. The idea was to just open files on my Linux workstation over SSH and then manage everything natively there using an SSH session. I had a number of issues that I couldn't trace down, but the biggest was that using the plink TRAMP method would indefinitely hang emacs on windows, forcing me to close it with the Windows task manager. As with above, had I spent a reasonable amount of time trying to debug this, I probably would've been able to figure out the error (which was probably a misconfiguration on my part), but as with above, it started to become a real time sink and I just wanted to get to work.

Eventually, I seemed to figure out something that worked beautifully for all of my expected cases.

Emacs has a server mode that covered all my bases and allowed for all the flexibility I ended up needing.

What I do is start a terminal emacs session in tmux with emacs -nw on my Linux workstation at the office. I can then do M-x server-start which will start the Emacs server. When I'm at home and working from my windows laptop, I have to use Emacs exclusively in terminal mode. This of course has some tradeoffs, but it surprisingly works very well, and even has great terminal mouse support (M-x xterm-mouse-mode). I can run any number of emacsclient's in tmux windows to easily manage and organize all my different development projects AND I can access the state of any of the other sessions from whatever session I'm in, just using the native Emacs buffer functionality.

Additionally, when I head into the office, I can seamlessly attach to the running Emacs server from GUI Emacs and pick up right where I left off.

There are a few obvious compromises with this setup.

Firstly, I can't natively address the windows environment from my terminal, as Emacs is actually running on my Linux server. This however kind of turned out to be a non issue, because I'm never actually writing any software for Windows, or doing any work with it. I'm just forced to have it installed on my laptop.

My sysadmin environment, for lack of a better term, has always been a large number of tmux sessions managing different aspects of the job. For example a tmux session for "$web Team Systems", a tmux session for "$app Team Systems", etc etc. By integrating my development environment into a similar tmux session, it allowed me easily hop in and out of different development contexts, regardless of which system I was using; just like with my "sysadmin environment".

The immediate question that arises from this conclusion is: "Well, if you're just doing all your development in the terminal, why not just use Vim?"

This question is not posed to restart the age old flame war, but considering that is exactly what I used to use, I should address it. The main reason is that, to my knowledge, I cannot run a Vim session in the terminal, and then "attach" to it with gvim (having all my tabs/files/etc open and available) when I come into the office and use the workstation locally.

There are many Emacs features I've come to love, which I might cover another time, but this one feature has really got me stuck in Emacs (plus there is the famous EVIL mode, which smooths over that transition quite a bit).

To come back to the original point, the reason I no longer worry too much about the Windows experience is that through emacs+tmux+ssh, I don't really ever have to interact with Windows. It provides a basic interface to the web browser and to team communication, and virtually every other part of my job can be done over SSH in cygwin. In this way, I've kind of side stepped the purpose of this blog post – I've just described how to use skirt actually using Windows as much as possible, as opposed to addressing solving these problems in a more Windows-centric way.

The second major compromise here (I touched on it above) is that I end up using emacs as a terminal IDE far more often than I'd like. But given the choice between a very robust and functional development environment available over SSH and having to go into the office every day, it's a pretty easy trade for me.