#-*- mode: org -*-
* Emacs and Learning to Live with Windows
** Background/Preamble
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).
** Enter Emacs
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.
** The Beginning
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 [[https://orgmode.org/][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 [[https://www.emacswiki.org/emacs/TrampMode][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 Server Mode
Emacs has a [[https://www.gnu.org/software/emacs/manual/html_node/emacs/Emacs-Server.html][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.
** Compromises and Other Thoughts
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 [[https://github.com/emacs-evil/evil][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.