5 ms·

As a devoted emacs addict, I can attest that plan old emacs is also pretty slow and clunky, though I could easily believe spacemacs is even worse! My dream edi

by dilap 7y ago

As a devoted emacs addict, I can attest that plan old emacs is also pretty slow and clunky, though I could easily believe spacemacs is even worse! My dream editor would combine the flexibility of emacs w/ the speed and quality of sublime.

Barrin92 7y ago
>As a devoted emacs addict, I can attest that plan old emacs is also pretty slow and clunky it's true in the sense that it's true for almost anything once you start to add a plugin or two or add personal customizations. The only thing for me that is actually consistently, superfast is terminal vim without any plugins. Which is too barebones for my daily use. In a realistic, daily working environment with all my stuff loaded emacs is clunky, but not necessarily slow. It's honestly still pretty responsive.
- dilap 7y ago
  Even just basic text rendering in emacs is slow! Three examples: I use the windowed Mac version most of the time, and touchpad scrolling is so slow that it's basically not a reasonable way to get around a file. Compare to Sublime, where it's silky smooth, and you can get an almost physical feeling of where things are, which makes zipping around using scrolling very effective. I run my shell inside emacs (which is super nice -- how do people survive not having easy immediate access to command output)? But if a command is going to generate a lot of output (e.g., if I have the misfortune to be running mvn), I'll need to either drop back to terminal or redirect the output to a file, or be content with my command slowing down 100x to wait for emacs to render the output. Try opening a file that happens to contain a very long line (this happens sometimes w/ generated code, or json data, or ...). Emacs will basically freeze, due to some N^2 in line length algorithm somewhere. It's no easy task, but I do think it's possible to make something w/ the near-infinite, excellent flexibility of emacs, while also hitting a much higher speed and quality bar.
  - omaranto 7y ago
    Scrolling sounds like a terrible way to get around a file. I'd much rather be presented with a prompt to go to a named "section" with completion (an actual section in a prose document, or a function definition in a program), or to search for some text. Or, if I don't have a specific target in mind and I want an overview of the file, I prefer pagination to scrolling. But... I wonder how much my preference is conditioned by years of Emacs and its subpar scrolling? My preference for pagination+search extends to other software; to browsers, for example (spacebar or ctrl+f over mouse-wheel), but is that just a habit I got from my constant Emacs usage (I typed this comment in Emacs)?
    - dilap 7y ago
      Exactly, it's hard to miss what you haven't had! In emacs, I mostly navigate around by searching, or sometimes by outlining (hide all lines that aren't a definition, move to definition, unhide). But I do remember before I became an emacs addict, and there was something very nice about having a physical sense of your file layout. If you have that sense, scrolling can an efficient way to navigate a file (well, up to a certain size, anyway). And I think there's something valuable in the almost subconscious feeling for the layout of the file you get as you scroll thru it. When I'm mostly in emacs, my sense of what a file "is" is much hazier, because I'm just warping from one place to another. (On the other hand, maybe the entire concept of a file as a linear progression is antiquated for source code...)
iLemming 7y ago
Quality? I think Emacs (for what it does) is a product of superb quality. I just checked - I pull over 400 packages (including built-ins). Can you imagine Sublime, VSCode, or Atom with 400 plugins installed? I don't even know if you can find that many useful plugins for them, but even if you do, I think at best it would just hang them indefinitely. And these are not 400 "dead-weight," useless packages. These are real programs that very often tightly integrate with each other. Some of them like Magit and Org-mode are quite serious products by themselves. Sure, there are decades-old issues in Emacs, and they are slowly, steadily being worked on. The problem with long lines is getting fixed. JSON performance got improved with jansson. Elisp native - some people reported a 300% speed boost. Rendering improvements with Cairo - no longer experimental; Native line numbers are in the stable version of Emacs; People today discussing using Tree-sitter for parsing, which would significantly improve syntax-highlighting. And many other things are slowly being improved. Things move slowly in the Emacs world. We have many smart people, but we don't have enough of them to contribute and move things fast.
- dilap 7y ago
  No argument that emacs is getting better. But I'm not sure it will ever be what I would consider high-quality! I think it's just the nature of a huge system implemented (mostly) in a dynamically typed, dynamically scoped (!) (though, happily, more and more less and less) language to be partly broken all of the time. And, to be fair, most of the bugginess is not emacs per-se, but in the various packages and their interactions -- but what is emacs, really, other than a platform to run the packages? So here's some random problems I have (I have a long list, and occasionally I try to fix one; the list is growing): - After I run a python shell for a while, bash shells stop asynchronously showing command output; the shell just hangs until the command completes. - There's an awesome mode iedit that lets you edit all instances of a symbol. Sometimes, for certain sequences of characters, instead of correctly performing the edit, it inserts gibberish. - There's an awesome mode grep-ed that let's you edit grep(†) results inline; very convenient. Except for when it very rarely, randomly decides to garbles the files. († Or even better ripgrep -- random shout out to truly fantastic piece of software!) - The afore-mentioned iedit mode doesn't work w/ the delete-horizontal-space editing command. (All other commands, yes, just not that one, for some reason.) - There is a mode dumb-jump that jumps to symbols. There is an emacs feature to soft-wrap lines. Dump-jump doesn't work when jumping to a symbol that's on a wrapped line. - To work around a rare but tricky race condition, emacs shell mode at some point added a built-in 1-second startup delay. I lived w/ annoyingly slow shell starts for months before I finally tracked it down, only to find out it was on-purpose terrible kludge! - The soft-line wrapping mode (visual-line-mode) goes crazy if the line gets really long. &c &c &c. So while I spend most my time in emacs and have great affection for it, I definitely don't feel like it's a high-quality experience. I'm constantly running into little bugs. To be fair, most of my arguments are with 3rd-party packages and their interactions, not emacs per-se. But emacs w/o 3rd party packages would be like a non-fat decaf latte: what's the point? (P.S. Very excited about the possibility of fixed long lines & tree-sitting parsers!)

by dilap 7y ago

Barrin92 7y ago

>As a devoted emacs addict, I can attest that plan old emacs is also pretty slow and clunky it's true in the sense that it's true for almost anything once you start to add a plugin or two or add personal customizations. The only thing for me that is actually consistently, superfast is terminal vim without any plugins. Which is too barebones for my daily use. In a realistic, daily working environment with all my stuff loaded emacs is clunky, but not necessarily slow. It's honestly still pretty responsive.

dilap 7y ago
Even just basic text rendering in emacs is slow! Three examples: I use the windowed Mac version most of the time, and touchpad scrolling is so slow that it's basically not a reasonable way to get around a file. Compare to Sublime, where it's silky smooth, and you can get an almost physical feeling of where things are, which makes zipping around using scrolling very effective. I run my shell inside emacs (which is super nice -- how do people survive not having easy immediate access to command output)? But if a command is going to generate a lot of output (e.g., if I have the misfortune to be running mvn), I'll need to either drop back to terminal or redirect the output to a file, or be content with my command slowing down 100x to wait for emacs to render the output. Try opening a file that happens to contain a very long line (this happens sometimes w/ generated code, or json data, or ...). Emacs will basically freeze, due to some N^2 in line length algorithm somewhere. It's no easy task, but I do think it's possible to make something w/ the near-infinite, excellent flexibility of emacs, while also hitting a much higher speed and quality bar.
- omaranto 7y ago
  Scrolling sounds like a terrible way to get around a file. I'd much rather be presented with a prompt to go to a named "section" with completion (an actual section in a prose document, or a function definition in a program), or to search for some text. Or, if I don't have a specific target in mind and I want an overview of the file, I prefer pagination to scrolling. But... I wonder how much my preference is conditioned by years of Emacs and its subpar scrolling? My preference for pagination+search extends to other software; to browsers, for example (spacebar or ctrl+f over mouse-wheel), but is that just a habit I got from my constant Emacs usage (I typed this comment in Emacs)?
  - dilap 7y ago
    Exactly, it's hard to miss what you haven't had! In emacs, I mostly navigate around by searching, or sometimes by outlining (hide all lines that aren't a definition, move to definition, unhide). But I do remember before I became an emacs addict, and there was something very nice about having a physical sense of your file layout. If you have that sense, scrolling can an efficient way to navigate a file (well, up to a certain size, anyway). And I think there's something valuable in the almost subconscious feeling for the layout of the file you get as you scroll thru it. When I'm mostly in emacs, my sense of what a file "is" is much hazier, because I'm just warping from one place to another. (On the other hand, maybe the entire concept of a file as a linear progression is antiquated for source code...)

iLemming 7y ago

Quality? I think Emacs (for what it does) is a product of superb quality. I just checked - I pull over 400 packages (including built-ins). Can you imagine Sublime, VSCode, or Atom with 400 plugins installed? I don't even know if you can find that many useful plugins for them, but even if you do, I think at best it would just hang them indefinitely. And these are not 400 "dead-weight," useless packages. These are real programs that very often tightly integrate with each other. Some of them like Magit and Org-mode are quite serious products by themselves. Sure, there are decades-old issues in Emacs, and they are slowly, steadily being worked on. The problem with long lines is getting fixed. JSON performance got improved with jansson. Elisp native - some people reported a 300% speed boost. Rendering improvements with Cairo - no longer experimental; Native line numbers are in the stable version of Emacs; People today discussing using Tree-sitter for parsing, which would significantly improve syntax-highlighting. And many other things are slowly being improved. Things move slowly in the Emacs world. We have many smart people, but we don't have enough of them to contribute and move things fast.

dilap 7y ago
No argument that emacs is getting better. But I'm not sure it will ever be what I would consider high-quality! I think it's just the nature of a huge system implemented (mostly) in a dynamically typed, dynamically scoped (!) (though, happily, more and more less and less) language to be partly broken all of the time. And, to be fair, most of the bugginess is not emacs per-se, but in the various packages and their interactions -- but what is emacs, really, other than a platform to run the packages? So here's some random problems I have (I have a long list, and occasionally I try to fix one; the list is growing): - After I run a python shell for a while, bash shells stop asynchronously showing command output; the shell just hangs until the command completes. - There's an awesome mode iedit that lets you edit all instances of a symbol. Sometimes, for certain sequences of characters, instead of correctly performing the edit, it inserts gibberish. - There's an awesome mode grep-ed that let's you edit grep(†) results inline; very convenient. Except for when it very rarely, randomly decides to garbles the files. († Or even better ripgrep -- random shout out to truly fantastic piece of software!) - The afore-mentioned iedit mode doesn't work w/ the delete-horizontal-space editing command. (All other commands, yes, just not that one, for some reason.) - There is a mode dumb-jump that jumps to symbols. There is an emacs feature to soft-wrap lines. Dump-jump doesn't work when jumping to a symbol that's on a wrapped line. - To work around a rare but tricky race condition, emacs shell mode at some point added a built-in 1-second startup delay. I lived w/ annoyingly slow shell starts for months before I finally tracked it down, only to find out it was on-purpose terrible kludge! - The soft-line wrapping mode (visual-line-mode) goes crazy if the line gets really long. &c &c &c. So while I spend most my time in emacs and have great affection for it, I definitely don't feel like it's a high-quality experience. I'm constantly running into little bugs. To be fair, most of my arguments are with 3rd-party packages and their interactions, not emacs per-se. But emacs w/o 3rd party packages would be like a non-fat decaf latte: what's the point? (P.S. Very excited about the possibility of fixed long lines & tree-sitting parsers!)