9 ms·

As an emacs addict/user, what I really want is a credible alternative to that cockroach of editors. Price of admission: run in a terminal, run graphically, run

by dilap 10y ago

As an emacs addict/user, what I really want is a credible alternative to that cockroach of editors. Price of admission: run in a terminal, run graphically, run on every possible system, be open source, be ridiculously, easily extensible. What a successor might add: Not be riddled with bugs. Not be ridiculously, terribly bad at actually displaying text (quickly, smoothly, large amounts). Not be extended in a language that's so slow that most "intelligent" modes end up being piles of half-correct regex hacks. Not not care about correctness, in general. Hop to it, dear idealistic genius whiz-kid reader! Or fund me, overly-$-laden startup lottery winner. I'll take a crack at it.

bauta-steen 10y ago
Isn't the emacs core (excluding packages) known to be very stable? At least I've only had one crash in a year or so, most likely due to some package misbehaving.
- LukeShu 10y ago
  Emacs has long been riddled with bugs that can cause daemonized emacs to crash if the display disconnects (yes, even with the Lucid toolkit). term-mode is hacks on hacks on hacks; and slow ones at that. There's a bug in Emacs 24's sh-mode that can cause it to deadlock if you move the point to a wrong place in an incomplete if/while/for block start (IDK if it's fixed in Emacs 25). All point-releases of Emacs 24 shipped with a TRAMP mode with broken /sudo:: that can cause /dev/null to become an ordinary file, causing the entire OS to slowly and mysteriously break (Fun on servers! Fixed in Emacs 25). I have a collection of emacs core dumps on one of my servers (where I use it like screen/tmux) that I have yet to try to diagnose. I mean, I love Emacs and use it daily. But it certainly has plenty of bugs; but what reasonably complicated piece of software doesn't?
  - peatfreak 10y ago
    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.
MildlySerious 10y ago
A possible (very early) start for this could be https://github.com/google/xi-editor https://github.com/google/xi-editor UIs and actual functionality are completely separate implementations. Loading and displaying text are entirely decoupled, so the display doesn't have to care if the actual file is 10kb or 2gb in size.
- dilap 10y ago
  super-early-days, but this looks philosophically very much in the right place.
  - MildlySerious 10y ago
    There's a talk about it, too, if interested: https://www.youtube.com/watch?v=SKtQgFBRUvQ https://www.youtube.com/watch?v=SKtQgFBRUvQ I'm hoping to find the time to get more comfortable with Rust and try to contribute at some point
- flukus 10y ago
  Yet another with a client server architecture. It makes no sense in a desktop application to add the performance overhead of IPC and serialization to every user interaction.
  - duaneb 10y ago
    What is the performance overhead like? I can't access the app right now but I'd be highly surprised if it caused a noticeable input latency. Or are you talking out of your ass?
    - flukus 10y ago
      It's a whole lot of unnecessary serialization and deserializtion, even if the performance is not noticeable it's a waste of cpu cycles. From looking at similar projects, overhead tends to be in the millisecond range per call, so performance depends on the ammount of back and forths. Add in all the overhead for serialization and IPC and in practice it looks a lot like the round trip in same data center latency here: https://people.eecs.berkeley.edu/~rcs/research/interactive_latency.html https://people.eecs.berkeley.edu/~rcs/research/interactive_l...
jdefr89 10y ago
As a Vim addict/user. All I really want is a bit more modernization. I mean single threaded text editor in 2016.. NeoVim is supposed to be the savior.. But I don't feel like it gets a lot of support...
- idobai 10y ago
  Neovim is multithreaded for years, for example you can use deoplete for autocompletion.
- jhoechtl 10y ago
  In Vim8 vim gained asynchronous I/O support https://github.com/vim/vim/blob/master/runtime/doc/version8.txt#L41 https://github.com/vim/vim/blob/master/runtime/doc/version8....
- minitech 10y ago
  Why does your text editor need multiple threads?
  - legulere 10y ago
    Because some tasks like autocompletion take a relatively long time. This leads to your editor blocking.
    - deleted 10y ago
      [deleted]
  - coldtea 10y ago
    To avoid blocking?
timehastoldme 10y ago
Atom (hear me out): + runs graphically + runs linux, macos, windows (nothing else?) + open source + ridiculously, easily extensible + not riddled with bugs (slowness is not a bug) + for small files, comparably quick to Sublime on my machine + major dev community; already much better than 6 months ago - slow in some instances, esp. large files - doesn't run in terminal - doesn't run in less-popular OSes +/- moderate RAM usage, decreasing
- omginternets 10y ago
  Honestly I don't get the Atom hate. It's a great editor. I came to Atom from Sublime because the plugin ecosystem was growing much faster and the community felt more active. I haven't looked back since. And no, Atom not designed to open 30Mb files. Complaining about this is akin to stomping on a land mine and complaining that your Timberland boots didn't save your foot. Just use Atom for its intended purpose: editing source files written by reasonably reasonable people.
  - cdelsolar 10y ago
    log files?
    - omginternets 10y ago
      Use something else for viewing log files! Going through log files and developing software are related, but distinct enterprises. It's no wonder the tools for one are sometimes suboptimal for the other. Atom is about nice aesthetics, github integration and a plugin ecosystem. It's not trying to solve the problem of reading through massive log files.
      - konart 10y ago
        >Atom is about nice aesthetics, github integration and a plugin ecosystem Same goes for Sublime. And arguably - Sublime has much better plugin ecosystem. With easier discovery and installation.
flukus 10y ago
Which of those does vim not hit?
- zem 10y ago
  the extension language, I'm guessing.
  - flukus 10y ago
    The second half of that line seemed to be alluding to something else. I'm not saying it's fast, but I've never encountered it's speed being a problem in practice.
    - yulaow 10y ago
      I just noticed that if I use too many plugins (where too many in my vimrc is > 12) the startup time can be a bit slow (3-4 seconds). Compare it with emacs in which I have far more plugins and it still starts fast as a clean install. Anyway not a big problem eh. For me vimscript is the shitty part of vim.
      - wkd 10y ago
        I just want to say that it's likely not the amount of plugins it's the weight each have, likely you have a few heavy ones causing your boot to be slow. I use ~20 plugins and startup time is still under a second when opening a 35000 line file, try using --startuptime
      - flukus 10y ago
        That sounds like an issue with specific plugins not loading on demand. Though it's not always avoidable, like when you open vim with specific files which triggers the lazy loading.
    - viraptor 10y ago
      The effect can be seen in the highlighter sometimes. If there are too many rules to parse the file correctly, sometimes it will parse just a few lines before the screen. This can randomly result in the first line being highlighted like it's a part of some string. And the whole highlighter/parser is a really bizarre world of regexes and almost-tokens.
deleted 10y ago
[deleted]
Shorel 10y ago
Check the IDE screenshot running on the console: https://dlang.org/blog/2016/10/07/project-highlight-dlangui/ https://dlang.org/blog/2016/10/07/project-highlight-dlangui/ It is written in D, a fast (close to C++) language, easy to write code in, runs in a terminal, runs graphically, runs on many systems (I don't know every possible system but I doubt in runs in a Commodore 64), it is open source and I have no idea about it being extensible or not. It's however the closest thing I have seen to your list of requirements.
qwertyuiop924 10y ago
Emacs is still the best for most of that. Text display works most of the time (although it sucks), there are intelligent modes that aren't a pile of half-correct regex hacks (semantic, most of the modes for the Lisp family), and the base is fairly stable (some of the packages may not be). OTOH, it could be better. If you don't mind the lack of extensions, and are willing to write your own, you may wish to try some of the other emacsen associated with the lisps. Hemlock is CL-based, so likely faster than Emacs, and Edwin and Guile-Emacs are both based on Schemes (edwin is MIT Scheme, Guile Emacs is... Guile). They still suck at some stuff, though, and they don't have the massive plugin ecosystem.

by dilap 10y ago

bauta-steen 10y ago

Isn't the emacs core (excluding packages) known to be very stable? At least I've only had one crash in a year or so, most likely due to some package misbehaving.

LukeShu 10y ago
Emacs has long been riddled with bugs that can cause daemonized emacs to crash if the display disconnects (yes, even with the Lucid toolkit). term-mode is hacks on hacks on hacks; and slow ones at that. There's a bug in Emacs 24's sh-mode that can cause it to deadlock if you move the point to a wrong place in an incomplete if/while/for block start (IDK if it's fixed in Emacs 25). All point-releases of Emacs 24 shipped with a TRAMP mode with broken /sudo:: that can cause /dev/null to become an ordinary file, causing the entire OS to slowly and mysteriously break (Fun on servers! Fixed in Emacs 25). I have a collection of emacs core dumps on one of my servers (where I use it like screen/tmux) that I have yet to try to diagnose. I mean, I love Emacs and use it daily. But it certainly has plenty of bugs; but what reasonably complicated piece of software doesn't?
- peatfreak 10y ago
  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.

MildlySerious 10y ago

A possible (very early) start for this could be https://github.com/google/xi-editor https://github.com/google/xi-editor UIs and actual functionality are completely separate implementations. Loading and displaying text are entirely decoupled, so the display doesn't have to care if the actual file is 10kb or 2gb in size.

dilap 10y ago
super-early-days, but this looks philosophically very much in the right place.
- MildlySerious 10y ago
  There's a talk about it, too, if interested: https://www.youtube.com/watch?v=SKtQgFBRUvQ https://www.youtube.com/watch?v=SKtQgFBRUvQ I'm hoping to find the time to get more comfortable with Rust and try to contribute at some point
flukus 10y ago
Yet another with a client server architecture. It makes no sense in a desktop application to add the performance overhead of IPC and serialization to every user interaction.
- duaneb 10y ago
  What is the performance overhead like? I can't access the app right now but I'd be highly surprised if it caused a noticeable input latency. Or are you talking out of your ass?
  - flukus 10y ago
    It's a whole lot of unnecessary serialization and deserializtion, even if the performance is not noticeable it's a waste of cpu cycles. From looking at similar projects, overhead tends to be in the millisecond range per call, so performance depends on the ammount of back and forths. Add in all the overhead for serialization and IPC and in practice it looks a lot like the round trip in same data center latency here: https://people.eecs.berkeley.edu/~rcs/research/interactive_latency.html https://people.eecs.berkeley.edu/~rcs/research/interactive_l...

jdefr89 10y ago

As a Vim addict/user. All I really want is a bit more modernization. I mean single threaded text editor in 2016.. NeoVim is supposed to be the savior.. But I don't feel like it gets a lot of support...

idobai 10y ago
Neovim is multithreaded for years, for example you can use deoplete for autocompletion.
jhoechtl 10y ago
In Vim8 vim gained asynchronous I/O support https://github.com/vim/vim/blob/master/runtime/doc/version8.txt#L41 https://github.com/vim/vim/blob/master/runtime/doc/version8....
minitech 10y ago
Why does your text editor need multiple threads?
- legulere 10y ago
  Because some tasks like autocompletion take a relatively long time. This leads to your editor blocking.
  - deleted 10y ago
    [deleted]
- coldtea 10y ago
  To avoid blocking?

timehastoldme 10y ago

Atom (hear me out): + runs graphically + runs linux, macos, windows (nothing else?) + open source + ridiculously, easily extensible + not riddled with bugs (slowness is not a bug) + for small files, comparably quick to Sublime on my machine + major dev community; already much better than 6 months ago - slow in some instances, esp. large files - doesn't run in terminal - doesn't run in less-popular OSes +/- moderate RAM usage, decreasing

omginternets 10y ago
Honestly I don't get the Atom hate. It's a great editor. I came to Atom from Sublime because the plugin ecosystem was growing much faster and the community felt more active. I haven't looked back since. And no, Atom not designed to open 30Mb files. Complaining about this is akin to stomping on a land mine and complaining that your Timberland boots didn't save your foot. Just use Atom for its intended purpose: editing source files written by reasonably reasonable people.
- cdelsolar 10y ago
  log files?
  - omginternets 10y ago
    Use something else for viewing log files! Going through log files and developing software are related, but distinct enterprises. It's no wonder the tools for one are sometimes suboptimal for the other. Atom is about nice aesthetics, github integration and a plugin ecosystem. It's not trying to solve the problem of reading through massive log files.
    - konart 10y ago
      >Atom is about nice aesthetics, github integration and a plugin ecosystem Same goes for Sublime. And arguably - Sublime has much better plugin ecosystem. With easier discovery and installation.

flukus 10y ago

Which of those does vim not hit?

zem 10y ago
the extension language, I'm guessing.
- flukus 10y ago
  The second half of that line seemed to be alluding to something else. I'm not saying it's fast, but I've never encountered it's speed being a problem in practice.
  - yulaow 10y ago
    I just noticed that if I use too many plugins (where too many in my vimrc is > 12) the startup time can be a bit slow (3-4 seconds). Compare it with emacs in which I have far more plugins and it still starts fast as a clean install. Anyway not a big problem eh. For me vimscript is the shitty part of vim.
    - wkd 10y ago
      I just want to say that it's likely not the amount of plugins it's the weight each have, likely you have a few heavy ones causing your boot to be slow. I use ~20 plugins and startup time is still under a second when opening a 35000 line file, try using --startuptime
    - flukus 10y ago
      That sounds like an issue with specific plugins not loading on demand. Though it's not always avoidable, like when you open vim with specific files which triggers the lazy loading.
  - viraptor 10y ago
    The effect can be seen in the highlighter sometimes. If there are too many rules to parse the file correctly, sometimes it will parse just a few lines before the screen. This can randomly result in the first line being highlighted like it's a part of some string. And the whole highlighter/parser is a really bizarre world of regexes and almost-tokens.

deleted 10y ago

[deleted]

Shorel 10y ago

Check the IDE screenshot running on the console: https://dlang.org/blog/2016/10/07/project-highlight-dlangui/ https://dlang.org/blog/2016/10/07/project-highlight-dlangui/ It is written in D, a fast (close to C++) language, easy to write code in, runs in a terminal, runs graphically, runs on many systems (I don't know every possible system but I doubt in runs in a Commodore 64), it is open source and I have no idea about it being extensible or not. It's however the closest thing I have seen to your list of requirements.

qwertyuiop924 10y ago

Emacs is still the best for most of that. Text display works most of the time (although it sucks), there are intelligent modes that aren't a pile of half-correct regex hacks (semantic, most of the modes for the Lisp family), and the base is fairly stable (some of the packages may not be). OTOH, it could be better. If you don't mind the lack of extensions, and are willing to write your own, you may wish to try some of the other emacsen associated with the lisps. Hemlock is CL-based, so likely faster than Emacs, and Edwin and Guile-Emacs are both based on Schemes (edwin is MIT Scheme, Guile Emacs is... Guile). They still suck at some stuff, though, and they don't have the massive plugin ecosystem.