5 ms·
To some extent what you write is true of vi (there was nothing better when it was written), and vim exists for folks who are used to vi to get some features of
by zeveb 9y ago
To some extent what you write is true of vi (there was nothing better when it was written), and vim exists for folks who are used to vi to get some features of an extensible editor (i.e., vim is an emacs for vi-users, just with a far worse extension language and fewer decades of debugging), but what you write is false when it comes to emacs.
The benefit of emacs is that it is a completely extensible environment for editing text. It turns out that just about everything we do on computers involves text: source code, sure, but also web pages, git, email, shells, configuration, UIs &c. All of that stuff is text, and emacs can handle it all, and it can be extended to handle the next thing which comes down the pike too[0]. emacs is the forever editor: decades after SublimeText and Atom are dead & gone, emacs will continue.
vi & vim will continue, too, because the textual language of vi is still more powerful than any of those GUI editors. It's more powerful than the default keybindings of emacs (although note that with things like evil-mode or viper, emacs takes on vi keybindings). Even GUI apps which try to implement vi(m) bindings generally fall down because they implement so few (in the same way that apps which try to implement emacs-style extensibility fall down because they use insufficiently powerful languages).
I don't know what editor the hip young kids of 2067 will be using, but I know that the folks getting stuff down will be using vi & emacs.
[0] vim can also be extended to handle anything, but compare:
function! ToggleSyntax()
if exists("g:syntax_on")
syntax off
else
syntax enable
endif
endfunction
nmap <silent> ;s :call ToggleSyntax()<CR>
vs:
(defun toggle-syntax ()
(setf syntax (not syntax)))
(global-set-key "\C-cs" 'toggle-syntax)
Which would you rather write?
- mason55 9y ago> Which would you rather write? I get your point but I don't think this is a good example. This is the kind of thing you write one, put in your .vimrc, and then never have to think about again. Especially if you're putting your .vimrc in source control and pulling it down automatically into new environments.
- zeveb 9y agoThe problem is that anything written in vimscript is going to resemble that first example, when were it written in elisp it could resemble the second. Regardless, better to have vim or emacs than anything else.
- SadWebDeveloper 9y ago> I don't know what editor the hip young kids of 2067 will be using, but I know that the folks getting stuff down will be using vi & emacs. I have yet to met a developer that blame his inability to "get stuff down/done" because his editor don't let him write fast enough. Developing isn't a who-can-type-faster contest is who can solve a problem in a fast and simple way, typing/coding is the thing you do _after_ you solve the problem.
- zeveb 9y ago> Developing isn't a who-can-type-faster contest is who can solve a problem in a fast and simple way, typing/coding is the thing you do _after_ you solve the problem. You're right, and that's the thing: emacs isn't better because it enables one to type more quickly; it's better because it enables one to do more. With emacs, a developer can build out his own environment, and he can share that customisation with others. As an example, magit is by far the best way to interact with git. Another example is org-mode. Another is gnus. Another is notmuch. And on and on. Indeed, it's this emphasis on extensibility which is why I prefer emacs (which is better-extensible) to vim (which, frankly, has a better text-manipulation language). There's simply no competitor to emacs when it comes to extensibly interacting with text. Even if SublimeText, Atom, IntelliJ, Eclipse, Visual Studio got perfect vi keybindings, I do not believe that they'd be as extensible as vim, let alone emacs. Since extensibility is the quality which enables a tool to be used for more than its designer imagines, and since no designer can imagine all his users' use-cases, I think that this means that SublimeText et al. will never be all one needs.