Editor Wars

As a rule, I try hard not to get sucked into religious wars. You know, Coke vs Pepsi. C++ vs Java. Chrome vs Firefox. There are two I can’t help but jump into: PC vs Mac (although, now that Mac has turned into Unix, that’s almost more habit than anything else) and–the big one–Emacs vs vi.

If you use Linux, Unix, or anything similar, you are probably at least aware of the violence surrounding this argument. Windows users aren’t immune, although fewer of them know the details. If you aren’t familiar with these two programs, they are–in a way–text editors. However, that’s like calling a shopping mall “a store.” Technically, that’s correct, but the connotation is all wrong.

Like most religious wars, this one is partly based on history that might not be as relevant as it used to be. Full disclosure: I’m firmly in the Emacs camp. Many of my friends are fans of vi–I try not to hold it against them. I’ll try to be balanced and fair in my discussion, unless I’m talking about my preference. I don’t have to be fair when it comes to my opinions. Just to be clear: I know how to use vi. My preference isn’t based out of not wanting to learn something new.

The Big Differences

Superficially, there is one big difference between the two editors. Vi has the concept of a mode. Most commands are just ordinary letters (for example, the I key enters insert mode). The problem with that, of course, is that if you start typing in the wrong mode you either get command characters in your file or you issue lots of random commands.

Emacs works more like a normal text editor. When you type normal characters they go into the current file. Commands use special prefix characters like Control+X or Escape. Sure, you might have a normal letter after a prefix (Control+X C, for example) but that’s only for the short duration of the command.

The Case for Vi

The best argument, in my opinion, for vi is that it is fairly lean and it is on just about every Unix-like system you’ll ever encounter. There are other “standard” editors, but they are not screen-oriented and are very painful to use. That’s why I know how to use vi.

You’ll often hear the argument that vi is lean and Emacs is bloated. That’s somewhat true, although modern versions of vi (like vim) are not very skinny, either. Generally, vi starts faster than Emacs, all other things being equal (although you can bog down either one). However, there’s a reason for that, as you’ll see in a minute.

The Case for Emacs

If it were just the fact that Emacs always lets you type plain text, it really would be just a matter of personal preference. However, I have noticed that there are two things people who are passionate about Emacs have in common. First, they are people who either predate widespread use of X11, or that could not use it for one reason or another. Second–and this is a secondary effect–they tend to be touch typists.

The first reason is because Emacs is a text-based window manager. Sure, the most common thing to have in a “window” is a text editor, but Emacs can also display file managers, games, e-mail clients, web browsers, and plenty of other window types. You can even run a shell inside an Emacs window. The most recent version even has a WebKit-based browser. You can watch a YouTube video from within Emacs. If YouTube doesn’t excite you, maybe you’d be more impressed by opening GitHub, Google, or Hackaday.

This leads to the popularity, I think, among touch typists. Being able to create, manipulate, and switch windows without taking your hands off the keyboard is very valuable to fast typists.

Granted, today, you don’t need a text-based windows manager. You could use GNU screen, although it works a little different. But most of us use a GUI desktop now and it is less important to have Emacs manage windows for shells, browsers, and so forth. Even if you want keyboard-driven window management, there are solutions for that too.

If you are a hardcore hacker, Emacs has one other advantage: it is fully programmable using a version of LISP. That’s a dual-edged sword. On one hand, Emacs an do anything. On the other hand, you can go deep down the rabbit hole making custom set ups.

So What’s the Answer?

So maybe it really is a matter of personal preference. But to me, its still Emacs all the way. One thing I’ll point out: It is pretty easy to make Emacs act very much like vi, but the reverse isn’t possible in any meaningful way. Of course, if you are under a certain age, you probably use some GUI editor like sublime or Eclipse and are scratching your head that an editor war even has its own Wikipedia page (not to mention the flurry of comments this post will probably launch).

If you do log into an embedded Linux system that doesn’t have enough horsepower (or connection bandwidth) to support a GUI, both of these editors can help you be more productive. However, Emacs can also give you some measure of multitasking windowing, even over a non-GUI SSH or telnet connection.

177 thoughts on “Editor Wars

        1. …and you get quite a few karma points for that. Thank you. Unfortunately, you don’t always have the extra space, and since vi comes with busybox and nano doesn’t (to those with spare time: *hint* *hint*)…

          1. Wow! I just looked at e3. (It has moved around a bit, so I’m not sure this is the latest home: https://sites.google.com/site/e3editor/)

            What an incredible achievement. On my Linux latpop, the binary is ~13k (compare to nano, which approaches 200k). The author certainly packed a lot into an incredibly small space.

            Unfortunately, there are some practical factors that make it hard to become the “installed already” editor.

            — It’s written in assembler, so porting is non-trivial.
            — The only fully-supported platform is x86.
            — It’s not currently available, even as an add-on package, for OpenWRT or Raspbian.
            — It looks like it’s been dormant for ~7 years, and mostly dormant for ~10 years.

            Still, again, wow! An incredible piece of work.

        2. E3 sounds interesting. A brief search shows that it is written in x86 assembly, so that would be a no-go for Openwrt. However, I also see a reference to a C version. Does anyone have a link for the up-to-date C version of e3? I’ll attempt to package it for Openwrt/Lede if there is a working site/official download link. Alternatively, this sounds like a great project for someone (not me) to fork and “make great again.”

          1. IIRC, the e3 man page says the C version only supports the Wordstar stuff. I used Wordstar a million years ago (on my Osborne 1), but it’s not really a “must have” for me these days. :-)

          1. Hmm. Maybe I pruned my post a bit too much…

            What I *meant* to say was that nano doesn’t require workarounds and/or contortions for keys, and key placements that are nonexistent or have long since been repositioned on even vaguely modern keyboards.

            And I use QWERTY.

        1. I use HJKL cursoring in vi (as I have done for over three decades) and until now wan’t aware these keys were obsolete. Do you not have them on your keyboard?

          1. I have to say that as a Dvorak-keyboard vi user, HJKL is a bit awkward, but I didn’t take long to get used to it. Even the nethack diagonal keys aren’t that bad in Dvorak. All that said, vi was definitely “tuned” for QWERTY. Worse than any of that is the Unix “ls” command, which is quite comfy in QWERTY, but becomes an awful same-pinkie reach in Dvorak. I should alias dir to ls, but my anti-DOS genes won’t let me.

          2. Ha, Just Kidding, LOL

            (Seriously, what about this suggests cursor movement, except for maybe H reminding you of ^H reminding you of backspace? I know the ADM3a you used during the US civil war has those arrows painted on them, but not so much any more. Whereas the emacs keybindings are completely mnemonic is you happen to speak English and think of the right words. :-))

          3. WJCarpenter: I prefer to not have to think about language when moving the cursor around on the screen :D
            (For vi, even though the up and down keys may be arbitrary, the key for moving left is the leftmost of the four vi cursor keys, and the one for moving right is the rightmost. At least for me, this is a much simpler shortcut to make than going over words!)

        2. I suspect you mean keyboards with Ctrl above left Shift. IBM moved Ctrl out of that position on the RT PC (1985) and the second iteration of the PC AT (1986) as just one volley in the company’s war on Ctrl-A through Ctrl-Z. One small example: Windows 1.00 had a few Ctrl-plus-letter-key “shortcuts”; M’soft showed it to IBM, and they disappeared in the first public release (version 1.01). Not everything IBM does is an advancement in the field.

    1. I like JOE myself. I started off with a C64 but soon moved on to CP/M and MS-D0S then to using Trubo Pascal. JOE uses the wordstar/turbopascal binding and it is light and fast. For development VS and Eclipse CDT.

      1. When I first installed Linux in 2001, I started using JOE because it could be invoked in different ways to emulate different editors. But other than trying the others, I’ve just invoked it as JOE.

        For a lot of purposes, you don’t need a complicated editor. When I had a Mac LC (right up to the switch to Linux), I git by with a desk accessory editor for just about everything. I could run vi or emacs, or a “wordprocessor”, but for much f wht I use, it’s overkill.

        Of course, I also use pico, which I guess is now nano. I’ve used that since August of 1996, when I started using pine, the mail/news reader. It’s part of the package. Realistically, JOE and nano/pine are bout the same and I should use just one of them, but somehow I am able to adjust rapidly between the two.

        Michael

        1. Pico is a separate package from nano. IIRC, pico is bundled with pine or the like(been a while, these days I usually just “ln -s /usr/bin/nano /usr/bin/pico” and am done with it but there was a time I used to build pine just to get pico.

      2. Same here. I still have a muscle memory for the Turbo Pascal and Wordstar keybindings after all these years, so I tend to use Joe as my editor on Linux boxes. But also got a survival-level knowledge of virus as most sysadmins does.

      3. I’ve spent way too much time with the Borland IDE when I was in school that Joe is the only thing that seem natural to use… Even if Emac is way more powerful, Joe got all I need with commands exactly where I remember them…

    2. I a fan of nano too but I’d had issue using it over a serial port. The problem being MobaXTerm uses ctrl X to close the connection. The same combination used to quit nano…….

      Has any one found a work around for this?

    3. I’m glad to see this here. Nano is my go-to. I only know enough about vi to save my butt on systems that don’t have nano installed and can’t (like if you need to edit a file to set up networking before you can hit the repos). It has made me feel like a poser but I haven’t yet had sufficient reason to invest enough time in emacs to get over the learning curve.

      1. I too am glad to see this here. I find vi extremely confusing to use. you’re either in insert or command mode. I want to be in neither, I want to be in normal text entry mode where i can use my cursor keys to move around as I would in a word processor and i’m ok with nano not being not quite as “powerful” as vi with it’s billion unintelligible commands. on the other hand, EMACS is pretty cool, but it’s more of an OS UI layer than an editor. I don’t need to run games, browsers, etc. when I just need to edit a config file, or write a quick note…

        1. “vi has two modes: Beep mode where every keypress simply makes a beep, and invisible corruption mode where every keypress does something to your file off screen.” used to be posted above my desk.

          Then again I use BBEdit anyway, use FUSE SSHFS mount our linux boxes…hell I use BBEdit to write my Powershell scripts..

    4. Some time around 2003, I recall the frustration of getting stuck with only vi when attempting to perform Linux installations. Drove me mad, since install disks often didn’t have the man pages, so I couldn’t even lookup the vi shortcuts. And often it was to edit the network config, so I couldn’t lookup the vi shortcuts online either. It was such a relief when distros started including nano on install disks! There were times I tried to learn vi, but it seems so arbitrary and unintuitive. 99% of the time all I need is a simple, plain text editor.

      1. Vi cheat sheets exist for a reason, there are plenty out there to be had, print one out and hang it up near your monitor. Perhaps even keep one as an image on your phone for reference on-the-go.

        I personally prefer nano and emacs to vi, as I find the mode switching and control keys cumbersome in vi compared to nano and emacs. If i need or want something more than what nano offers I go to Emacs (Which I used long before I ever touched nano.) There are situations where only vi is available.. for those situations a vi cheat sheet can prove invaluable.

        A good text editor (or any program for that matter) should be relatively intuitive and should not take ages to get used to. While Vi is a powerful editor, intuitive it is not. If you’re willing to sit down and spend a lot of time forcing yourself to get used to it- it may just prove beneficial. Or it might not. However, when one is busy trying to get something work related done, fighting with cumbersome tools is the last thing they want to do. As with any tool, the more you use it the more skilled you become with it. For many- myself included, it just isn’t worth the time and effort.

    1. Just because an article is impartial doesn’t mean it will not seem to endorse one over the other. Any truly honest comparison is just bound to show that vi is just emacs’s little bitch. That’s just how it is. Sorry!

      1. Ha, that was definitely true for me a million years ago. There was a time in command-line days when there was a pattern for tools to toss you into your “favorite editor” to write a comment or whatever. The default tended to be vi. So the first information about vi that I learned was how to quit.

        I find that non-intuitive for both vi and emacs.

  1. No comments? Really? Where are the pitchforks? But seriously, I’ve always been a vi person, mostly because it’s what I first used when learning Linux in 91, and I’ve never had a need to change. I’m not evangelical about it, it’s just that I never learned how to use Emacs, and vi is like a weathered baseball glove to me, familiar and well worn.

  2. Vi’s duplication and semi-macro functions, creating small functions as you type, to manipulate what you’re typing in, are very useful for writing code. And since you’re a programmer anyway Vi’s way of working will suit you. That’s ignoring actual macros.

    What’s nice about Vi is the grammar is sortof universal. You can think “ahhh, what if I type xxx” and it works! You can apply it’s little language of concepts, inserting and deleting, repeating, words and lines, and combine them most ways you can think of. Very handy for code, which tends to be quite repetitive in some parts.

    I probably wouldn’t write a novel in Vi, but that’s not what it was invented for.

  3. You can’t really argue that Emacs is for touch typists as if vim isn’t. The primary reason I use vim is the fact that I don’t have to use a mouse, yet I can easily move around and edit a document.

    1. You don’t have to use a mouse with emacs either. I also think the touch typists thing is weird. I use emacs for the ease of multiple file editing and especially for the regex search and replace.

  4. Darn… I was kind of hoping for a battle to see which Editor can edit better (post an article with the fewest wrong words, misspellings, grammatical errors, and content errors). :)

        1. RIght. Emacs is short for “editor macros”, which was originally a set of macros for TECO. Vi was written by Bill Joy when he was at Berkeley working on what eventually became BSD Unix.

    1. At least sources still exist for EDT (see recent character set discussions on comp.os.vms). TECO was VESTed for Alpha, then again for Itanium. I wonder if they’ll translate it again for x86.

  5. If you are going to do systems administration, you need at least a survival level knowledge of vi, it will e on any system you need to manage, while EMACS will not be.

    for writing code or other tasks, install whatever you want on your workstation, and don’t complain to others about what they choose to use.

    1. I very much agree; I use Emacs for all my coding, mostly because when I first started using editors, I came from a GUI environment, and found XEmacs much quicker to pick up. That doesn’t really matter to me much anymore, but I have two decades of training my muscle memory on emacs key combinations, as well as setting up dev environments, so switching would be ridiculous.

      However, vi is invaluable in system administration tasks (visudo, as just one small example), and I use it for minor edits all the time (due to its near instantaneous launch time).

    2. So, I’ve heard that argument, and every time I hear it, I remind them of the TRAMP facility which lets me edit remote files in Emacs over a variety of protocols. If they don’t believe me, I show them then and there.

    3. I must add that I am fluent int vi too, more than at “survival level knowledge”.
      But those little admin changes and additions to configuration files, I more often do them using sed.
      Why?
      Because so these are easier to document: no need for prose text to ambiguously describe what has to be done in the editing session.

    4. When I first started using Linux (Redhat 1.X days) it came with both vi and emacs. There was something funky with the termcap settings though and backspace only worked in emacs. That made using Vi so frustrating!! Chosing Emacs to invest my time in learning was a no-brainer.

      Now any editing of scripts just to get to a good startup point stuff can be done in nano or pico. Then it’s easy to install emacs to get the real work done. What is the point of Vi?

      1. The former physicist in me shakes his head at “pencil”. Was taught in school to never erase, but just to put a line through erroneous entries, for everything is data (including known wrong info).

  6. I must admit that I have recently gotten into the habit of using atom instead of vim (Not that atom is that great, especially not for large files). It is just as convenient to open as vim/nano/emacs from a shell. I rarely use macros for anything and besides that I can’t really see what vim offers over something where you can actually move the cursor with your mouse, don’t have to memorise all commands etc. But theres always that case where all you have is a shell, so vim will never die im sure! Never really bothered with emacs, maybe that was a mistake?

  7. The problem I’ve always had with editors that make very heavy use of keyboard commands is that more often than not my Swedish keyboard layout will screw me over. I love Sublime Text for example but a lot of commands just don’t work for me so I still have to go menu hunting, very frustrating.

    1. I would suggest that if you will be coding anything other than a qwerty is going to be hard given that most code is in some pigeon English (yes, embedded text will likely be in whatever language you use) and, that being the case, it would make utter sense to swap your whatever keyboard for a qwerty. 20 years ago, before plug/play popularity and PS/2 was king, this would probably have required a reboot. With USB it makes perfect sense.

  8. I tried both vi and emacs, and came to the conclusion that they don’t provide ME with any more feature than most editors. I used to use gedit (*) and is now working with Kate (with a terminal for doing stuff). I work on a codebase with millions of C lines. Maybe my situation does not apply to the others, but when I code, I spend most of my type not actually coding, but rather thinking. Thus I don’t care about a super-powerful editor, I can’t even touch type, and I don’t care :) And yes, I am under a certain age ;)
    Otherwise I like nano for simple things, very handy and it even has syntax highlighting now!

    Since I cannot resist the troll, I have a note. UNIX philosophy is about having lots of small program that do one thing but do it well. Emacs does everything, including coffee. Thus emacs is very unix-unlike :-p Unless one considers emacs as an operating system…

    (*) back in the days when it still had features

  9. I feel pretty passionately in favor of vim. Thanks for the article though, it finally gave me some insight into the mindset of an emacs enthusiast.
    I think vi/m would have more followers if it shipped with reasonable defaults. There is not surer way to extract a string of expletives from me then logging into a fresh system and my arrow/del/backspace keys not working right in vim. It makes no sense whatsoever to ship as if the edge cases are the norm.

  10. I’ve been a vim user for 20+ years. You might be surprised to learn that I used it quite heavily when I worked for “that Redmond company”. That being said, I tend to use it for small code changes and config files. For long coding sessions, it’s worth the time to start up an IDE to get easier navigation, auto completion, debugging, integrated compilation, etc.

  11. I’ve never understood how this is such a serious point of contention in the world, since it should impact so few people. These two editors are the best options for computer programming with syntax highlighting in a non-GUI environment … which isn’t really a thing any more.

    If you’re a sysadmin or embedded engineer or someone else who regularly needs to edit complicated files on a system without a graphical shell, you actually have skin in the game. Pick a favorite and be proud, because you’re in a small minority of people without a better option.

    If you just need to tweak configuration files, they’re both a huge pain in the ass. Pico, Nano, Joe, Notepad, Notepad++, and TextEdit are all much better options depending on your environment.

    And if you’re doing serious programming on a real computer, whatever is wrong with using a GUI? VI(M) and EMACS are extremely opaque because you have to memorize commands to make any headway. Meanwhile, every windowed program ever still has shortcut keys to pretty much every function. Heck, you can even make a case for GUI EMACS. But the main thing is having buttons for rarely-used functions (even if you don’t use them), having the option to move the cursor with your mouse (even if you don’t), and having a lot more detail available in displaying information. There’s nothing more perverse than using a perfectly good GUI to open a terminal to open an outdated program that doesn’t even have the option to use half your peripherals.

    1. How comes that Vim and EMACS and their package database are still developing ? Why peoples still spend so much time to learn to use them at their full potential ?

      You should be ashamed to show how much you’re ignorant. I bet your laziness and lack of curiosity never got you past the integrated EMACS tutorial.

      I hope it’s a troll.

    2. As a 20+ year veteran of *IX/*UX system administration I can tell you that the biggest reason I’ve seen for the choices of VI/Emacs versus anything else is one of corporate culture. Most of the people I work with tend to be a little older. And most of those old folks in my org started with with version 2.4/2.5 of Solaris. Couple this with an internal training “University” for our devs at that time, and vi is what happened to “stick” in our org. Moving forward there was always a variant of vi available regardless of OS flavor, so it was, and is, just part of our culture. Sure we’ve had younger guys come in and want the “new hotness”, and if it wasn’t a pain to deploy, we would make it available. But again, due to the culture, half of those new folks would end up switching to vi and not hating it.

      There is also the issue of remote connections. We have people scattered throughout the US and we mostly deal with healthcare customers. Sure they can code remotely and upload and test, but having pieces of our source code scattered around on people’s laptops presents legal and security issues. So we want our people to code on dev systems in our data center. Talk about PITA, imagine having to reliably provide remote access for whatever flavor of the month GUI editor our devs want to use across a myriad of *IX/*UX systems. Nope, they can use an ssh terminal and we’ll try to accommodate them on a CLI editor.

      TL;DR – I assure you that our systems are “real” and and “serious programming” gets done with vi (and the occasional, emacs, nano, pico, joe, etc)

    1. My favorite on Windows as well, on Linux I use its cousin SciTE.

      Whenever I have to use a CLI-based editor, I like nano. Very simple but it does the job. vi’s ridiculously unintuitive interface of modes and key actions drives me nuts, it feels like a program you’d expect to find on a 6ft tall computer with visible tape reels on the front, and that there should be a poster like this somewhere in the room showing you how to use it.

      Emacs is the “everything INCLUDING the kitchen sink” approach…maybe my uses are too mundane but I have no need for that kind of thing.

  12. I don’t try to evangelize emacs to anybody these days, though I’ll help them along if they ask me about it. But I do sit there with a smirk when someone comes along telling me how cool Notepad++ or similar things are because they have syntax highlighting or you can write extension or some other favorite feature. Gee golly.

    If an editor doesn’t have regex-based incremental search, it puts a serious crimp in my productivity. Not kidding.

    1. Notepad++ has regex searches. I never used emacs. Started with vi and am quite content. If I am remoting to a UNIX-like via microspasm windows then I will likely use n++ to get it together then send it over…but I also use gygwin and, oddly, never use n++, always vi.

      1. There’s one problem with regex searching in Notepad++ (and SciTE), it can’t handle any searches involving the \r and \n characters. It’s a limitation of the Scintilla library, it searches one line at a time, stripping out any newline/return characters first.

  13. Careful! Vi can be addictive. I got hooked on it, and now every time I try a new editor, one of the first things I do is install a vi mode plugin. I just don’t feel at home without it.

    Of course, there’s probably some fairly deep psychological stuff at play here. For some people, vi’s modal editing is extremely natural, almost like having a conversation with the editor. I’d imagine that for some others, the “in-band signaling” of using the same keys for typing and for editor commands is terribly unintuitive, but they have the coordination and flexibility to juggle four (or more!) modifier keys in emacs.

  14. The number of people here going with nano is downright disturbing…

    I’m a vim girl, but emacs has evil mode so I don’t really care too much so long as its not nano.

    Anything but nano.

    1. It’s anything but Vi for me. I’ll use nano to get the computer up and running to a point where I can download and install emacs. But.. I may have a bit of an irrational hatred for Vi stemming from the days when it came on every Linux install disk configured in such a way that the back space and possibly arrow keys do not work.

  15. I started out on the Mac in the early 90s. All I want to do is edit some damn text without having to memorize the keyboard layout of a 70s dumb terminal. Modal editing feels like a 20-year step backward from even TeachText.

    In a terminal I tend to use nano/pico. On the GUI, BBEdit and Notepad++ suit me just fine.

  16. I think the main difference between the two is what you use the editor for. Personally, I’m Emacs all the way and on any OS. However, this is because I use it for sysadmin, WebDev, PIM (org-mode!), programming, notebooks…everything. Using a single tool that can handle it all, be customized to “link” those differing modes of work together, and allows me to keep my hands on the keyboard and not bouncing between keyboard and mouse…invaluable. Yes, it took time to learn, but now the time saved has far surpassed the learning curve.

  17. vi is a useless passion. For small editing tasks, such as editing configuration files, ed is your best bet. It exists on literally every version of Unix, it’s small and fast, the command set is uncommonly sensible and easy to learn, and it even works on hard-copy terminals. The only vi command I know is :q!

    Of course, it’s a line-oriented editor. Back when I was writing large Fortran programs on a PDP-11 under RSX-11M, I preferred TECO. The first EMACS-like editor I used was FINE (FINE is not EMACS) written by Mike Kazar for the PDP-10 running TOPS-10. I moved on to Gosling’s EMACS (later, Unipress EMACS) on a Vax 11/780 running 4.1BSD Unix, and then to Gnu Emacs, which I’ve used ever since.

  18. “edlin”! OK, I’m just joking, but when I was an undergraduate, my FORTRAN instructor had us create a line editor as our semester assignment.

    Much later, when I went on to teach intro to scripting at a private college, I replaced notepad and wordpad on all the windows computers with VI for Windows.

    Today, as a senior *nix admin who often interviews candidates for junior positions, one of the 1st questions I ask is “How do you save a file in your favorite editor?” + points for answers relating to VI, EMACS, nano, or joe, – points for anything “alt-f-s” or similar.

  19. I’m a vi guy. Did the emacs thing for a while about 20 years ago, but once I started doing short consulting stints, vi was the way to go. For sysadmin work, you pretty much had to know vi to at least get the network interface up.
    I found it annoying when doing my first git commit and realizing it defaults to nano…

  20. “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!”

    “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!!!!!!”

    http://c2.com/cgi/wiki?EdIsTheStandardTextEditor

  21. Both VIM and Emacs are great cli editors. I prefer VIM but have much respect for Emacs. As far as graphical editors go, Atom is a great free & opensource code editor. Brackets is another great free but closed source editor. Also let’s not forget Sublime.

    BTW Gedit & Kate/Kwrite can make versatile code editors as well.

  22. I started working with vi back in 1980 on a terminal based Unix system, using either VT100 or ADM3 serial terminals. On windows, you could purchased the MKS toolkit from Mortice Kerns Systems, which included a vi version plus a lot of Unix command line tools. I don’t know if MKS is around anymore; but, Cygwin has pretty much done everything they had and more as a free download.
    In the interim I ported versions of Elvis and Stevie to several real time operating systems, since they were better than the supplied editors and were something I was used to working with.
    On my Linux systems I still use vi at the command line, usually via Ssh and I use vim on Windows.
    I have nothing against emacs; but, it just comes down to what I was used to, and getting to old to learn something new that may or may not offer any features I need.
    While vi does not support multi tasking, you can export data to a Unix command and have the command output placed back into your document. This can be handy if you want to do something like sort a list in your document, embed the files by name from a directory, etc.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.