Hacker News new | past | comments | ask | show | jobs | submit login

It’s moving, it’s just going to take a long time to get to where it needs to be. Personally I would be focused entirely on performance if I were to start making improvements.



May I ask, purely out of curiosity, where do you see does Emacs need to be? From social, cultural, technical or any other point of view that you are thinking, and why so.


At minimum it needs to be a lot faster than it is currently, and all of these comments about how you can configure it to be fast are just excuses. I’ve been using Emacs for years and my config’s performance is still something I have to hack on regularly.

Beyond that I think there’s a lot of low hanging fruit but it gets more controversial and you get a lot of really reactionary people asking why we want to attract new users, why anything needs to change at all, etc. So I’m somewhat loathe to make suggestions there, but at minimum I would try to integrate lsp-mode or Eglot as well as company (and maybe flycheck) out of the box.

I don’t think Emacs needs to be all things to all people. For one thing it has features that seem to exist mainly as misguided attempts to make it easier to use that serious users almost entirely ignore (I’m thinking mainly of Customize here). I would pare down the functionality to what the most serious Emacs users use in able to better focus on the rest, at which point it’s probably a fork, but you asked for my opinion.


> I’ve been using Emacs for years and my config’s performance is still something I have to hack on regularly.

The only performance issue I've had is startup time, and it doesn't bother me much as I have it running all the time. But certainly, if you want to keep launching new Emacs windows, you will need to optimize your config.

> but at minimum I would try to integrate lsp-mode or Eglot as well as company (and maybe flycheck) out of the box.

I can somewhat understand company-mode, as the default completion just sucks. You'll still get into an argument about which completion mode to use, as there are several good ones, and people who like a given one tend to hate the others (and then you'll get a lot of complaints from new users who have to find a way to change it...). Personally I think they should make ido and its ecosystem the default. It's good enough[1], and people who want more can modify to get helm/company/whatever. Also, ido comes with Emacs, and the others don't.

lsp-mode: IMO it's just not that "stable" and/or robust. While many love it, there are lots of complaints about people struggling with some of its quirks, and then just giving up and moving to VSCode. The other thing is that it should be trivial to turn off. As an example, I use elpy for Python programming. It's great for some projects, but for one-off Python scripts, it's incredibly annoying - so I keep elpy off by default and enable it only on some of the larger Python projects.

Flycheck: It's good, but I had performance issues. I finally dropped it for flymake. It would have totally sucked if flycheck was enabled by default when I was an Emacs newbie, and I would have erroneously ditched Emacs as being too laggy when all I would have needed was to disable flycheck.

[1] I used it for 10 years before switching to Helm. I still fall back on it sometimes.


The fundamental problem is that the large parts of the ecosystem do not use the built-in mechanisms for various reasons, which makes it hard to change the overall user experience by changing those mechanisms.

I personally use Eglot and not lsp-mode, as I found the latter extremely hard to configure. Ditto for using flymake vs flycheck. But it ultimately doesn’t matter which of these many packages gets chosen, as long as they dominate the ecosystem, provide a good experience, and are performant.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: