Hacker News Reader

> 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/ ) instead of nano. The ability to use the same keyboard shortcuts that i'm used to is a godsend.

You don't need nano when you have vi on every install anyway.

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.

There is also mg: http://en.wikipedia.org/wiki/Mg_(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!)

Don't forget Eclipse.

Neither Windows.

All those web browsers, IRC clients, email programs. You can do pretty much everything inside an emacs.

If you ever draw a Venn diagram of Windows users and Emacs users, you'll see the intersection of both sets is vanishingly small.

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!)

wasn't this what elisp was for, albeit it is very emacs centric.

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.

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

> Some of those editors are already superior.

To vi(m)/emacs? An example?

They're easier to use.

No, they're easier to get into if you're used to Notepad.

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

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.