3 ms·

Vim productivity has been overblown by the fanboys of terminal-based text editors, vim et al are sorta on the verge of being irrelevant even deprecated because

Vim productivity has been overblown by the fanboys of terminal-based text editors, vim et al are sorta on the verge of being irrelevant even deprecated because there are two things that are getting better: modern languages and IDE's. Vim/emacs existed solely because there wasn't anything better (lookup for ed, that's a real man editor) to develop on the old-days plus old-school languages have this trend of including tons of "ceremony" and "duck-tape" code for handling data that vim was good because the repetitive nature of those things while coding but those days are over, there are less jr's learning vim/emacs and those "Vim masters" you talk are becoming less and less irrelvant with every year, i expected that in the next 5 years vim will be talked as a thing of the past.

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 ago
    The 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.
mason55 9y ago
> vim et al are sorta on the verge of being irrelevant even deprecated because there are two things that are getting better: modern languages and IDE's. I don't spend a ton of time coding any more but do spend a ton of time doing random text editing (properties files, XML, data manipulation, whatever). While I agree that modern IDEs are probably better if you're just doing straight coding I think there will always be a place for a high powered text editor. Plus, if I'm editing a script on a remote host (random shell script) or just need to make a quick change to something locally then it's much faster/easier to drop into vim than to fire up an IDE.
- SadWebDeveloper 9y ago
  IMHO vim for editing remote files it's still far too complex, i prefer nano for editing config files and write some tiny shell scripts. I do give you the reason when editing long xml files remotely, vim is superior on that but still i prefer to locally edit the xml file with a IDE because i have the possibility to visually collapse entries and automatically show syntax errors. I know vim/emacs fanboys are going to say that all that it's possible on vim/emacs but still i have to invest time configuring those options and plugins on vim while on almost every IDE or even some simplistic GUI editor like Notepad++ those things come already configured and ready for work.

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 ago
  The 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.

mason55 9y ago

> vim et al are sorta on the verge of being irrelevant even deprecated because there are two things that are getting better: modern languages and IDE's. I don't spend a ton of time coding any more but do spend a ton of time doing random text editing (properties files, XML, data manipulation, whatever). While I agree that modern IDEs are probably better if you're just doing straight coding I think there will always be a place for a high powered text editor. Plus, if I'm editing a script on a remote host (random shell script) or just need to make a quick change to something locally then it's much faster/easier to drop into vim than to fire up an IDE.

SadWebDeveloper 9y ago
IMHO vim for editing remote files it's still far too complex, i prefer nano for editing config files and write some tiny shell scripts. I do give you the reason when editing long xml files remotely, vim is superior on that but still i prefer to locally edit the xml file with a IDE because i have the possibility to visually collapse entries and automatically show syntax errors. I know vim/emacs fanboys are going to say that all that it's possible on vim/emacs but still i have to invest time configuring those options and plugins on vim while on almost every IDE or even some simplistic GUI editor like Notepad++ those things come already configured and ready for work.