Posted: May 19, 2012 8:03 pm
I suspect it's a case of whatever you grew up with. Incidentally, both of these text editors are principally Unix/Linux editors, but I suspect ports have been made to other operating systems.
In the case of vi, if memory serves, it started life as an attempt to make the even more rudimentary text editor known as ed a little more friendly to newcomers. The ed text editor first saw the light of day with the first ever operational versions of Unix, and it may be possible to find ed lurking somewhere even on modern Linux systems with GUIs, as a fallback in case you need to dive into the OS without the GUI running, and edit key system files to resurrect the system after someone's been futzing about with it.
When cursor-addressable terminals started to appear, sometime in the late 1970s, Unix programmers sought to take advantage of this, and thus set about producing a front end for ed. Somewhere along the way, an extended version of ed, called ex, put in an appearance, and it was decided to integrate the forthcoming front end with the new, enhanced ex version of the line editor. The end result was vi.
Since vi has been something of a standard amongst text editors on Unix systems since the late 1970s, it's hardly surprising that a lot of Unix/Linux programmers like it. It's what they first encountered when learning the dark arts of Unix shell scripting and C programming, and as a consequence, they've come to regard it as a family friend, so to speak.
In the case of emacs, this was originally derived from a mainframe editor called TECO, about which much has been written with respect to the hilarity of using this 1960s-vintage product. TECO was the classic piece of 1960s mainframe software - unforgiving, littered with counter-intuitive commands and command sequences, and generally a pain in the arse to use. The emacs editor began life as a set of TECO macros, which proved to be so popular amongst benighted TECO users, that they demanded a proper, native implementation, which duly emerged. The ability to automate editing sequences with custom macros you can define yourself, as well as a small army of existing macros to perform just about any editing task you can think of, makes emacs popular with those who grew up with it. Anyone whose programming history revolves around the VMS operating system, or various DEC minicomputer operating systems of 1970s vintage, will know all about TECO and emacs. There was even an implementation of emacs for the Amiga computer in the 1980s, based upon the MicroEmacs project. Incidentally, one of the interesting features of this editor, is that its development history is intertwined with the Lisp programming language, and people whose careers were based upon Lisp projects, are likely to have been emacs users and fans from early in their careers.
Where emacs loses out, is that it's restricted with respect to file size. Ask it to edit a file bigger than 512 MB, and it curls up and dies. vi, as far as I'm aware, suffers no such restrictions, because it uses Unix standard filestream operations, which don't have any intrinsic limits on file size, other than those imposed by the CPU architecture upon which the Unix/Linux implementation is residing. So, for example, you can expect a 4 GB file size limit on systems with 32-bit CPUs, unless the version of Unix/Linux resident thereupon makes proper use of block filesystems, in which case on a 32-bit system with a 1K block size, the maximum file size is actually 4 TB. Where emacs scores is that it is practically infinitely extensible, all you need to do is figure out a way of implementing your desired features as a macro, and hey presto, emacs will implement that feature, without needing a major rewrite of the editor. Also, emacs had interactive help facilities and a built in tutorial from the start, features that were to be ruthlessly copied by other text editors that came after it. However, one feature that skews a lot of viewpoints is this: vi is free, and bundled with the operating system, whilst emacs (unless you obtain the GNU version) is a commercial product that can cost you a tidy sum of money.
In the case of vi, if memory serves, it started life as an attempt to make the even more rudimentary text editor known as ed a little more friendly to newcomers. The ed text editor first saw the light of day with the first ever operational versions of Unix, and it may be possible to find ed lurking somewhere even on modern Linux systems with GUIs, as a fallback in case you need to dive into the OS without the GUI running, and edit key system files to resurrect the system after someone's been futzing about with it.
When cursor-addressable terminals started to appear, sometime in the late 1970s, Unix programmers sought to take advantage of this, and thus set about producing a front end for ed. Somewhere along the way, an extended version of ed, called ex, put in an appearance, and it was decided to integrate the forthcoming front end with the new, enhanced ex version of the line editor. The end result was vi.
Since vi has been something of a standard amongst text editors on Unix systems since the late 1970s, it's hardly surprising that a lot of Unix/Linux programmers like it. It's what they first encountered when learning the dark arts of Unix shell scripting and C programming, and as a consequence, they've come to regard it as a family friend, so to speak.
In the case of emacs, this was originally derived from a mainframe editor called TECO, about which much has been written with respect to the hilarity of using this 1960s-vintage product. TECO was the classic piece of 1960s mainframe software - unforgiving, littered with counter-intuitive commands and command sequences, and generally a pain in the arse to use. The emacs editor began life as a set of TECO macros, which proved to be so popular amongst benighted TECO users, that they demanded a proper, native implementation, which duly emerged. The ability to automate editing sequences with custom macros you can define yourself, as well as a small army of existing macros to perform just about any editing task you can think of, makes emacs popular with those who grew up with it. Anyone whose programming history revolves around the VMS operating system, or various DEC minicomputer operating systems of 1970s vintage, will know all about TECO and emacs. There was even an implementation of emacs for the Amiga computer in the 1980s, based upon the MicroEmacs project. Incidentally, one of the interesting features of this editor, is that its development history is intertwined with the Lisp programming language, and people whose careers were based upon Lisp projects, are likely to have been emacs users and fans from early in their careers.
Where emacs loses out, is that it's restricted with respect to file size. Ask it to edit a file bigger than 512 MB, and it curls up and dies. vi, as far as I'm aware, suffers no such restrictions, because it uses Unix standard filestream operations, which don't have any intrinsic limits on file size, other than those imposed by the CPU architecture upon which the Unix/Linux implementation is residing. So, for example, you can expect a 4 GB file size limit on systems with 32-bit CPUs, unless the version of Unix/Linux resident thereupon makes proper use of block filesystems, in which case on a 32-bit system with a 1K block size, the maximum file size is actually 4 TB. Where emacs scores is that it is practically infinitely extensible, all you need to do is figure out a way of implementing your desired features as a macro, and hey presto, emacs will implement that feature, without needing a major rewrite of the editor. Also, emacs had interactive help facilities and a built in tutorial from the start, features that were to be ruthlessly copied by other text editors that came after it. However, one feature that skews a lot of viewpoints is this: vi is free, and bundled with the operating system, whilst emacs (unless you obtain the GNU version) is a commercial product that can cost you a tidy sum of money.