4 ms·

Emacs 19 was a model of low-defect, stable software, and my experiences reinforced that widespread notion. Over time and subsequent major releases, it grew and

Emacs 19 was a model of low-defect, stable software, and my experiences reinforced that widespread notion. Over time and subsequent major releases, it grew and grew, and the complexity got too big to perform adequate QA, now nearing the point of unmaintainability. I also love it and use it daily, but I really wish the developers would show some restraint when considering whether to add new features (i.e., packages). Having said that, the very core text editing engine, i.e., the part that's written in C and the basic Elisp editing functions around that are still rock solid as always, and for me this is still the ultimate model of what a text processing engine should be. It handles large files beautifully (and errors gracefully when it cannot), does file locking well, goes to great lengths to ensure the integrity of your file, all of that basic core stuff is just superb and well thought out, by a lot of brilliant people over a long time, and that's all very well optimized. I think the problem is that too many third-party extensions are included with the core release.

oblio 10y ago
I'd argue that in 2016 a well designed system has a way to make sure that its extensions can't slow it down, can't bring it down and can't step on each other's toes. On the other hand, I can't really think about a system that fulfills those conditions. But I wouldn't call anything "ultimate" if it doesn't :)
hollerith 10y ago
Well, I'm sure you'd concede that read-file-name is part of Emacs's core, and its been buggy for years. (Have not checked to see yet if it is still buggy in version 25.) Specifically, if the current buffer is visiting an image file, pressing down arrow during a read-file-name will often cause read-file-name to try to insert the whole image as a text string into the minibuffer after the prompt, which will make Emacs unresponsive for a few seconds and will sometimes crash Emacs. Before that there were years during which there was no way to configure Emacs that I was able to find to refrain from asking the user what coding system he wants to use every time a buffer containing a non-ascii character is saved. Not strictly a bug since maybe there are users who do not mind regularly getting into the same dialog with their text editor, but certainly, so many occurrences of the same monotonous dialog is unusual behavior in a user-facing application in this decade and very tedious at least to this particular user. One reason Emacs is difficult to debug is because of the widespread use of global variables. That said, I haven't found anything worth leaving Emacs for. (If I were a web dev, maybe I would've left it for vscode by now, but I don't like how text looks in vscode: I prefer the native OS X text rendering used by almost all text editors except the Electron-based ones.)
- qwertyuiop924 10y ago
  Hopefully, Guile-Emacs will eventually get finished, so we'll have decent debugging. Hey, I can dream.
- peatfreak 10y ago
  > That said, I haven't found anything worth leaving Emacs for. Exactly. Every so often I try to make a half-hearted effort to move to a more moderen editor, or even an IDE, but for all its flaws even nothing comes close to Emacs. Vim is pretty good, but tries to do too many things it's not supposed to; for vi-style editors I prefer Nvi.

oblio 10y ago

I'd argue that in 2016 a well designed system has a way to make sure that its extensions can't slow it down, can't bring it down and can't step on each other's toes. On the other hand, I can't really think about a system that fulfills those conditions. But I wouldn't call anything "ultimate" if it doesn't :)

hollerith 10y ago

Well, I'm sure you'd concede that read-file-name is part of Emacs's core, and its been buggy for years. (Have not checked to see yet if it is still buggy in version 25.) Specifically, if the current buffer is visiting an image file, pressing down arrow during a read-file-name will often cause read-file-name to try to insert the whole image as a text string into the minibuffer after the prompt, which will make Emacs unresponsive for a few seconds and will sometimes crash Emacs. Before that there were years during which there was no way to configure Emacs that I was able to find to refrain from asking the user what coding system he wants to use every time a buffer containing a non-ascii character is saved. Not strictly a bug since maybe there are users who do not mind regularly getting into the same dialog with their text editor, but certainly, so many occurrences of the same monotonous dialog is unusual behavior in a user-facing application in this decade and very tedious at least to this particular user. One reason Emacs is difficult to debug is because of the widespread use of global variables. That said, I haven't found anything worth leaving Emacs for. (If I were a web dev, maybe I would've left it for vscode by now, but I don't like how text looks in vscode: I prefer the native OS X text rendering used by almost all text editors except the Electron-based ones.)

qwertyuiop924 10y ago
Hopefully, Guile-Emacs will eventually get finished, so we'll have decent debugging. Hey, I can dream.
peatfreak 10y ago
> That said, I haven't found anything worth leaving Emacs for. Exactly. Every so often I try to make a half-hearted effort to move to a more moderen editor, or even an IDE, but for all its flaws even nothing comes close to Emacs. Vim is pretty good, but tries to do too many things it's not supposed to; for vi-style editors I prefer Nvi.