Hacker News Reader

To be fair, improving performance on Windows is not really a priority for GNU. From the GNU downloads page for emacs (https://www.gnu.org/software/emacs/download.html#nonfree):

> To improve the use of proprietary systems is a misguided goal. Our aim, rather, is to eliminate them. We include support for some proprietary systems in GNU Emacs in the hope that running Emacs on them will give users a taste of freedom and thus lead them to free themselves.

I fully understand GNU's ideology and I understand no one owes me an Emacs that runs smoothly on Windows. I'm just sharing my experience so far.

So how does the slow tasting freedom help achieve that goal?

So how does slow tasting freedom help achieve the goal?

It doesn't. Stallman hand-waved the "taste of freedom" nostrum to avoid throwing away the man-years supporting emacs on Windows and Mac. The same stupid argument was made to justify the new Android port.

Emacs runs perfectly on macos though

I'm one of those people that stays in emacs all day, and you're right that the Windows port is basically useless on it's own. I use the emacs-w32 package from Cygwin (it is a real GUI emacs that doesn't require an X server but also integrates with the Cygwin environment) though, and that has gotten me productive on lots of corporate workstations where running desktop Linux is out of the question.

I can't speak for emacs performance on windows (you surely have very good reasons to put yourself through devving on windows), but if you're a big vim user I'd highly recommend looking into evil mode, to bring vim bindings into emacs. I find emacs native key bindings kinda stupid, and modal editing to be superior. There's also full emacs config suites around this, such as spacemacs and doom, if you want to explore how they integrate vim-ness into emacs.

Emacs + evil mode has been my primary text editing environment for 7 years now.

Installing evil mode was surely one of the first things I did :) Right after set a dark theme ofc.

Emacs-eat is supposed to work on windows, and may give you a faster e-shell.

Note that you can use things like `pcomplete` and `eshell-syntax-highlighting` to make eshell fairly smart. The fact that my shell can use corfu and the same completion, filtering, and ordering as the rest of my emacs is great.

Thanks, I'll take a look at these eshell batteries.

I became persuaded of the superiority of eshell when I could use corfu for completions. So. Cool.

I hear WSL is snappier. Sadly NTFS optimizes for a completely different file usage pattern than extfs and the native win emacs has poor performance.

I ran Emacs on Windows and used it every day for most of the past year, first natively and then in WSL. I can confirm that performance is many, many times better on WSL, in lots of ways.

Unfortunately, WSL's GUI support is extremely buggy on multimonitor setups (and maybe elsewhere), so you may have to restart your Emacs session often to get window management or even just clicking around to work right.

Have MS managed to figure out window snapping for WSLg yet? From what I've heard (maybe this is dated) there are a bunch of limitations that come from them using a primitive compositor for their Wayland setup.

Xpra (or even a full X server, if you don't mind losing X clients on sleep) has been a lot better on the integration front.

If magit is slow, its likely because of your filesystems performance profile with gits data structures on-disk.

Source: I benchmarked git on windows and decided it wasn't worth trying to fix it.

Could FAT be actually better than NTFS in this regard?

It could be, however I also never tried it.

On remapping C-x -> C-j:

You are meant to press Ctrl with your right hand when you press C-x. Those who came up with these keybindings had this way of using in mind. If you remap it to C-j, it becomes inconvenient because you need to switch between left and right Ctrl in the middle of a chord (though, in some cases this is inevitable). Also, many keybindings are configured so that you can do both C-x (some key) and C-x C-(some key). That is you don't need to release Ctrl in the middle. But, if you change to C-j, then this becomes difficult to execute. Imagine pressing C-j C-m (or C-jm) for example.

Bottom line: not a good idea.

As for Windows: (I haven't used it roughly since Windows 7, and even then only in one work place that required it). How does the OS affect whether you close Emacs between sessions or not? Or is it still the case that you need to reboot Windows a lot?

Also: Magit wasn't always very slow on Windows (although both Git and Magit are and were always slower on Windows, but the magnitude varied at times). As someone who used Magit long before current maintainers took over: it evolved, but not always in the ways that I would like it to. The original Magit is quite a bit less organized (internally, in the way it's coded), but it's a lot simpler and in some ways more intuitive to use.

Modern Magit went through a cycle where they tried to do some performance optimizations, but then they added more features, and the performance gains were lost. Today, Magit is plagued with performance issues, and is a very complex (and a very unfriendly) program to debug: it's neigh impossible to get to the source of errors or trace the performance offenders. But, it's still better (at least on Linux) than anything else I tried by a large margin. So, I'm ranting about performance, but will keep using it anyways.

> You are meant to press Ctrl with your right hand when you press C-x.

I've been using Emacs for several years now, and I think the real solution is to turn Caps Lock into another Ctrl.

The right Ctrl key is in a very uncomfortable position whether I press it with my pinky or with the base of my hand, so in practice I basically never use it. The left Ctrl key is not as bad, but it's still not comfortable if I need to press it often. Caps Lock, however, only requires a slight adjustment of my left pinky finger to press. Simultaneously pressing x with my left ring finger is slightly weird, but not uncomfortable. There are some other keys on the left side that don't really comfortably combine with left Ctrl or Caps Lock, but I don't run into them often enough for it to be a problem.

> The right Ctrl key is in a very uncomfortable position whether I press it with my pinky or with the base of my hand

When I used a traditional keyboard I rebound ctrl to be next to space so I could easily hit it with my thumb so the layout was like:

    [super][alt][ctrl][----space----][ctrl][alt][super]

But now I use a split keyboard(Kinesis Advantage) with ctrl/alt/super in thumb clusters that make hitting those modifiers really easy.

Yep. I do that same key remapping too. IIRC original suggestion was from Xah Lee

I use Kinesis Advantage 2, and have been doing so for about 10 years now. So it's hard for me to relate. But, in a rare event that I need to use a more conventional keyboard, I press right Ctrl with my thumb.

In the beginning of my exposure to Emacs I did rebind CapsLock, but that offered little relief. The true quality of life improvement comes from not pressing Ctrl+<anything> with the same hand. Anything that requires Meta or Ctrl -- automatically use both hands.

> You are meant to press Ctrl with your right hand when you press C-x.

Nothing's stopping you from doing it that way, but since Steele and Moon started writing EMACS in 1976 on the PDP-6 and the PDP-10 and probably used VT52 terminals to access those systems, you're probably expected to have a control key on the home row to the left of the caps lock. The VT52 does not have a control key on the right side of the keyboard. I've found that Emacs's ergonomics are greatly improved by swapping the caps lock and left control keys on modern, IBM Model M-inspired keyboard layouts.

I believe this was / is still believed to be the "best historical keyboard" to be used with Emacs: https://en.wikipedia.org/wiki/Space-cadet_keyboard#/media/Fi... it has Ctrl on both sides.

Even if the 76's Emacs wasn't designed for it, most people with decades of Emacs experience would start salivating just from looking at this keyboard. I believe, that when anyone using Emacs is designing key bindings, be it today, ten or twenty years ago -- they think about something like Space Cadet.

> Imagine pressing C-j C-m (or C-jm) for example.

I'm not sure what it means since I just pressed <C-j> <C-m> and I had zero issue about this. I stated in the first post that I use capslock as ctrl.

> How does the OS affect whether you close Emacs between sessions or not?

I didn't say that I close Emacs between sessions. I meant (I supposed) some Unix people use tools like vterm and magit so they don't even switch to another terminal app. I instead constantly switch between Emacs and Windows Terminal.

I guess, it depends on the physical keyboard layout. The point about C-j C-m is that you'd have to crunch your index finger too much. Well, maybe that's not the best example, as that still seems possible. Try maybe C-j C-/ to really feel the strain.

> Windows Terminal

Why not use shell from Emacs instead? Emacs has a bunch of terminal emulators. One of those ought to work decently on Windows...

If you do it the way you describe, you will set yourself up for a painful experience. Because Windows Terminal (most likely) doesn't have the editing capabilities of Emacs, and (most likely) it doesn't use the same navigation / editing scheme as Emacs, you will have to switch between the two and make mistakes in both of them. It's really annoying to work like that, and it causes people who chose Vi or Emacs to use or to configure other tools to work in the same way their preferred text editor does it. But, ideally, they'd just want the other tools to be embedded in their editor (because any customizations they make for the editor will automatically extend to those tools).

Having to deal with switches in how you write or navigate text is similar to having a crying baby nearby or a loud pub etc. Most people wouldn't willingly put themselves in that position.

You didn't say it was Emacs's fault, but to make the point clear to others, Magit is slow on Windows because of how Windows spawns processes:

https://magit.vc/manual/magit/Microsoft-Windows-Performance....

While WSL might be "slow" relative to linux, emacs with lots of plugins is exponentially slower under standard windows. Also since emacs launches lots of processes and accesses a lot of files the windows virus scanners, including microsoft, slow things down a lot more. I don't use live virus scanning though and have my downloads folder automatically scanned and a nightly scan set up for my windows machine to avoid that.

The reason eshell doesn’t feel like a proper terminal is because it’s a shell that doesn’t run in a terminal but in an emacs buffer. A down side is programs meant to display output in a terminal emulator won’t render properly in eshell. An up side is emacs commands meant to display output in an emacs buffer will work beautifully in eshell and the entire output will be editable.

I’ve been trying to use emacs and vim/nvim on and off for a several years now but it always seems like a task in vain. Half of it works and it’s a real pain to get something usable.

I wish I could use Linux but I work in the gaming industry ina company that solely creates windows games so it’s not really an option…

I've had good results with wsl2. The only thing that frustrates me is magit performance on a big project with literally twenty years of commits. (It was originally an SVN repo.)

Windows gained support for pseudoterminals only in the last few years. I'd guess that eshell hasn't been updated to take advantage.