Emacs and Vim are great tools. Amazing pieces of software. But in some areas you really see the prospect of time and aging.
I used and learned both in some point in time, liked something from both, sticked to Vim, but I kinda felt the best text editor would
be hybrid of these two. (Now don't run and tell me to install EVIL in Emacs, I tried that, but modal editing is not the only thing that gives Vim edge over Emacs)
What got my attention recently is Xi (developed by Raph Levien). It is written in Rust, looks fairly interesting, can't wait for it to be in advanced state. I really wouldn't mind some nice, modern, terminal text editor. (I use NeoVim at the moment, and I think it is closest to that, but VimL :cringe:)
Personally, as much as various editors talk about "modernity," there isn't really one that's surpassed Emacs yet. My requirements are fairly simple:
-Text interface: I don't want to be unproductive when I'm without a GUI
-Consistant abstractions and scriptability: Your editor needs to be customizable for whatever task I may need: that means scripting anything that can be done with a UI, customizing pretty much any aspect of editor behavior, the ability to embed curses-style UIs into the editor (when in nongraphical mode), and interfacing with external programs. And yes, these are all features I use. And not just for playing tetris, either.
In order to do this, you need consistant abstractions. For instance, if every window, from your obtions window, to your editing window, to your tetris window, aren't treated the same, aren't fundamentally the same object type, then you've failed as an editor designer.
-Ecosystem: this one isn't so much of a requirement, but it's nice to have a good one. That means lots plugins and other tooling.
The only editors that have these are vim, emacs, and, to a certain degree, acme.
Interesting. For me the killer feature of Emacs is its customizability. That's not quite the right word, because Emacs's integration with ELisp lets you do things that almost nothing else does. The ability to modify existing functions live is central to its power, and the boundary between "The Editor" and "Extensions" is extremely fuzzy.
Xi seems to take a harder approach to customization, which means that customizers will always be subject to the limitations of the plug-in interface. There will always be a hard boundary between "The Editor" and "Extensions", and I believe that will ultimately limit its usefulness.
I agree with you. Having tasted the emacs way, I'm constantly frustrated (actually I just simply avoid) by interactions with software that isn't so inspectable, and malleable. Still, never blocking user input is a respectable goal for an editor, and a design philosophy I wish emacs would seriously pursue. I would not mind a "feature" freeze on emacs for the remainder of the decade if it meant absolute responsive editing with asynchronous operations.
Emacs customizability is something rare. I had the pleasure to run QBASIC and Turbo Pascal 7 not long ago; and was amazed at the capabilities and speed of these old IDEs. Yet, they were locked. TP7, which is an epic[1] thing, made me feel sad, because the editing features are so basic, almost crippling (no block selection); you physically feel how you miss emacs, where anything is a few LoC away.
[1] text based multifile edition with overlapping windows (including .. ascii window shadowing), invisible compilation times (on a Pentium2), exhaustive help system; all in 800KB.
> you physically feel how you miss emacs, where anything is a few LoC away
That is my problem with IDEs, in a nutshell. There is the running joke that Emacs is a decent operating system in want of a decent editor. The same can be said - more strongly - about Eclipse or Visual Studio.
Some things these IDEs do spectacularly well, for sure, but when it comes to basic text editing, I keep thinking how easy this or that would be in emacs. ;-|
Same, and I started in the Eclipse fad, with eclipse plugin being a thing, before I knew how to program emacs (beside default config). The day I realize how general lisp was and how dynamic emacs was I had to pause for a minute.
Last winter I had to use Eclipse (for scala), one day of mild use trigger nasty wrist pain (I play music, I'm used to pushing the mechanics, that was more). And people say emacs causes RSI ;)
Also the Eclipse crowd is completely off the user side. It's all about tech. Microsoft might be better, I didn't use VS since ages. IDEA is said to be really great at ergonomics. But rarely someone brings a lot to the table. (the only recent thing I noticed was parinfer, ambitious and useful). Also people underestimate what a elisp can do when used correctly. See yasnippet, of Fuco litable.el.
I don't even remap. I think my hands ended up morphing into an emacs stockholm syndrom. Or maybe music did it before that. Still I was surprised that Eclipse would revive such painful sensations.
Modifying existing functions sounds like a recipe for plugin incompatibilities. Vim doesn't let you modify any built-in functions but it seems to be just as powerful.
Indeed, architecturally it's just asking for trouble. However it also lets user extend the system in ways that aren't previously planned for. Pros and cons...
> The editor should never, ever block and prevent the user from getting their work done.
A thousand times this. Emacs and vim are both guilty of failing this most basic principle. It frustrates me to no end that a text editor will hang while font locking text, or printing repl results.
A lot of what used to cause trouble for Vim was fixed with Neovim and the new async stuff Vim 8 introduced. This mainly ensures plugins don't have to block (though a lot still do).
That said, there's still parts of Vim that don't benefit from this and especially on large files can get annoying. But since switching to Neovim I've had a significant drop in the amount of times I have to wait for vim to do something and sit there screaming "oh come on" at my monitor.
Maybe eval'ing to the repl is almost a tic of mine. But as a contrived example, (range 100000) is instantaneous in a clojure repl in the terminal, and interminably slow in cider (emacs package for clojure). There's also SO questions like this[1], and I've personally come across it a lot as well. Anytime lines get long emacs grinds to a halt.
Geiser might just be adding a lot more newlines by default. There is a setting in CIDER to pretty print everything, which alleviates the issue. The core problem is emacs is terrible at displaying/wrapping/navigating/editing long lines.
Well I used GUI Emacs for the 99% of the time. Maybe I should give terminal version a try... I had problem that i couldn't stop tweaking Emacs. I would do work, and come to the point of "aha, I need to this, no plugin on melpa, lets try hack it", and then I realize Emacs devoured my productivity! I like Emacs and it's Elisp eco system, but sometimes it goes too far. And I don't like that it has so many things included. I feel constantly like I use 0.1% of it...
What specifically do you find so great about Emacs? I've forced myself to try it a few times but I couldn't get past the slow performance of the editor itself and the unreliability of basic things like syntax highlighting.
For me I find it quite performant once it's actually running. I've never had a problem with highlights either. Usually there is a minor mode for even the most esoteric language
I was using it to write C++. The default cc-mode didn't work properly. I was then pointed to various random plugins that people had written to address various modern C++ syntax issues but each had their own bugs.
Text editing is basically 90% of command-line interfaces, and Emacs has its own Unix-like shell with Unix-like utilities (that work the same on every platform, even Windows), terminal emulator, file manager, a bunch of email clients (I stopped using any for a while, although I plan to try using mu4e over the holidays), add-ons for any kind of programming language and version control and build system, stuff like calendars and spreadsheets, a file system emulator that lets you transparently work with remote files over a bunch of different protocols (no need to try to set up NFS or whatever on Windows), and all this works the same on any OS and over a terminal connection. It is a great text UI for most computing tasks.
What got my attention recently is Xi (developed by Raph Levien). It is written in Rust, looks fairly interesting, can't wait for it to be in advanced state. I really wouldn't mind some nice, modern, terminal text editor. (I use NeoVim at the moment, and I think it is closest to that, but VimL :cringe:)