Posted on Dysfunctional Programming 2021-08-27
On my current development workstation I have tried almost all major operating systems, from macOS (Hackintosh) to illumos. As a desktop environment all are terrible. Considering my hardware and peripherals, I’ve never really had too much of a problem with Linux, my default choice for the last decade and my current target deployment platform, but it turns out that even when running a Hackintosh, everything is just better. This isn’t to say that there aren’t some things that Linux is better at even on the desktop, but generally no single environment really satisfies me, and in fact generally annoys me with bugs, bad performance and inconsistencies.
Recently I tried WSL2 again. The landscape has changed over the years and I’ve
found that the latest state of things in Windows 10 actually works out quite
nicely for me. When I’m developing outside of a browser I don’t stray too far
from the terminal, so when I’m running Vim and my development tools inside
tmux, it’s just Linux. I get the exact same experience as I would on Ubuntu,
but my bluetooth earbuds, my webcam and hardware acceleration just work and
really well too. In a typical day I don’t need to cross the file-system
boundary and when I do it’s either because I’m running a background backup job
with rsync in Linux transferring files to an NTFS formatted external USB drive
or I’m viewing Linux-hosted content in Chrome/Firefox/Edge on Windows. TCP port
forwarding is handled transparently and for local files you can use the
//wsl$ network mount, in either case I haven’t noticed any performance issues
at all. Once I had set up everything, there were two missing pieces left.
In my experience both macOS and Windows have terrible out of the box support
for custom hotkeys. I tend to use keyboards that don’t have any kind of
dedicated multimedia keys or function key modifiers, or if they do, require you
to do some kind of finger gymnastics to invoke them. This is why I have my own
scheme that I can setup as needed anywhere. On pretty
much every other operating system, because of X, this is trivial. Either the
desktop environment has an interface or a configuration file you can use to
define your hotkeys. Alternatively you can use a more generic solution such as
xbindkeys. Wayland clients also have their own implementations. The last
time I tried Windows, I used Microsoft
PowerToys, but aside from
including lots of other stuff that I didn’t need, there were certain
limitations that I came up against, such as the inability to define a 4-key
binding, which for my scheme at least, is a requirement.
I’ve now settled on AutoHotKey, an application I had heard about but never used and which addresses the requirement perfectly, here’s my current configuration:
^!N::Media_Prev ^!n::Media_Next ^!p::Media_Play_Pause ^!y::Volume_Down ^!u::Volume_Up ^!t::Run, alacritty.exe
You just enter this into a file ending
.ahk, create a shortcut to that file
and place it in the startup folder (Win + R
The other small missing piece was a shared clipboard between Windows and Linux.
Now, you can of course copy and paste in a terminal window, whether running WSL
cmd, PowerShell, Alacritty or
others, but what I was missing specifically is the ability to pipe in and out
of the clipboard on the command line. So what you get with
pbpaste on macs.
On Linux my tmux config includes these lines:
set-option -g mouse on set-option -s set-clipboard off bind-key -T copy-mode-vi MouseDragEnd1Pane send-keys -X copy-pipe-and-cancel "xclip -se ci -i"
It basically allows you to select with the mouse (or using keybindigs with vi
mode enabled) and copy into the clipboard the selection you’ve made. It’s a
small feature but for me a massive productivity boost and something I use all
the time, so without
xclip or similar on Windows I missed it.
I already knew that you could refer to
.exes in WSL and it would interact
with the application on the Windows side, so I began
investigating the Win32 C APIs required to do this
programmatically but after a quick search I found out about
which is the native out of the box solution to
xclip. I made a very simple
tweak to my config:
bind-key -T copy-mode-vi MouseDragEnd1Pane send-keys -X copy-pipe-and-cancel "clip.exe"
…and everything just works as expected.
0 a refurbished HP Elite Ivy Bridge system with a load of extra RAM.
1 as an example, instead of
xdg-open .that I use regularly for opening the current directory in the file explorer, you can do
2 I’m comfortable with C but totally unfamiliar with Win32. I also considered cross-platform solutions in Rust or Go.
Copyright © 2018 - 2021, Rory Bradford.