As a long time Windows users, I could not understand why anyone would love emacs. It's slow on Windows and locked up often for me. When I switched to Linux on the desktop though, I understood. Input latency in emacs is less than in gnome terminal for me. Never thought I would say that emacs feel snappier than vim, but that seems to be the case in my current setup. Also, I recently discovered magit and now I don't hate using git anymore.

Emacs performance in general (not just Windows) has been a complaint forever. Back when Emacs was first launched, and machine memory was measured in megabytes, people joked it stood for Eight Megabytes And Constantly Swapping.

Today gedit has twice memory footprint of a tricked out Emacs, however.

Only back then it was true. Now it’s only slow on Windows for some reason (and maybe not universally so, though I don’t use Windows enough to have bothered investigating).

While that's true, what's not slow on windows except maybe AAA video game titles? e.g. the "right click" on the Windows 10 desktop takes time to show up (even on a high end desktop pc)... just to show a contextual menu.

It's still very slow with a lot of Elisp code (Spacemacs, for instance). Maybe the memory footprint is better than VSCode, but VSCode starts faster and is more responsive than Emacs with a ton of packages.

Still waiting for Guile Emacs to solve that.

Of all the problems Guile Emacs might have fixed, performance on Windows is not one I considered.

I don't know if it would, but I can imagine that replacing the aging Elisp interpreter would improve the situation on all systems.

Yeah but does guile even work on windows? Last time I checked it was still very much confined to *nix systems.

Guile probably would, but Guile Emacs is not ready (yet?).

I can't stand Emacs on Windows. Even trying to keep a simple TODO list in org-mode is painfully slow for me. I was explaining to a co-worker how amazing emacs and when I showed him all he saw was a lag ridden mess. I use it at home on my Linux desktop mostly with some python development and ledger-mode and it's amazing.

That's really unfortunate. I was using Emacs on Windows back around the year 2000 and it was fine. I wonder what happened in the meantime.

This is what I use and to be honest, I don't see any reason to use the windows version /at all/ for Emacs. WSL and VcXsrv requires minimal set up and works right away for me.

I used to have code in my config files to try and handle different paths, etc. when I was in windows vs linux and now I don't have to worry about that anymore.

The Windows GUI is a bit slow. I found that I disabled all the bars anyway though, so using the CLI version of GNU Emacs is acceptable even on Windows.

YMMV

The Windows version is complete unusable for me because of how slow magit is on Windows (though that's not the fault of magit or emacs).

I haven't yet tried WSL (I run Windows on a work issued laptop), so my emacs sessions run in a Linux VM to get acceptable performance.

Hehe insane, you get better performance in a virtualized environment! I understand why that could be but virtualization overhead exceeding native performance is bonkers.

You can give WSL2 a try. It has speed improvements.

> how slow magit is on Windows

I am relieved, though, that it's not just me.

From my experience, Anything that launches subprocesses is slow on Windows.

I use Emacs in Debian on WSL with X410 and it’s fine, no perceptible lag.

Git is definitely slower in Windows

Gnus is unusably slow for me. I wonder if that is related to Windows as well...

Where did you found Emacs 26.3 for Windows? The official FTP site has only 26.2 as the latest Windows binary.

This might not matter for your case specifically, but last time I was on Windows, I found it straightforward to compile it using the msys tooling. I mention msys specifically to avoid bringing cygwin.dll into the mix, which caused me no end of headaches.

http://git.savannah.gnu.org/cgit/emacs.git/tree/nt/INSTALL.W...

As with most things in that realm, the hard part is getting all the dependencies (libpng, etc) but (a) since msys2 switched to pacman that looks a ton easier (b) AFAIK building with those graphical libraries is a nice-to-have for w3m support, so if it's a hassle you can skip it

Just be forewarned that [again, last I checked] msys has a bad interaction if your machine is a member of an Active Directory domain, but you are road-warrior-ing and it is unable to reach the domain controller; one of my more popular SO answers: https://stackoverflow.com/questions/929495/why-is-mingw-very...

I guess you can try one in pretest?

https://alpha.gnu.org/gnu/emacs/pretest/windows/