1. 5

  2. 2

    One barrier to entry is that I had no idea how to install it on my desktop

    I use Emacs via Cygwin

    GNU Emacs 26.3 (build 1, x86_64-pc-cygwin) of 2019-08-30

    There are pre-compiled binaries for Windows (native):


    The Emacs wiki has a bunch of info


    In my previous job I used Emacs extensively to plan my workday and to read email. I had a Windows desktop and used the native build (from memory, it’s been a long time). It worked fine.

    1. 3

      And don’t forget the real bleeding edge Windows pre-compiled binaries: https://alpha.gnu.org/gnu/emacs/pretest/windows/

      As a pretty dedicated Emacs user for the past 5 years, I’ll admit to having fought with Emacs on Windows (which I run on my work laptop). Most of my past work had been Linux-native so I was primarily using TRAMP and working on a remote system or local vm under hyper-v.

      I’ve been too chicken to turn on the Insiders channel to get WSL2, so I’m curious how the ergonomics are using native Emacs + TRAMP (into the WSL2 instance) vs. Emacs over X11.

      1. 1

        While I’m not sure what TRAMP is, I know that sometimes inputs can get lost when using terminal Emacs, depending on your terminal of course. Windows Terminal for example, treats Ctrl and Ctrl + Shift as the same thing so trying to do eg; C-c C-S-l to remove a link in org mode will actually fire C-c C-l (which inserts one). It also has some system bindings for keys like Ctrl + (zoom in) which can interfere with terminal Emacs. I’m sure any other regular terminal wouldn’t have the C-l / C-S-l issue though.

        1. 2

          From the official docs: TRAMP stands for “Transparent Remote (file) Access, Multiple Protocol.”

          TRAMP is the original “remote editing” before VS Code had it. It effectively lets you work with files on a remote machine via ssh/scp as if they were local (in most cases). Most Emacs modes just work without even knowing it’s a remote file. You can run the native Windows Emacs and still work within a WSL2 instance without mucking about with X11 etc. (There are some caveats, but even eshell supports it and I believe magit.)


          1. 1

            Ah! I totally misunderstood your comment then.

            This seems like a really interesting alternative, and if it works, I’d probably opt for a native Windows binary in that case. I might see if I can get it running on the weekend. Let me know if you end up experimenting yourself as well.

      2. 2

        Oh yeah, that is definitely true and I could do that for sure.

        Originally, I did have my development files on my C drive and kind of fumbled my way around with Powershell. When WSL came about, it was a lot more attractive being able to use regular unix tools and just apt-get install things.

        I believe it’s still the recommended case that you keep everything within the WSL environment for performance reasons? Either way, having to navigate to /mnt/c/code/ was a bit more tedious than being able to just do ~/code for example

        That was sort of the logical steps that lead me to keep everything inside WSL and hence why I opted to get emacs in there, rather than out in Windows land.

        On a similar note, I’ve found it much nicer running the WSL2 Docker Preview (docker daemon + kube inside WSL2) than having it run in Windowsland so it’s basically another reason for keeping my dev environment inside WSL, at least at work anyway.

        That said, maybe someday I’ll give the pre-compiled binaries a spin! Thanks for the heads up

        1. 2

          I should give WSL a closer look. I think it’s a bit sad Cygwin seems to be forgotten. It has served me well for many years, even as you say that dicking around with /cygdrive is a bit of a pain.

          Performance-wise I find it much faster to parse large log files using Perl in Cygwin than using pure PowerShell!

      3. 1

        The X Windows server I use for Windows is Xming, which has both a free and a paid version. The free version works like a champ with WSL - just run it, set DISPLAY=:0 and you’re good. But I guess it will be a little more complicated once I move to WSL2.

        1. 2

          I imagine the exact same steps as VcXsrv should apply? Just make sure it’s allowed through Windows Firewall and that the DISPLAY variable is set to the IP address within /etc/resolv.conf but I’ve never tried it myself. I don’t think it’s as complicated as I would have expected it to be

        2. 1

          If you’d like to be on the bleeding edge (and is what Doom Emacs recommends), you’ll probably need to compile Emacs 27 from source :(

          Emacs 27 decidedly isn’t bleeding edge – the release cycles are very, very long. I’ve been using 27 for months with absolutely no issues. Furthermore, the native JSON parser makes LSP et al far faster.

          …you do need to compile it, though.

          1. 1

            I did a bit of a search for an Ubuntu repository and could only find Emacs 26 via apt-get sadly

            You’re right though, bleeding edge probably isn’t the right term to use here. Compiling should be easy enough too and I’ll likely do that once I’ve committed my soul to Emacs haha


            1. 1

              Compiling should be easy enough too

              I use Ubuntu and like to stay on the latest version of Emacs so I typically use my own builds from source. Once you’ve done apt-get for the necessary -dev library packages, the usual configure, make, make install dance goes very smoothly. It can also be quite fast too if you use make -j and have enough cores.

              1. 1

                And a tip is that if you’re just building a newer version of something that has a package, apt-get build-dep that-package will get you what you need in 95% of cases.