#-*- 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.