Hacker News Reader

Comment by jhoechtl | Hacker News Reader

The most core inards of Emacs are subject to bitrot. It doesn't play well with any Windowing system.

And as an editor it is quite slow/sluggish.

Hmm. I think it plays really well with macOS's windowing system. What am I missing?

I use emacs in my OSX Terminal windows without issue. When I've tried using it in Windows with vagrant ubuntu vm's, it does wonky things on screen redraws and clears but does not redraw - probably something fixable but I could not figure it out and just moved to Visual Studio Code for now on Windows. I speculate it's a Windows specific issue for running in a command prompt, for instance there's weird key combo for using cut and paste to/from the Windows/command prompt that is unnecessary when going back and forth from OSX/Terminal.

Also when using ssh to a web server over my slow connection I can run emacs but it's obviously redrawing the screen when I change the buffer, vi is much more responsive.

Hey I suggest you try installing it on WSL (Windows Subsystem for Linux). I tried it just last week to do some hacking different from my usual C#/Visual Studio development and was pleasantly surprised it mostly worked out of the box. To render more nicely I had to install X Window for Windows (can't remember the exact name of the library) but it was pretty much a very good experience. Only limitation I can think is you should not access linux files from Windows, but the other way around has no problem.

Also (may be different from your use case), using tramp-mode has mostly eliminated the need to run the emacs inside the server, I run it locally and fetches files using ssh.

Just to clarify this: You tried to use emacs on Windows in Ubuntu VMs and are asking it to compare to native performance of tools like VS Code? Have you considered running a native Emacs build too and see if that performs better?

It's quite speedy, unlike IDEs, and it's very well-integrated with good windowing systems.

Reply on news.ycombinator.com