[vim user] Usually I don't get baited by the holy war, but this one got me good, well played.
I don't use other editors much, but my experience with them has been that they usually do have good basic vim keybindings, but only for the default keys, and never with support for configuration; I have k-j and j-k mapped to esc, so I don't have to take my hands off the home row to leave insert/visual mode, and not being able to do that is terrible. So I don't use vim keybindings even if they are available -- it's more frustrating to put my brain in "vim mode" and then have some things missing, than to just use the default settings.
Also, it's always been weird to me how it's emacs vs vim. Vim is a text editor; emacs is an IDE and an operating system. When I'm working I'm constantly ctrl-z-ing out of vim to use other tools.
Me too, and for me too.
What do you use that doesn't allow jk for normal mode? I found it works with most programs in which I use vim bindings nowadays:
https://github.com/tasuki/dotrc/blob/master/.inputrc#L8-L13
https://github.com/tasuki/dotrc/blob/master/.zshrc#L41-L42
https://github.com/tasuki/dotrc/blob/master/.ideavimrc#L5-L7
The other problem is speed of typing is irrelevant if you are working with libraries all the time, which is basically what most of the programming world does. This is also true in part for vim. The whole idea of one having to press less buttons to move text around is really a solution for a problem that doesn't exist in the modern world.
Emacs is still very good in things like Keyboard macros, and M-x Occur etc. Basically text manipulation stuff. The thing is that kind of text manipulation work isn't common anymore.
Having said that, I'd be very happy if there was a good default keyboard macro system in vscode. Or in general some emacs features ported to vscode would be really neat. Some features in emacs would make great feature ideas in vscode.
Text is still a large part of computing.
> These days programming languages are designed around tooling.
Every time I see a language which requires a lot of tooling to use it comfortably, usually it's bad designed one
> The whole idea of one having to press less buttons to move text around is really a solution for a problem that doesn't exist in the modern world.
I think the idea is not about having to press fewer buttons, but to bother your brain with unnecessary things as little as possible. With Emacs, you don't have to remember "where the hell is this command and what is the shortcut for it?", you type M-x (especially if you use plugins like counsel or helm) type some related words and that's it. You don't have to know how every function works - M-x decribe-function at your service! Not enough? You can always jump to definition and take a look at it.
> The thing is that kind of text manipulation work isn't common anymore.
You still write programs in text, the commands you give to computer ARE text too, even "modern" menus are nothing but text.
> The thing is that kind of text manipulation work isn't common anymore.
Emacs has LSP plugins, if that's what you are talking about
> Or in general some emacs features ported to vscode would be really neat.
Which features does VS Code have but Emacs don't?
Given that you're still on a computer, what do you think isn't representable as text in one way or other? You can drag and drop images from a browser into Emacs[1], and it will download the image to a sensible (and configurable) location, add a link to the file and display it inline.
> The other problem is speed of typing is irrelevant
Yes, but having an interface which is reasonable and configurable is important for managing cognitive load, and Emacs excels here.
I think a modern lisp based editor, with concurrency/threading built in. With Racket/Clojure/CL backend with modern controls builtin would be all we need.
You still keep the emacs spirit, but with modern outlook.
Sure, but it's the same as the "replace (La)TeX" problem: part of the value of the ecosystem is the huge collection of packages/extensions.
But if there was a reasonable way of porting packages over to a CL/Scheme new editor base, I agree that would be good.
> Including having to do less configuration and tweaking work.
Sure, but a bad, unconfigurable tool is more work.
Text still is mostly everything for all of my backend programming, note taking, etc.
> The other problem is speed of typing is irrelevant if you are working with libraries all the time, which is basically what most of the programming world does.
Typing speed is far from the most important part. It's the consistent interface for everything, reduction of cognitive load, and everything being available at your fingertips in emacs.
How could you emulate emacs? Just the keybinds would miss the point.
I installed the Doom Emacs configuration and it looks really great and modern on macOS. I think you'd like it! Definitely worth a quick install to see what is possible - you can always go and make your own configuration based on that if you want
Doom Emacs: https://github.com/hlissner/doom-emacs
Doom Emacs themes: https://github.com/hlissner/emacs-doom-themes (can be installed standalone but not sure if they disable the toolbars etc)
Is that just the default installation with better choices in the settings? I should have been more patient Emacs and persistent in configuring it.
- better-defaults (removes the toolbars/etc): https://github.com/technomancy/better-defaults
- doom-modeline (a nicer-looking modeline - that's the bar at the bottom): https://github.com/seagle0128/doom-modeline
- base16-chalk theme from base16-theme
All of the above packages are in MELPA.
And then the transparent titlebar is:
(add-to-list 'default-frame-alist '(ns-transparent-titlebar . t))
(add-to-list 'default-frame-alist '(ns-appearance . dark))I don't need better manipulation of meaningless context-free lexicographical symbols. I need better manipulation of context-specific, meaningful, rich objects. I spend very little time on the former, and almost all of my programming time on the latter.
Emacs has had structural editing for lisp how long?
Plus, it's nice to fallback to ctags or ripgrep if your lsp server dies
They are still represented as text in 99% of editing interfaces, and you have to work with that representation.
This doesn't sound particularly earth-shaking, but it really is. Think of a language like Ruby or especially Clojure, where there are a few core data structures, but many things that leverage them. This means that every time you learn part of the Ruby Array API, or a useful function to work on Clojure sequences, you get to use that _everywhere_. So all of Emacs' basic interactions (and they may seem weird to begin with but they're honestly just trying to save your wrists some pain) work everywhere. You can always trust your intuitive, spatial model of the thing you're looking at. Search backwards in a text file, find some text, select it, copy it, go back to the end and paste it. That works exactly the same in a shell. It works exactly the same in a database client. Or SSH'd into a server. Or replying to an email. Same gestures when entering commands, same gestures moving around in autocomplete popups.
Everything you learn with Emacs (and later, everything you write with elisp), has a little incremental benefit to your power and productivity manipulating text. Except everything is text, and so it all multiplies together.
For whatever reason, I've been trying VSCode on Windows the last couple of weeks, coming from an Emacs on Linux background. I cannot tell you how painful I find it, even after making a pretty good attempt to map all the keys correctly (snarky sidebar, sorry: every editor and IDE has really good Vim key bindings, but terrible Emacs support. I used to feel bad about this until I realised it was a sign that Vim people clearly didn't use Vim that much, whereas Emacs people never leave Emacs). But VSCode begins at a completely different level of abstraction to Emacs. It doesn't want to show you a text-based UI everywhere, and implement tools to manipulate text. It wants to show you windows and panels and configuration screens and extensions with their own behaviour. Everything is modal and different, some windows are special, and you can't just navigate around the same way everywhere.
So, sure, this isn't for everyone, but it's what I love about Emacs, to the point that the many regular indignities it forces on you (hangs if you're not careful about large files, abysmal performance of various things on Windows because of the overhead of starting processes, and sure, the learning curve for some people) are bearable because everything is so natural.