5 ms·

I've always thought that the whole vi(m) vs. Emacs "war" is a false dichotomy. I'm an Emacs guy myself; I haven't used vi(m) a lot, but from all I gather it's

I've always thought that the whole vi(m) vs. Emacs "war" is a false dichotomy. I'm an Emacs guy myself; I haven't used vi(m) a lot, but from all I gather it's a fine editor. The real "enemy", if we need to use war-inspired vocabulary, are editors like nedit, Kate, ScITE, and maybe even Textmate (boy am I going to get told off for this!) Emacs and vi(m) are great editors today, but imagine how much even greater they would be if all those people pouring hundreds and thousands of man-hours into projects like Gedit, JEdit, KWrite, Medit, etc. would have instead put their efforts towards improving the true editors! Disclaimer: I haven't really used those other editors a lot and I'm sure that each of them has something going for it. Also, I know how much fun it is to work on something challenging, like a text editor, even if (or exactly because) there are already established "solutions". Finally, a few alternative editors are genuinely useful, such as nano - it might be inferior in pretty much every regard to Emacs, but it's not possible to shrink Emacs to nearly the size of nano so it does seem to serve a valuable purpose for when disk space or memory footprint is an issue. Cue the Eight Megabytes And Constantly Swapping jokes. EDIT: and yes, Emacs/vi(m) are not necessarily the be-all, end-all of editors for all time to come; maybe one of those alternative editors will one day prove to be superior. All those other editors just remind me of the phrase "Those who don't understand Emacs/vi are condemned to reinvent it, poorly"... err, or something like that.

rbanffy 16y ago
> The real "enemy", if we need to use war-inspired vocabulary, are editors like nedit, Kate, ScITE, and maybe even Textmate (boy am I going to get told off for this!) Don't forget Eclipse.
- scorpion032 16y ago
  Neither Windows. All those web browsers, IRC clients, email programs. You can do pretty much everything inside an emacs.
  - rbanffy 16y ago
    If you ever draw a Venn diagram of Windows users and Emacs users, you'll see the intersection of both sets is vanishingly small.
alextgordon 16y ago
> Emacs/vi(m) are not necessarily the be-all, end-all of editors for all time to come; maybe one of those alternative editors will one day prove to be superior Some of those editors are already superior. Imagine you convince <insert name of computer-illiterate relative> to switch to linux. If they need to edit a text file, are you going to recommend Kate/gedit or Vim/Emacs? I would wager a lot more non-programmers use text editors than programmers. Of course programmers use text editors a lot more often, but still the importance of those other editors should not be underestimated.
- verysimple 16y ago
  > Some of those editors are already superior. To vi(m)/emacs? An example?
  - alextgordon 16y ago
    They're easier to use.
    - aerique 16y ago
      No, they're easier to get into if you're used to Notepad.
      - alextgordon 16y ago
        I find this response baffling. Are you seriously claiming that normal people (non-developers) would do better using Vim/Emacs rather than a Notepad-like editor? Or that most normal people aren't used to Notepad-like editors? I despair...
      - gnosis 16y ago
        Not even that. For instance, gvim comes with an "easy mode" (just start it as "evim"). In this mode, it acts very much like Notepad (you're automatically in insert mode, and you can just use the File menu to open files, save, and exit). I'm not sure how much having this mode buys vim, however, as there's no gradual way to progress from "easy mode" to more advanced vim use. Except for the syntax hilighting it offers, its users might as well just be using Notepad, nano, pico, or what have you.
sophacles 16y ago
I agree with your "too much fragmentation" argument. Although I think a better solution would be this: 1. Define a common API to text editors. It would have stuff like "change text at" and "highlight line" and so on. Going the other direction there would be a set of well defined events like "text changed" and "do X", and so on. 2. Convince tool makers to write to this api rather than a specific editor. 3. Enjoy awesome source tools from any darn editor you want. (Also, IDEs don't go away, they become the gui layer in editor/plugin interaction. This is not a small role!)
- brianobush 16y ago
  wasn't this what elisp was for, albeit it is very emacs centric.
  - sophacles 16y ago
    Elisp is the inverse of what I am talking about... it is a special purpose language to take advantage of a specific editor. I am talking about a well defined generic interface that allows for all editors to tie nicely with code-tools.
kanak 16y ago
> Finally, a few alternative editors are genuinely useful, nano - it might be inferior in pretty much every regard to Emacs, but it's not possible to shrink Emacs to nearly the size of nano so it does seem to serve a valuable purpose for when disk space or memory footprint is an issue. I'm an emacs user too, and I now use zile ( http://www.gnu.org/software/zile/ http://www.gnu.org/software/zile/ ) instead of nano. The ability to use the same keyboard shortcuts that i'm used to is a godsend.
- sigzero 16y ago
  You don't need nano when you have vi on every install anyway.
  - weaksauce 16y ago
    The gp is an emacs user and zile is a bare bones emacs. If you are a proficient emacs user going to vi is going to be torturous even on small projects. I am a vim user and I see why the gp would want to skip vim and use something comfortable.
- ez77 16y ago
  There is also mg: http://en.wikipedia.org/wiki/Mg_(editor) http://en.wikipedia.org/wiki/Mg_(editor)

rbanffy 16y ago

> The real "enemy", if we need to use war-inspired vocabulary, are editors like nedit, Kate, ScITE, and maybe even Textmate (boy am I going to get told off for this!) Don't forget Eclipse.

scorpion032 16y ago
Neither Windows. All those web browsers, IRC clients, email programs. You can do pretty much everything inside an emacs.
- rbanffy 16y ago
  If you ever draw a Venn diagram of Windows users and Emacs users, you'll see the intersection of both sets is vanishingly small.

alextgordon 16y ago

> Emacs/vi(m) are not necessarily the be-all, end-all of editors for all time to come; maybe one of those alternative editors will one day prove to be superior Some of those editors are already superior. Imagine you convince <insert name of computer-illiterate relative> to switch to linux. If they need to edit a text file, are you going to recommend Kate/gedit or Vim/Emacs? I would wager a lot more non-programmers use text editors than programmers. Of course programmers use text editors a lot more often, but still the importance of those other editors should not be underestimated.

verysimple 16y ago
> Some of those editors are already superior. To vi(m)/emacs? An example?
- alextgordon 16y ago
  They're easier to use.
  - aerique 16y ago
    No, they're easier to get into if you're used to Notepad.
    - alextgordon 16y ago
      I find this response baffling. Are you seriously claiming that normal people (non-developers) would do better using Vim/Emacs rather than a Notepad-like editor? Or that most normal people aren't used to Notepad-like editors? I despair...
    - gnosis 16y ago
      Not even that. For instance, gvim comes with an "easy mode" (just start it as "evim"). In this mode, it acts very much like Notepad (you're automatically in insert mode, and you can just use the File menu to open files, save, and exit). I'm not sure how much having this mode buys vim, however, as there's no gradual way to progress from "easy mode" to more advanced vim use. Except for the syntax hilighting it offers, its users might as well just be using Notepad, nano, pico, or what have you.

sophacles 16y ago

I agree with your "too much fragmentation" argument. Although I think a better solution would be this: 1. Define a common API to text editors. It would have stuff like "change text at" and "highlight line" and so on. Going the other direction there would be a set of well defined events like "text changed" and "do X", and so on. 2. Convince tool makers to write to this api rather than a specific editor. 3. Enjoy awesome source tools from any darn editor you want. (Also, IDEs don't go away, they become the gui layer in editor/plugin interaction. This is not a small role!)

brianobush 16y ago
wasn't this what elisp was for, albeit it is very emacs centric.
- sophacles 16y ago
  Elisp is the inverse of what I am talking about... it is a special purpose language to take advantage of a specific editor. I am talking about a well defined generic interface that allows for all editors to tie nicely with code-tools.

kanak 16y ago

> Finally, a few alternative editors are genuinely useful, nano - it might be inferior in pretty much every regard to Emacs, but it's not possible to shrink Emacs to nearly the size of nano so it does seem to serve a valuable purpose for when disk space or memory footprint is an issue. I'm an emacs user too, and I now use zile ( http://www.gnu.org/software/zile/ http://www.gnu.org/software/zile/ ) instead of nano. The ability to use the same keyboard shortcuts that i'm used to is a godsend.

sigzero 16y ago
You don't need nano when you have vi on every install anyway.
- weaksauce 16y ago
  The gp is an emacs user and zile is a bare bones emacs. If you are a proficient emacs user going to vi is going to be torturous even on small projects. I am a vim user and I see why the gp would want to skip vim and use something comfortable.
ez77 16y ago
There is also mg: http://en.wikipedia.org/wiki/Mg_(editor) http://en.wikipedia.org/wiki/Mg_(editor)