Comparison: Linux Text Editors

jrepin writes: Mayank Sharma of Linux Voices tests and compares five text editors for Linux, none of which are named Emacs or Vim. The contenders are Gedit, Kate, Sublime Text, UltraEdit, and jEdit. Why use a fancy text editor? Sharma says, "They can highlight syntax and auto-indent code just as effortlessly as they can spellcheck documents. You can use them to record macros and manage code snippets just as easily as you can copy/paste plain text. Some simple text editors even exceed their design goals thanks to plugins that infuse them with capabilities to rival text-centric apps from other genres. They can take on the duties of a source code editor and even an Integrated Development Environment."

Comments

You're welcome to them.

[jeffb (2.718)]

It may not have been wise for me to spend years training vi into my muscle memory, but it's done now, and I'm not especially interested in giving up that advantage.

Re: You're welcome to them.

[Anonymous Coward]

Have you used Vim lately? With its multitude of plugins, it's hard to make the point that it's an editor from the Stone Age. I sometimes switch to editors like Sublime and always find myself coming back to Vim. It's extremely powerful, allows me to do complicated edits and movements, and it has all the features I'd expect in any GUI editor.

Stop being a prick. Not everyone uses vi/vim because it's "cool". Many of us use it because it's simply more productive to do so.

Re:You're welcome to them.

[ccanucs]

It's a matter of functionality, speed of use and the commonality of embedded operations that work the same as in other UN*X tools. Incredibly powerful. Would pay to have vi on systems that don't have it.

Re: You're welcome to them.

[Anonymous Coward]

Except that Vim is not a pig. I started using it 3 years ago, not because it's cool, but because many programmers recommended it to me.
I've been a programmer for more than 20 years, and during the past years using Vim I regretted many times that I hadn't take the time to make the switch sooner.
All other editors I tried (but I never tried Emacs) helped me a lot at the beginning, but eventually I would hit a top and stop improving. With Vim I feel like there is no limit to the productivity gains I can achieve. It's user interface is a language and I speak it more fluently every day, and I can extend it with customization.

Re: You're welcome to them.

[Em Adespoton]

I use Sublime with vim bindings turned on. It has features I use every day that vi/vim doesn't have, and doesn't get in the way of my vim muscle memory. It also doesn't get in the way of my ed muscle memory, nor my Mac muscle memory. In fact, pretty much whatever legacy text editor my muscle memory thinks I'm using, Sublime will interpret the commands correctly and let me get the job done.

I've used all the listed editors, and eventually settled on the vim/Sublime combo, as they accomplish everything the others do, and then some.

And to think that 20 years ago, I was a diehard emacs user. I liked my macros, but Sublime can do all that too; it just prefers python over LISP.

Re:You're welcome to them.

[Anonymous Coward]

My preference is to use Notepad++ on Windows for everything, even when I have Visual studio, because it loads fast. If I'm going to compile things locally then I use Visual Studio.

On *nix OS's I use Midnight Commander editor (mcedit) if it's available, nano or pico if it's not, and only resort to vi when the system is obnoxious about using it (like editing crontab or passwd files, which BTW I do with MC anyway despite the archaic warnings.) MC has syntax highlighting and all the minimal BS I want to put up with that the plain text editors don't have.

Nobody needs to use VIM or Emac's anymore unless that's what they are comfortable using.

The article is about GUI text editors. See here's the thing, you can open the text editor in a command line prompt or ssh shell, anywhere, but using a GUI text editor is much more involved (a separate FTP or SFTP/SCP step is required to put the file where you want it.)

Re: You're welcome to them.

[EricScottChandler]

I've been a faithful vi user for 15 years. I couldn't imagine using anything else at this point. Heck, I named my firstborn Vi. Ok, no I didn't.

Re: You're welcome to them.

[CaptnZilog]

I would have gone for "ed" maybe. ;)

Re:You're welcome to them.

[Volguus Zildrohar]

There are many times where you repeat code and DRY does not apply. Common patterns that apply to different projects, but are mostly just grunt-work typing.

snipMate for Vim adds a nice version of code snippets. For example, I type "#!" in python scripts to add "#!/usr/bin/env python". It's a small single saving, but things like that add up over numerous scripts, and help avoid typos.

Re: You're welcome to them.

[MacTO]

Another often overlooked advantage of vim is continuity. Thos of us who learned vi because it was one of the best editors at the time can still use those skills. When the need arises, we can also build upon those skills with a modern implementation. In all likelihood I'll be able to make the same claim 20 years from now, when most (if not all) of these upstarts will be long forgotten.

New and improved is great. Constantly relearning skills that you already have, to adapt to new interfaces, isn't so hot.

Re: You're welcome to them.

[dcollins117]

Or Kate, if it's a girl. And Emacs if you're not quite sure what the hell it is.

Re: You're welcome to them.

[Anonymous Coward]

Sounds like you need a better compiler.

Re:You're welcome to them.

[AxeTheMax]

So what systems are these that Kate has crashed on? It has never given me any problems whatsoever on several Linux (KDE) systems.

Re: You're welcome to them.

[davester666]

run. run away when you see little Emacs coming.

Re: You're welcome to them.

[ThePhilips]

The problem with Vim (and Emacs) is that they do not support anything modern, not even ctrl-z/x/c/v.

VIM has the "VIM Easy" mode, which when used on MSWindows would do Ctrl-Z/X/C/V out of box. And even select text when holding Shift and moving around with cursor keys.

Shortcut to VIM Easy is preinstalled. If you complain about it, then you probably never really used the VIM. Or are you complaining about the *NIX "vi"?

For programming Eclipse or NetBeans or Visual Studio is just miles away what of vi/emacs can do, especially out of the box.

The problem for the professionals is not what the IDE can do out of box, but what can it be made to do. Eclipse or NetBeans or Visual Studio - all suck horribly at everything for what there is no button premade. And when there is a button for everything - they suck at finding this right button.

But I'm not planning to contest the point that VIM is not IDE. No, it is not "VIM is bad IDE" - it is "VIM is not IDE". (This is different for Emacs, though: it is an IDE and then some more. One needs to learn it. And lack of good in-depth tutorials is actually what turned me off from the Emacs.)

The thing about VIM is that it integrates nicely with the system, instead of reinventing it. And it also provides great automation facilities with macros, mappings or scripts. They are fairly simple and can be learned in 1-2 weeks, which is a small price to pay for the ability to control 100% of your text editor. That is the capability no other editor offers.

To get vi/emacs to work nearly as good as good IDE is just too big a job.

(Please do not say "vi" when you really mean "VIM".)

In the project Neovim the work going on to make the Lua the built-in scripting language and improve VIM's plug-in framework. All that to specifically allow to create IDE based the VIM. (Though in my opinion, the direction of the Neovim effort is misguided. They should have went in direction of allowing VIM to be easily embeddable into other applications.)

So in the future, there might be an IDE based on VIM. But not right now.

For example NetBeans ctrl-b (go to declaration). Sure, you can install ctags, configure it, run it, tinker with it, tinker some more, add custom rules, search net, rinse-and-repeat and eventually you'll get something resembling ctrl-b, but not quite the same.

This is probably the most unjustified complain you throw. The tags support in VIM is very good - if you bothered to RTFM. Literally every book and tutorial describe these highly sophisticated and inexplicable 3 steps involved: install the exuberant ctags, put into the .vimrc the line ":set tags=tags;/", and finally run "ctags -R ." in the root of the project.

If you use plugins like YouCompleteMe, they would do it for you automagically.

In the end, if you can't bother to read the VIM's help (which is by far the best help for a text editor there is out there) then VIM is definitely not for you.

Re: You're welcome to them.

[serviscope_minor]

The problem with Vim (and Emacs) is that they do not support anything modern, not even ctrl-z/x/c/v.

Yeah we al know vi has esoteric keybindings. You're raising this like it's some fundemental point.

For programming Eclipse or NetBeans or Visual Studio is just miles away what of vi/emacs can do, especially out of the box.

No it can't. vim is so much more than a Java, C++ or C# editor. None of those "miles away" editors provide syntax highlighting for shell, awk, python, etc

To get vi/emacs to work nearly as good as good IDE is just too big a job.

No, I disagree, again. Or at least if you're trying to turn vim into an IDE then you're doing it wrong and misunderstanding the tools. Unix is the integrated development environment, and it provides lots of sub-tools (compilers, editors, build systems and so on) to cover all the aspects of development.

in NB this will understand the variable and give completitions according to that. It will give hints to the parameters too. In every language there is

This is spoken like someone so wrapped up in visual studio that you haven't seen the outside world. Firstly, it doesn't work unless you've already declared the variable (duh). Small point, but it forces you to write the code top-to-bottom so that the variable has been defined before you use it. When you're used to a rather more freeform development style, the visual studio top-to-bottom style is rather awkward and limiting. Not to say that intellisense does not work very well and isn't very handy, but it's not the be-all and end-all and often produces worse results than simple text completion.

Also, every language there is? Tell me, how well does it handle an awk script embedded inside a atring inside a shell script?

I do not want to waste my time to get mundane things like that to work properly.

I'm mainly a programmer, but I've been slowly wandering in the direction of toolmaking (as in real physical thinga). I've always been an engineer. The idea of using only the tools you have in the form they come out of the box come hell or high water and never going to additional lengths to increase the toolbox and automate processes and just plain make things easier is a completely foreign idea to me. If you want to see a funny facial expression, go up to a woodworker and say something along the lines of: I don't want to take the time to make a jig, I just want to get things done.

Re: You're welcome to them.

[socode]

I don't use it exclusively, but these features are what swung me. 1) mini map - a godsend when understanding quickly the structure of large files, particularly those you are lumbered with 2) slick multi-select and edit 3) fast search all files and interactive step though 4) same L&F on Mac, Windows, Linux since I need to use all three.

Re: You're welcome to them.

[TheRaven64]

Code duplication is not free either. Even if execution time is the only thing that you care about, on anything that's vaguely like a modern CPU (GPUs and microcontrollers are somewhat different), instruction cache space is the most scarce resource, with data cache the second. A function call will likely be branch predicted and in an out of order system the prolog and epilog are mostly handled by the register renaming infrastructure, so the function call is almost free, but the cost of an instruction cache miss from having too many copies of the same code is quite measurable.

Re: You're welcome to them.

[s122604]

Yep, pretty much this..
If you aren't using a modern IDE like eclipse for Java, or VIsual Studio for .net languages, you're doing it wrong
It's like pulling an automobile with a rope tied to your balls, impressive, but there are better ways to get the job done.

Where editors like vi and Emacs, in the hands of an expert, still shine is configuration file maintenance, and really file maintenance on any text that isn't compilable source code.
I really wish I knew them better than I do, just for that reason. I can use them, but just at a basic level.

Re: You're welcome to them.

[david_thornley]

8-10 years ago, I was working on an application that was annoyingly slow, and a profiler showed that 80% of the time was spent in one particular function that was long and repetitive. I rolled up the calculations as tightly as I could, using as little duplicate code as I could, and sped the app up markedly. I roughly halved the amount of time that function took.

Pfft

[relisher]

You can do all of this in Emacs and Nano. No need for some shiny new text editor...

Re:Pfft

[Stele]

Okay okay I'll get off your lawn!

Re:Pfft

[techno-vampire]

I've been using nano, or as I like to call it, "Mork's editor," for a number of years when I've needed (or wanted) to do text editing in a CLI environment under Linux and I've never had a bit of trouble with it, even with line endings. You just have to remember that in some places, such as /etc/fstab, you need to make sure there's a /n at the end of every line, including the last one. Of course, my bashrc includes alias nano='nano -w -m' which may well explain why I've had such good luck with it.

Re:Pfft

[TheGoodNamesWereGone]

Nano has gotten me out of a jam more times than I can count when I couldn't get X working. It's simple, easy to use, and works great.

Re:Pfft

[Darinbob]

Ya, I'm surprised by the summary. Apparently the author has not actually used emacs or vim, and instead listed the BARE MINIMUM set of features that any editor should support. Maybe the author came with a pre-existing bias against emacs and vi as "tools for old farts" and assumed any new tools must automatically be better.

What's there to compare?

[qw(name)]

none of which are named Emacs or Vim

What's there to compare? Everything else is just Notepad.

Re: What's there to compare?

[LocutusOfBorg1]

Exactly! --- sent from emacs

Re: What's there to compare?

[LocutusOfBorg1]

BTW that was a joke, I'm a proud vi(m) user, but I think emacs can also post on ./, vim cannot :-)

Re:What's there to compare?

[zAPPzAPP]

But Notepad(++) is pretty good...

Re:What's there to compare?

[Em Adespoton]

vi aka vi

I predate emacs (esc alt meta key) and it is on all unix systems. emacs is still spotty and sometimes you need to install it--vi is always there.

mqh

Not true -- I've been in many situations where 'which vi' has returned nothing.

Now ed is always there -- any environment that doesn't contain ed is not worth being in. It's been the default since 1971, unlike newcomers such as vi that didn't show up until 1976.

Re:What's there to compare?

[Arker]

So they did a text-editor roundup that excluded every serious contender in favor of 5 third-string also-rans.

I actually tried to read the text but it was too brain-numbingly stupid to get through. He's trumpeting all these wonderful features that... vi and emacs had in the 80s.

It's so true - 'those who do not remember Unix are condemned to re-invent it, poorly.'

Re:What's there to compare?

[Darinbob]

But but but.. the newer editors are different! """They can highlight syntax and auto-indent code just as effortlessly as they can spellcheck documents. You can use them to record macros and manage code snippets just as easily as you can copy/paste plain text. Some simple text editors even exceed their design goals thanks to plugins that infuse them with capabilities to rival text-centric apps from other genres. They can take on the duties of a source code editor and even an Integrated Development Environment."""

Next you'll be pulling my leg and telling me that emacs and vim can do that stuff too. You sound like the skeptical sort of person who refuses to believe the words of truth that flow from the marketing departments.

(do I really need to mark this as sarcasm, on the one hand it's obvious, but on the other hand this is slashdot)

Re:What's there to compare?

[shadowknot]

So they did a text-editor roundup that excluded every serious contender in favor of 5 third-string also-rans. I actually tried to read the text but it was too brain-numbingly stupid to get through. He's trumpeting all these wonderful features that... vi and emacs had in the 80s. It's so true - 'those who do not remember Unix are condemned to re-invent it, poorly.'

Lennart Pottering needs to read the last line of this comment in particular!

What the fuck happened to gedit's UI?

[Anonymous Coward]

I used to use gedit on Linux a lot a few years ago. I then used OS X for a few years, but I recently moved back to Linux. One of the first things I did after getting Linux installed was try to edit some files using gedit. And my first reaction was: JESUS FUCKING CHRIST, WHAT IN THE FUCKING HELL DID THEY DO TO GEDIT'S UI?!

It used to have a good, traditional UI. There were useful menus and a toolbar, and it all worked very well. But now, JESUS FUCKING CHRIST, it looks stupid as all hell. There are no menus any longer, and the toolbar has been castrated into having like 4 buttons. The icons are pathetic, and don't indicate what the button actually does. Whoever the hell reworked the UI managed to break what was once a very usable text editor. Now it's rubbish.

It's like they took the idiotic UI design of Chrome and brought it over to gedit. And now gedit is useless to me! So I've moved on to Kate. At least the KDE crew hasn't gone completely fucking stupid like the GNOME dipshits apparently have.

Why the fuck did they have to ruin gedit's UI?

Re: What the fuck happened to gedit's UI?

[neiras]

As someone who actually likes GNOME Shell, I have to agree. The new-style GNOME apps are horrible. Over simplified, too much white space.

In particular the whole "move dialogue buttons to the window title bar" thing is jarring.

I just use Shell and ignore as much of the rest of GNOME as I can.

Re:What the fuck happened to gedit's UI?

[0123456]

Buttons and menus confuse users.

Or something.

Did they ever fix the god-awful nonsense where Gedit refuses to open a file because it thinks it's some wacko Unicode crap and doesn't even give you an 'I don't freaking care, just open the goddamn file as ASCII' option?

Have you seen Gedit lately?

[Anonymous Coward]

Have you seen Gedit lately? Its new user interface is even less usable that vi's is: https://en.wikipedia.org/wiki/Gedit#mediaviewer/File:Gedit_3.11.92.png

The Gnome designers just keep making Gnome's user interface worse and worse to use. I guess that's why so few people use Gnome these days!

Re:Have you seen Gedit lately?

[Anonymous Coward]

Vi has a learning curve that's more of a cliff than a curve, but it's probably the most usable text editor ever invented. People get freaked out by it and give up on trying to learn it, but everything is available without having to remove your hands from the keyboard and it has commands for virtually anything that you're likely to want to do.

Re:Have you seen Gedit lately?

[Skarjak]

You weren't kidding. I just downloaded gedit just to see. There's one option button. You can basically open files, save files, print them, hilight syntax, find and replace and see document statistics. That's certainly... spartan.

Re:Have you seen Gedit lately?

[Bazman]

A Pedant Writes: A learning curve is a plot of amount of stuff learnt on the y-axis against time on the x-axis. A steep learning curve means you learn quickly. I avoid using "steep learning curve" which I know in common usage is often taken to mean the opposite of its original meaning and use "slow learning curve", since "slow learning" is less ambiguous, hopefully..

You'll thank me later.

Geany

[lorinc]

Where's geany? It's much better than gedit.

Re:Geany

[sayfawa]

Agreed. Without geany there, this comparison is not very useful. Whenever I was using Linux, I missed notepad++, until I found out about geany.

Re:Geany

[Camel Pilot]

Vote here for geany also...

In my recent switch from Windows to Centos for my desktop/development computer I was missing an editor on par with notepad++. Found geany and I haven't looked back. Excellent all around.

depends on what you're doing

[roc97007]

Sorry if this is stating the obvious, but if you're a programmer who does lots of editing on a few machines, then pick the editor that best fits the job.

However, as an admin, I have long ago standardized on VI for the simple reason that it's included by default on every single *nix variant out there. (At least, in my experience.)

My cunning strategy breaks down with Windows, though. Notepad is so nasty to use that I find myself installing textpad or cygwin on the machines where I do most of my work.

Re:depends on what you're doing

[Anonymous Coward]

However, as an admin, I have long ago standardized on VI for the simple reason that it's included by default on every single *nix variant out there. (At least, in my experience.)

FWIW, vi(1) is actually part of the POSIX specification. So you're guaranteed at least the base level of functionality (which is generally all you need to tweak /etc/hosts, etc.).

For heavier coding jobs something else can be useful, but for the basics: getting in, moving around, editing, and saving/quitting, are what you need to know. Anything after that is gravy.

Re:depends on what you're doing

[Rutulian]

However, as an admin, I have long ago standardized on VI for the simple reason that it's included by default on every single *nix variant out there. (At least, in my experience.)

While true, in my experience there is no reason why nano could not be included (and should be).

Re:depends on what you're doing

[Darinbob]

You essentially are required to install cygwin on all windows computers before they become marginally useful.

Re:depends on what you're doing

[cbhacking]

Until Win8.1, it was actually possible to install a "native" POSIX environment on NT-family OSes (which for most people means XP and anything since then). It had better performance and was more Unix-y than Cygwin - key differences include support for things like SetUID/SetGID/Sticky bits and case-sensitive file system (required NTFS, and could occasionally confuse Win32 programs if there were two files whose name differed only in case, but it worked), though there were others (like not tacking .EXE on the end of every program name). It was called SUA (Subsystem for Unix Application), and was quite useful for those who needed to run Windows software but wanted a bash shell and compatibility with scripts and software written for *nix (it had a complete GCC-based build toolchain, though you could also use MSVC, and was source-compatible with most portable *nix code).

It's still available, including the "tools and utilities" download that gives you basic shells and the like, but when MS released Win8.1 - which doesn't allow the POSIX subsystem - they also stopped funding the forums and package repo, so even if you can find the package files they're all getting more and more outdated.

Ed man! !man ed

[kuzb]

( obligatory, credit to: https://www.gnu.org/fun/jokes/... )

When I log into my Xenix system with my 110 baud teletype, both vi and Emacs are just too damn slow. They print useless messages like, ‘C-h for help’ and ‘“foo” File is read only’. So I use the editor that doesn't waste my VALUABLE time.

Ed, man! !man ed

ED(1) Unix Programmer's Manual ED(1)

NAME
          ed - text editor

SYNOPSIS
          ed [ - ] [ -x ] [ name ]
DESCRIPTION
          Ed is the standard text editor.
---

Computer Scientists love ed, not just because it comes first alphabetically, but because it's the standard. Everyone else loves ed because it's ED!

“Ed is the standard text editor.”

And ed doesn't waste space on my Timex Sinclair. Just look:

-rwxr-xr-x 1 root 24 Oct 29 1929 /bin/ed
-rwxr-xr-t 4 root 1310720 Jan 1 1970 /usr/ucb/vi
-rwxr-xr-x 1 root 5.89824e37 Oct 22 1990 /usr/bin/emacs
Of course, on the system I administrate, vi is symlinked to ed. Emacs has been replaced by a shell script which 1) Generates a syslog message at level LOG_EMERG; 2) reduces the user's disk quota by 100K; and 3) RUNS ED!!!!!!

“Ed is the standard text editor.”

Let's look at a typical novice's session with the mighty ed:

golem$ ed

?
help
?
?
?
quit
?
exit
?
bye
?
hello?
?
eat flaming death
?
^C
?
^C
?
^D
?
---

Note the consistent user interface and error reportage. Ed is generous enough to flag errors, yet prudent enough not to overwhelm the novice with verbosity.

“Ed is the standard text editor.”

Ed, the greatest WYGIWYG editor of all.

ED IS THE TRUE PATH TO NIRVANA! ED HAS BEEN THE CHOICE OF EDUCATED AND IGNORANT ALIKE FOR CENTURIES! ED WILL NOT CORRUPT YOUR PRECIOUS BODILY FLUIDS!! ED IS THE STANDARD TEXT EDITOR! ED MAKES THE SUN SHINE AND THE BIRDS SING AND THE GRASS GREEN!!

When I use an editor, I don't want eight extra KILOBYTES of worthless help screens and cursor positioning code! I just want an EDitor!! Not a “viitor”. Not a “emacsitor”. Those aren't even WORDS!!!! ED! ED! ED IS THE STANDARD!!!

TEXT EDITOR.

When IBM, in its ever-present omnipotence, needed to base their “edlin” on a Unix standard, did they mimic vi? No. Emacs? Surely you jest. They chose the most karmic editor of all. The standard.

Ed is for those who can remember what they are working on. If you are an idiot, you should use Emacs. If you are an Emacs, you should not be vi. If you use ED, you are on THE PATH TO REDEMPTION. THE SO-CALLED “VISUAL” EDITORS HAVE BEEN PLACED HERE BY ED TO TEMPT THE FAITHLESS. DO NOT GIVE IN!!! THE MIGHTY ED HAS SPOKEN!!!

Re:Ed man! !man ed

[countach]

Ha ha, but seriously all Programmers should know some basic ed.

Please tell me I'm wrong...

[msauve]

Don't all of these text editors require a GUI? I prefer something which can work with a serial/telnet/(basic ssh) console, without all the unnecessary overhead of a GUI. I like joe (which can reasonably emulate emacs/pico, if you want), but can deal with vi if I have to.

Obligatory xkcd cartoon

[Anonymous Coward]

          http://xkcd.com/378/

Even if you don't personally engage in editor wars, it's pretty funny. I'm afraid that the number of Slashdot articles best answered by an XKCD cartoon has remained surprisingly consistent.

Given that most of the tools in the mentioned article require a GUI to work from, and many of them are destabilized by their use of Java, I'm afraid that the article will remain aimed at GUI and web developers, not "real programmers". We who do real systems recovery or kernel level code development will continue to use "vi" for small tasks, "emacs" when we need full integration with source control systems or more powerful indentation..

Steep learning curve

[Anonymous Coward]

Yeah, right, dat steep learning curve. I've wasted years using UltraEdit, because I was told that vim was too hard. One friday afternoon I fired up vimtutor, and it took me the following weekend to learn vim enough to do my work as good as with UltraEdit. From that moment on, I've spent years honing my vim skills, following a very slow but rewarding learning curve.

I've been editing (plain)text for living for the last 15 years, and I doubt I'd ever get as dedicated, thorough and precise in my work without vim. All those self-proclaimed no-learning-curve, get-the-job-done editors are inferior, and one should use them only if they actually need to do some ad-hoc work, which they actually don't even want to do.

Pick a proper tool for your job, not a toy.

Re:Steep learning curve

[Darinbob]

In school we were given a one page sheet with vi cheat notes the very first day class started, and that was all the instruction we had, and we started using it that first day. No one had a mouse yet so no one could complain about the lack of point-and-click editing and so it was naturally assumed there would be some learning involved.

Vim makes it so much easier now as it actually comes with help built in.

But EMACS has butterfly mode...

[140Mandak262Jamuna]

http://xkcd.com/378/

Re:GUI = fail

[Anonymous Coward]

I see you're used to Linux boxes with X installed. *BSD doesn't necessarily have X installed and it would be highly unlikely on a firewall box. Also, sshd might not have X11 forwarding turned on.

Not to mention, it's actually nvi not vi or vim.

Re:There can be only one....

[sl149q]

No, you can teach us old Unix guys new tricks. Vim is a totally acceptable acceptable upgrade to vi. Just like bash is an acceptable upgrade to sh. And perl is definitely better than awk/sed.

We do draw the line at gvim though. And I've heard rumours of a new C like language that is object oriented... haven't tried it though.

Re:Try Sublime in 'vintage' mode.

[Marc_Hawke]

You're not supposed to close the windows. They just stay open all the time. (You don't even have to save them, it just keeps them up 'unsaved' the next time you come back. :w does work though, exactly as you'd expect.

Re:GUI = fail

[techno-vampire]

I've had to clean up my desktop after an upgrade didn't finish properly and I only had a CLI to work with. Knowing how to use at least one non-GUI text editor and having that editor installed already was a life saver because without it I couldn't have gotten the network up again and without that, I couldn't have installed an editor. Remote admin is one good reason to know how to work without a GUI, but it's not the only one.

Who else makes this mistake?

[rossz]

I have a few text files on my Windows box with :wq scattered around in random locations.

I used to teach Linux.

[attemptedgoalie]

My students hated that I made them learn vi. Why? Because if the graphics subsystem failed, or they had to go to single user mode, they had vi.

If they made it through my class alive, they could use whatever they wanted.

Re:I used to teach Linux.

[jtara]

If the graphics subsystem fails, or I have to go to single-user mode, I have nano.

WordStar rules!

The bottom line

[ccanucs]

So, - here's the bottom line. Almost nobody here agrees with the OP premise :-)

Vim and Emacs

[nuggz]

Personally I use vim and emacs, they can do everything those editors can, and much more.
Once you get over the learning curve, which I did, there is no reason to try the less capable editors.

There are only 4 editors

[russotto]

There is emacs. There is vi, for when some fool didn't install emacs. There is ex, for when the terminal is messed up. And there is ed, because it is the standard text editor.

Anything else is either redundant, or is a word processor with a text-only output.

Re:There are only 4 editors

[jd]

Sigh. Emacs is an operating system with text editing facilities.

Without Joe, I would have failed Linux

[swb]

Or taken a lot longer to sort it out and then move on to FreeBSD.

Joe seems very intuitive to me and has just enough power as a text editor to give you free range of config files and basic scripting or even a couple hundred lines of Perl. I've always found vi impossible; the command/editing modes never made sense yet Joe seemed to work "like normal."

I made an honest effort to master emacs, but it always seemed like effort and I always went back to Joe when I needed to get something done.

I actually went trolling recently for a win32 text mode version of joe (which I swear I used to have) but couldn't find one.

Re:Jed

[multimediavt]

apt-get? Who uses apt-get? Real men use make, make dep, make install!!!

Stop mentioning vi and emacs

[Art3x]

Okay, y'all can stop mentioning how vi and emacs do everything these do plus come preinstalled on Linux systems. From the article:

Two of most popular and powerful plain text editors are Emacs and Vim. However, we didn’t include them in this group test for a couple of reasons. Firstly, if you are using either, congratulations: you don’t need to switch. Secondly, both of these have a steep learning curve, especially to the GUI-oriented desktop generation who have access to alternatives that are much more inviting.

This is for people moving to a text editor from Word.

Re:There can be only one....

[Cederic]

And perl is definitely better than awk/sed.

No. People learn perl then think they can program. It just goes wrong.

Re:My Personal Favorite

[msauve]

I'dprefertheeditorstripthefileofallspacesnotusedforindentationwhenitsaves,becausespacesjustdon'tfuckingmatter.Samewithtabs,don'tusethem,justindentwithspaces.

Areyouserious?Whatlanguagesdoyouwritecodein,whichacceptthat?

screen real-estate !

[tuxidriver]

I have yet to see anyone comment on this...

One advantage of so-called stone-age editors like Emacs and VI is that they don't clutter the screen with useless junk like toolbars, menus, project side panels, etc. I've got Emacs setup on each machine I use such that each pane, running 2 across or 3 across, almost exactly fits the width of the code based on the maximum line length called out in the coding standard we follow (giving a few characters of margin). I want as much code on the screen as possible in as large a font as is reasonable (to reduce eye strain). I also remove as much clutter vertically so that I get as many lines of code on the screen as possible.

I definitely do not want my editor to clutter my screen with menu bars, tool bars, scroll bars, project side panels, cute little multi-line consoles, big status bars, etc. that take valuable space away from the actual code window. I use my editor 8 hours every day, if not more. I know the editor's commands. I use my editor to write code, I want to see the code, not screen wasting cruft.

Some GUI editors, such as JEdit, let you remove some of the clutter; however, I have yet to see any GUI editor let you remove all of the clutter to the extent possible (or default) with Emacs or VI.