Re:The Era of Visual Studio Code
by paulryanrogers on Tuesday September 22, 2020 @09:16PM
(#24561940)
Keyboard conventions do come and go but muscle memory is expensive to reprogram. Your hands are also irreplaceable. So I go for the most efficient that's not too radically unfamiliar or painful.
And honestly one could spend a career learning every editor/IDE in depth without ever accomplishing anything else. Embedded is especially bad as one often must use the IDE integrated into the platform's SDK.
Re:The Era of Visual Studio Code
by atilaneves on Wednesday September 23, 2020 @07:52AM
(#24565874)
I think you missed the point where they mentioned you can change any and all keybindings in Emacs.
Re:The Era of Visual Studio Code
by paulryanrogers on Wednesday September 23, 2020 @08:52AM
(#24566396)
Right but that requires learning Emacs well enough to change bindings. Then all the other tweaks one makes to a tool like text expansions, macros, and learning differences in find-replace, refactoring, and autocomplete.
There's no more learning required for changing Emacs keybindings than in other IDEs. If you don't want to go the scripting way, you can use the Customize interface, which is Emacs's equivalent of Settings dialog in most other software. Hell, unlike most software, Customize interface gives you a choice between applying changes temporarily and permanently, so you can try things out and if you mess up, just restart the editor.
(Under the hood, stuff you change via Customize gets serialized into a file called custom.el. But you don't have to know that to use it.)
Current keyboard conventions go back to 1984 and the Mac, and no sign of them changing anytime soon.
The article mentions Excel, for example, coming a few years after that and going strong today.
So I really do think Emacs predating those conventions is not going to be overcome.
This has an important downstream consequence on the "plugin" ecosystem: since these "plugins" are better seen as small applications running on in a shared, restriction-free OS, they don't need a fixed and restrictive API to interoperate. The entire Emacs is the API, and as long as an elisp app follows conventions and plays nice, it will almost seamlessly interoperate with every other app. And in cases where it doesn't (e.g. you try to use two apps that do roughly the same thing), it's relatively trivial to patch out the conflicts yourself. Having an integrated debugger and REPL is also helpful :).
VSCode philosophy feels more restrictive compared to that.
As for the keyboard conventions, it's true and it impacts the market share, but that's a problem for almost any software that reaches longevity. Conventions come and go, so it shouldn't stop one from learning a tool that keeps proving its worth over decades. And in case of Emacs, if you don't like the default keybindings, you can quite easily patch them up to follow whatever convention you fancy :).
Terminology is a slightly worse problem because you can't patch that out if you don't like it - but then again, it's just a bunch of terms you need to learn; par for the course for any developer.