Hacker News new | ask | show | jobs
by slightwinder 2396 days ago
There may be much going on with emacs, but so far it fails to move ahead. The project is just improving the old strenghts, but not fixing the old fails. And as time moves, they start to hurt more and more and more until they break.
2 comments

What are some old fails that need fixed?
One thing I notice: too many things cause unresponsiveness. 8 cores in my laptop and I can't install a package in the background, and semantic parsing interrupts typing. There doesn't seem to be any concurrency at all, things I do every day like eval'ing forms to REPL cause stutters.

I love that it allows makers to explore new ui paradigms (magit, lispy), but performance is its biggest downside.

Personally I don't see performance as a major issue, though some things can be a bit annoying. But note that the concurrency problem has been recognized by the devs and a recent version of Emacs introduced some kind of threads. So I think we can expext progress in the next coming years.
https://github.com/Malabarba/paradox lets you install packages async, by the way.
That looks like an interactive ui--I can't declare use-package forms in my init.el, and have the initial install and any updates be async and concurrent.
The big ones, to me:

- No support for threads or any other concurrency model. Any I/O and the entire UI freezes, no matter how many cores you have idling.

- Even on a single thread, the runtime is generally several times slower than comparable modern scripting languages. The GC is not so great, either.

- The drawing model is archaic. Every mode seems to have its own kluge to work around such basic tasks as "I want to display a simple table".

- Elisp is the worst Lisp dialect I've ever used. No packages or namespaces. No bignums. Weak regexes, using a syntax completely incompatible with any other. It's improving but very slowly. It finally got support for lexical scoping a few years ago.

Except for the generous contribution of Unicode support, it feels like a system whose technical attributes were not even terribly impressive for the 1980's. Emacs is truly greater than the sum of its parts. It has to be, because each part is worst-of-breed.

> The drawing model is archaic. Every mode seems to have its own kluge to work around such basic tasks as "I want to display a simple table".

It has pros and cons.

The pro is clearly that in Emacs everything is text, and can be processed as text, by using the same commands, keys and macros you use for everything else.

No other editor has this, and I cannot understate how handicapped I feel in those editors where some things are "off limites" and cannot be copied, because it's a designated "GUI" of some sort, instead just... text.

Taking that away from Emcas would IMO be a major loss.

Are you an emacs hacker and have the knowledge/power to fix the problems that prevent it from catching up to, say, a mediocre editor like Kdevelop?

https://news.ycombinator.com/item?id=17178246

No, I'm just a guy who's pretty content with emacs and wants to know what others perceive to be the major failings
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.