6 ms·

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 Subli

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!)
- useragent86 7y ago
  > 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. To be clear, Elisp has had lexical-binding for about 8 years now. > After I run a python shell for a while, bash shells stop asynchronously showing command output; the shell just hangs until the command completes. That's very strange, indeed. See if you can reproduce with emacs -q. > 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. iedit is great. I've never seen it insert gibberish or misbehave in any way. > 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. Haven't heard of grep-ed. Maybe you're thinking of wgrep? See also occur, which can also perform edits. In fact, there are probably at least 5-10 packages which implement such functionality, some of which are built-in. > 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.) It would be helpful to report that issue so it could be fixed. > 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. That's unlikely. If that ever were the case, it's probably fixed by now, because dumb-jump is under active development, very popular, and widely recommended, and that would be a very basic problem. Besides, I can't imagine how being on a wrapped line would affect it, because Emacs commands that read from the buffer aren't affected by visual-line-mode. > 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! Try ansi-term instead of shell. > The soft-line wrapping mode (visual-line-mode) goes crazy if the line gets really long. Extremely long lines have been a problem in Emacs for a long time, however Emacs 27 includes so-long-mode, which mitigates it.
  - dilap 7y ago
    Thanks, I do appreciate the tips. Like I mentioned, these are just a couple problems from a longer list. Occasionally, I pick one and (try) to solve it. If I tried to solve them all, I wouldn't have much time left for anything else. :-) My more general point is Emacs is pretty janky. I also don't think it's inevitable -- it's possible to make something that offers the awesome flexibility of emacs, but w/o the quality issues. Who knows, maybe Emacs itself will eventually evolve in this direction. (Re a couple of your specific points: - I just checked, and 36% of the files in my site-lisp directory are using lexical scoping. - Dynamic scoping can be handy! Here's (incredibly nasty) my fix for the hard-coded 1-second delay in shell mode: (flet ((sleep-for (&rest args) ())) ;; redefine sleep-for since shell calls it on purpose, guaranteeing a 1s startup time... The fact that such a fix is needed, on the one hand, and that such a fix is possible, on the other, are emblematic of the both cultural and technical reasons that emacs is not more robust.)

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!)

useragent86 7y ago
> 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. To be clear, Elisp has had lexical-binding for about 8 years now. > After I run a python shell for a while, bash shells stop asynchronously showing command output; the shell just hangs until the command completes. That's very strange, indeed. See if you can reproduce with emacs -q. > 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. iedit is great. I've never seen it insert gibberish or misbehave in any way. > 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. Haven't heard of grep-ed. Maybe you're thinking of wgrep? See also occur, which can also perform edits. In fact, there are probably at least 5-10 packages which implement such functionality, some of which are built-in. > 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.) It would be helpful to report that issue so it could be fixed. > 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. That's unlikely. If that ever were the case, it's probably fixed by now, because dumb-jump is under active development, very popular, and widely recommended, and that would be a very basic problem. Besides, I can't imagine how being on a wrapped line would affect it, because Emacs commands that read from the buffer aren't affected by visual-line-mode. > 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! Try ansi-term instead of shell. > The soft-line wrapping mode (visual-line-mode) goes crazy if the line gets really long. Extremely long lines have been a problem in Emacs for a long time, however Emacs 27 includes so-long-mode, which mitigates it.
- dilap 7y ago
  Thanks, I do appreciate the tips. Like I mentioned, these are just a couple problems from a longer list. Occasionally, I pick one and (try) to solve it. If I tried to solve them all, I wouldn't have much time left for anything else. :-) My more general point is Emacs is pretty janky. I also don't think it's inevitable -- it's possible to make something that offers the awesome flexibility of emacs, but w/o the quality issues. Who knows, maybe Emacs itself will eventually evolve in this direction. (Re a couple of your specific points: - I just checked, and 36% of the files in my site-lisp directory are using lexical scoping. - Dynamic scoping can be handy! Here's (incredibly nasty) my fix for the hard-coded 1-second delay in shell mode: (flet ((sleep-for (&rest args) ())) ;; redefine sleep-for since shell calls it on purpose, guaranteeing a 1s startup time... The fact that such a fix is needed, on the one hand, and that such a fix is possible, on the other, are emblematic of the both cultural and technical reasons that emacs is not more robust.)