5 ms·

I agree with you on UX but disagree with everything else. If you use native elisp compilation, I find its speed to rival an average editor. Completions can be s

I agree with you on UX but disagree with everything else. If you use native elisp compilation, I find its speed to rival an average editor. Completions can be slow in lsp-mode but still faster than VSCode (and emacs itself ships with eglot, a less full featured alternative to lsp-mode, but may be faster. I haven't used it enough to judge.) This is due to shelling out to LSPs and the fact that not all LSPs are particularly well built. If you find your emacs to feel jank I highly recommend declaring "emacs bankruptcy" and starting anew with a fresh config. Defaults emacs ships with today are really good. That said I haven't used emacs on Android yet so I don't know how well, if it all, it works. I also think the UX of emacs tends to bend toward the user's own preferences rather than good UX, and the default UX of emacs is a bit bad.

IceDane 11mo ago
I've been using emacs for 15 years as my daily editor. One thing that never fails is that when I share the fact that I've switched away, emacs users fall over themselves to tell me I'm wrong. I assure you that my emacs setup is as optimized as it can be. Native compilation, all that jazz. I've compiled my own. But emacs is ultimately a lost cause unless something drastic changes. The single threaded nature of it means that you need to just live with your editor regularly freezing for a whole second while working in bigger projects using modern tooling. The only way to remedy this is to turn off as many features as possible and accept a worse tooling experience. Shifting the blame for emacs poor internal architecture over on the poor LSPs is silly. Every other editor handles this better than emacs. For now, I'm using zed and it was really an eye-opener to how fast an editor can be and feel. I replicated a large part of my workflow, basically all the keybindings, and while there are things I miss (projectile and some other things), I can live without them in exchange for not having my editor choke constantly when working on big projects while emacs chugs through json from lsp or something like that.
- skydhash 11mo ago
  You may have a very justified reason to switch, including nnot liking one aspect of emacs. But you are presenting it as a general flaw. Which people cannot obviously accept as it’s fine for them and they are not experiencing your issue (and as you know, everyone’s setup and workflow are different) As for the single threaded nature of it, it doesn’t bother me. Because what should be async already is. The only thing left that is synchronous follows closely the repl model of the terminal. I issue a command and I wait for the result. If the result doesn’t matter or I want part of it as soon as possible, then it can be async and there’s plenty of way you can make it so.
  - actionfromafar 11mo ago
    How do you make LSPs fast?
    - skydhash 11mo ago
      What do you mean? The language servers are independent projects from emacs. Some are slow and some are fast. And your project size is a factor.
    - G3rn0ti 11mo ago
      > How do you make LSPs fast? https://github.com/blahgeek/emacs-lsp-booster https://github.com/blahgeek/emacs-lsp-booster The fundamental issue is Emacs its JSON parser is currently still rather slow (not sure why actually). But in LSP mode it needs to parse the LSP server's many JSON response messages very quickly. The aforementioned booster converts all JSON into ELISP byte code so Emacs can process LSP messages much faster. I guess, the Emacs project will have to tune their JSON parser in the future.
  - IceDane 11mo ago
    > it doesn't bother me Right, so what you're really saying is that you are totally fine with your editor being unresponsive and janky during regular editing workflow, working with modern tooling, and that everyone else is just wrong for not feeling the same way. You do you. I lived with the same copium excuse for years, obviously, but I've moved past that now and into the year 20xx. I love emacs and truly wish that I felt like I could seriously use it, and in many ways, I feel like it's the ultimate expression of what an editor could be. But it's just suffering from being 40 year old software that hasn't seen significant modernization to meet the demands of today's development workflows.
    - skydhash 11mo ago
      Your assumption is that Emacs is unresponsive and janky during my editing experience and it’s not that. Everyone’s setup is different. Your configuration may be janky and unresponsive, but it’s not a generality.
- taeric 11mo ago
  You get the same behavior from any editor, though? Hell, you'd probably get similar behavior if you switched brands of power tools. People are attached to their tools. That said, it would help if you didn't have hyperbole there. Many of us do not, in fact, have to live with the editor freezing on a regular basis.
- Karrot_Kream 11mo ago
  Look nobody is forcing you to stay on emacs. But most of us aren't experiencing editor freezing even on big projects. I'm working in a monolith of multiple languages and can get LSP for all the ones we use just fine. To use your own argument, every other person has a better experience than you. Shifting the blame to the editor is silly ;)
chuckadams 11mo ago
> Defaults emacs ships with today are really good. They're really not. It still defaults to opening a split window, still litters #foo# and foo~ files in the directory of whatever you're editing, and still comes with few language modes supported out of the box, let alone set up to automatically spawn and use LSP servers. Running a macro over a 10,000 line file is still incredibly slow on a 1-year old mac. Many common functions are still bound to chains of two or sometimes three keystrokes with multiple combinations of ctrl-keys and sometimes the mysterious ctrl-u prefix. Rebinding all the defaults is pretty much a given for any emacs power user. It's no wonder RMS ended up with RSI problems, because "emacs pinkie" is still very much a thing. I miss emacs in a lot of ways, I used it for a good two dozen years starting in the 90's, but there's a reason I use IDEA Ultimate to write code now.
- lycopodiopsida 11mo ago
  > but there's a reason I use IDEA Ultimate to write code now. IDEA is so painfully slow that while I have it paid by my company I cannot force myself to work in it for extended periods of time. And I say it being fully aware of Emacs's speed problems. Also, the limitation on "1 Window - 1 Project" is laughable in IDEA, as well as in VSCode.
  - chuckadams 11mo ago
    IDEA can certainly get slow, but `esc 10000 c-x e` still means I'm hitting abort before it gets even close to done. I use multiple panes/windows in IDEA all the time, and it also supports opening tabs in new windows/frames.
    - lycopodiopsida 11mo ago
      I have just opened a 7k loc JS file in idea and I can observe for at least 2 seconds how syntax fontification and all the hints are applied and rendered. All of it on a macbook M4. It is not acceptable and also the slowest of any editor I've used.
      - 11mo ago
BeetleB 11mo ago
> If you find your emacs to feel jank I highly recommend declaring "emacs bankruptcy" and starting anew with a fresh config. My custom config is the reason to use Emacs. If I declare bankruptcy, I might as well switch editors. eglot has performance issues. I'm not the only one who's noticed them. There's a whole page out there on config settings you can try to improve eglot's performance.

IceDane 11mo ago

I've been using emacs for 15 years as my daily editor. One thing that never fails is that when I share the fact that I've switched away, emacs users fall over themselves to tell me I'm wrong. I assure you that my emacs setup is as optimized as it can be. Native compilation, all that jazz. I've compiled my own. But emacs is ultimately a lost cause unless something drastic changes. The single threaded nature of it means that you need to just live with your editor regularly freezing for a whole second while working in bigger projects using modern tooling. The only way to remedy this is to turn off as many features as possible and accept a worse tooling experience. Shifting the blame for emacs poor internal architecture over on the poor LSPs is silly. Every other editor handles this better than emacs. For now, I'm using zed and it was really an eye-opener to how fast an editor can be and feel. I replicated a large part of my workflow, basically all the keybindings, and while there are things I miss (projectile and some other things), I can live without them in exchange for not having my editor choke constantly when working on big projects while emacs chugs through json from lsp or something like that.

skydhash 11mo ago
You may have a very justified reason to switch, including nnot liking one aspect of emacs. But you are presenting it as a general flaw. Which people cannot obviously accept as it’s fine for them and they are not experiencing your issue (and as you know, everyone’s setup and workflow are different) As for the single threaded nature of it, it doesn’t bother me. Because what should be async already is. The only thing left that is synchronous follows closely the repl model of the terminal. I issue a command and I wait for the result. If the result doesn’t matter or I want part of it as soon as possible, then it can be async and there’s plenty of way you can make it so.
- actionfromafar 11mo ago
  How do you make LSPs fast?
  - skydhash 11mo ago
    What do you mean? The language servers are independent projects from emacs. Some are slow and some are fast. And your project size is a factor.
  - G3rn0ti 11mo ago
    > How do you make LSPs fast? https://github.com/blahgeek/emacs-lsp-booster https://github.com/blahgeek/emacs-lsp-booster The fundamental issue is Emacs its JSON parser is currently still rather slow (not sure why actually). But in LSP mode it needs to parse the LSP server's many JSON response messages very quickly. The aforementioned booster converts all JSON into ELISP byte code so Emacs can process LSP messages much faster. I guess, the Emacs project will have to tune their JSON parser in the future.
- IceDane 11mo ago
  > it doesn't bother me Right, so what you're really saying is that you are totally fine with your editor being unresponsive and janky during regular editing workflow, working with modern tooling, and that everyone else is just wrong for not feeling the same way. You do you. I lived with the same copium excuse for years, obviously, but I've moved past that now and into the year 20xx. I love emacs and truly wish that I felt like I could seriously use it, and in many ways, I feel like it's the ultimate expression of what an editor could be. But it's just suffering from being 40 year old software that hasn't seen significant modernization to meet the demands of today's development workflows.
  - skydhash 11mo ago
    Your assumption is that Emacs is unresponsive and janky during my editing experience and it’s not that. Everyone’s setup is different. Your configuration may be janky and unresponsive, but it’s not a generality.
taeric 11mo ago
You get the same behavior from any editor, though? Hell, you'd probably get similar behavior if you switched brands of power tools. People are attached to their tools. That said, it would help if you didn't have hyperbole there. Many of us do not, in fact, have to live with the editor freezing on a regular basis.
Karrot_Kream 11mo ago
Look nobody is forcing you to stay on emacs. But most of us aren't experiencing editor freezing even on big projects. I'm working in a monolith of multiple languages and can get LSP for all the ones we use just fine. To use your own argument, every other person has a better experience than you. Shifting the blame to the editor is silly ;)

chuckadams 11mo ago

> Defaults emacs ships with today are really good. They're really not. It still defaults to opening a split window, still litters #foo# and foo~ files in the directory of whatever you're editing, and still comes with few language modes supported out of the box, let alone set up to automatically spawn and use LSP servers. Running a macro over a 10,000 line file is still incredibly slow on a 1-year old mac. Many common functions are still bound to chains of two or sometimes three keystrokes with multiple combinations of ctrl-keys and sometimes the mysterious ctrl-u prefix. Rebinding all the defaults is pretty much a given for any emacs power user. It's no wonder RMS ended up with RSI problems, because "emacs pinkie" is still very much a thing. I miss emacs in a lot of ways, I used it for a good two dozen years starting in the 90's, but there's a reason I use IDEA Ultimate to write code now.

lycopodiopsida 11mo ago
> but there's a reason I use IDEA Ultimate to write code now. IDEA is so painfully slow that while I have it paid by my company I cannot force myself to work in it for extended periods of time. And I say it being fully aware of Emacs's speed problems. Also, the limitation on "1 Window - 1 Project" is laughable in IDEA, as well as in VSCode.
- chuckadams 11mo ago
  IDEA can certainly get slow, but `esc 10000 c-x e` still means I'm hitting abort before it gets even close to done. I use multiple panes/windows in IDEA all the time, and it also supports opening tabs in new windows/frames.
  - lycopodiopsida 11mo ago
    I have just opened a 7k loc JS file in idea and I can observe for at least 2 seconds how syntax fontification and all the hints are applied and rendered. All of it on a macbook M4. It is not acceptable and also the slowest of any editor I've used.
    - 11mo ago

BeetleB 11mo ago

> If you find your emacs to feel jank I highly recommend declaring "emacs bankruptcy" and starting anew with a fresh config. My custom config is the reason to use Emacs. If I declare bankruptcy, I might as well switch editors. eglot has performance issues. I'm not the only one who's noticed them. There's a whole page out there on config settings you can try to improve eglot's performance.