Einar's blog

Emacs on Windows

I have to use Windows at work. At home, I use GNU/Linux and Emacs thrives, but using Emacs on Windows is different. There is an Emacs port that installs fine and the editor runs well enough, but the problem is that there are a lot of free software tools that integrate with Emacs that are either hard to set up or not available at all on Windows. Some are available through chocolatey, winget or msys2, and that helps. In addition to installing tools like pandoc, latex (texlive), imagemagick, unoconv (for docx and odt in doc-view mode), aspell, mupdf… you also have to add each individual programmme's path to the exec path when running Windows, unlike on GNU/Linux. It is very cumbersome, especially since the path you need vary from package to package and is unpredictable even if installed with the same tool. You also have to reverse every slash when you do that, which makes it even more annoying. You cannot just copy the path from File Explorer. LSP servers can be installed with npm which you can get by installing node.js with chocolatey. Git is available through msys2. There is a good video on the Emacs Elements Youtube channel about setting up Emacs on Windows that helps you get the basics installed and configured.

Even after doing all that work, I found a lot of papercuts everywhere. On my other machines, I am used to using Ansi-term in Emacs as my terminal. On Windows, Bash is not available, but you can use shell-mode and configure it to use PowerShell. It lets you get to node, npm and git, so it is rather nice to have even if it is not a POSIX-compliant shell. Fair enough, I guess, but then I open up a python file and hit C-c C-p to start an interactive shell, but no, that doesn't work, even if I have python installed through chocolatey. In addition to things not working even after a lot of setup and me having to adjust to another workflow since tools like Bash that I take for granted are not available, the amount of extra configuration compared to my normal config also meant that either I would have to have two separate configs, or I would have to pollute my normal config with a lot of code only useful on Windows and with code to run either this or that depending on the OS. It is doable, but it is cumbersome.

Luckily, there is another way. WSL2 comes with WSLg which let you run GUI programs with the Weston Wayland compositor. I find that there are a million papercuts in WSL2 since the distros you get are not actually those distros, but their WSL2 versions which behave slightly differently, but it is still the best experience you can get on Windows if you want to use good free software tools like Emacs. In the newest Ubuntu LTS (24.04), WSL2 was smart enough to start Emacs as a deamon and only surface Emacsclient (not Emacs) to the start menu on the Windows side. I pinned it to my task bar so I can launch Emacsclient with Super - 1. By using lxappearance and installing my standard icon and widget themes (breeze-gtk-theme, which lets me use breeze-dark and papirus-icon-theme) and cloning down my config which sets modus-vivendi as my theme I got Emacs to look like I am used to. Unfortunately, every WSLg window gets an ugly Windows7-style window border that doesn't respect the dark mode I have set in Windows. It looks ugly and wastes space. (At home, I have no window border when there is only one window on a workspace and otherwise use 2 pixels that show me which window is active by colour. The joys of a good tiler and the freedom to choose your own WM or DE is only available on GNU/Linux.) In Windows 10, when I resumed from screen locking or sleep, WSLg windows would disappear, but they seem to not do so in Windows 11, so that is a nice improvement. I tend to fullscreen Emacs with Super - up arrow after launch and alt-tab if I need to get to another window.

The big advantage of using Emacs on WSL2 is that all the free software tools I know and love are there and integrates with Emacs normally. I don't need to set paths or do any other non-standard extra configuration. I can use the same config as everywhere else, cloned down with git. There is almost no context switching, and I enjoy the same efficiency as I am used to, which are two of the main points of the somewhat all-inclusive Emacs lifestyle. To avoid Windows' inefficient window handling (I calculated that with a conservative estimate, using it instead of a tiling WM steals 3 whole work days out of every work year.), I try to do as much as possible within a web browser to limit the number of windows I need to handle. We have MS365, but instead of using the standalone Windows apps, I use Outlook, Teams and OneNote in Firefox. That way, I only have a couple of full screen windows to alt-tab between instead of a lot of them. After living in tilers for half a decade on my home machines, the inefficiency of floaters annoy me, so anything that brings me closer to a sane setup helps.

There is discussion going on in the Emacs community about the Windows and Mac ports of Emacs. Since there are no contributors to the Windows port, there is discussion about closing it down unless someone from the community steps up to help. After trying (for half a year) to use Emacs on Windows and still ending up using Emacs on WSL2 instead since it works a lot better, my thoughts are that there is no longer a need for the Windows port. You get Emacs the way it is meant to work on WSL2. On Windows, Emacs works, but a lot of the functionality that depends on external programs do not, and it is cumbersome and time-consuming to set up. If you are used to the real thing, it is too hard to adopt to a lesser experience in my opinion.

For new users trying it out, the Windows version would seem to be lacking features that are actually there if the user installs the external programs that are needed and is able to configure it to use those features. And it would seem very cumbersome to set up. It might dissuade new users trying Emacs out on Windows from delving deeper and finding the true power of the editor. Since WSL2 works rather well on Windows 11, if I were to recommend a Windows user to try out Emacs, I would recommend doing it through WSL2 instead of the native way. So if no one steps up to maintain the Windows port of Emacs, I am not certain that Windows users loose out on the Emacs experience. Instead, they get the better experience by using WSL2 in my opinion. If the Windows port is dropped, it might also make it possible to clean out some legacy code.

I would guess most Emacs users are on GNU/Linux with a minority on MacOS. Emacs users know good tools. That is why they use Emacs. When they have a choice, they choose good operating systems, hence the limited interest in the Windows port. My guess is that the people that use the Windows port are people who have to use Windows at work and have done so for long enough that WSL2 was not available at the time they setup their config and they have learned to live with the Windows port after having spent a lot of time setting it up even if some functionality we take for granted on GNU/Linux is just missing. If someone steps up and does a lot of work on the Windows port to make it less cumbersome to use, that is great, but my guess is that nobody will do that and that the Windows port will die. As long as Microsoft keeps WSL2 around, Windows users are better served with GNU/Linux Emacs than the Windows port. Spending the extra effort on the Windows port seems like wasted effort for the main development team driving Emacs forward. I think the idea floated by the Emacs maintainers of letting the Windows port die if no one takes on the responsibility to maintain it is the right choice.



All content is shared under the terms of the Creative Commons Attribution-ShareAlike license.