Vi or emacs?  I prefer acme (under Plan 9, or ported to Unix) or TextMate
(under Mac OS X).

This is the great text-editor holy war item.  Best to testify in the name
here....

80 responses total.

 vim for me, unless I'm doing something very specialized.  

pico/nano because I'm lazy and haven't learned very much vi. :)

Remmers had a great post about this subject on M-Net; I'm hoping he will
repost that with context here.

Vim. I do need to learn Emacs sometime, if only to take advantage of the
Emacs-like features of the Bash shell, but I've already got an operating
system; I don't want one in my editor.

Here's a blog post on switching from emacs to TextMate on the Mac:

http://www.oreillynet.com/mac/blog/2006/05/emacs_est_mort_vive_le_textmat_1
.ht
ml

The best line in it (regarding Emacs LISP): "Dont get me wrong, being fluent
in a programing language from 1958 gets me plenty of trim at parties."

Yea!

I prefer vi, because I am guaranteed to have the same base functionality
on UNIX, BSD, Linux, etc. I also like the fact that I don't hurt my
wrists trying to hold Esc+Shift+Control+K to make things happen. I also
don't like waiting longer for a text editor to start up than I do for a
full-blown GUI application like Gnumeric. Most of all, I learned vi
first, so I have an inherent bias towards it.

 There's apparently no truth to the canard that emacs was named as it is
 to be an acronym for "escape-meta-alt-control-shift".  But it should have
 been.
C-x C-c

Heh.  Emacs was actually originally a set of macros for the TECO text editor
on the DEC PDP series of machines.  It stood for Editor MACroS.

"joe" for me, because I'm from a CP/M background.

Does EMACS have Ctrl-S and Ctrl-Q bound to functions in the
software?  If so, I think that qualifies Stallman as a
lunatic (in case anyone was left wondering ;-)

 re #9:  (regarding XOFF/XON -- nothing is bound to ^S, ^Q by default,
 so far as I know.  But it's not uncommon for people to customize emacs
 with a site-specific customization file that binds functions to those
 keys.  Obviously, though, that doesn't work well via a terminal session.

I use vi because I do UNIX/Linux based editing so infrequently that I'm not
going to be learning something better, and knowing vi is fairly transportable
to the various *x flavors.

To be fair, vi has its quirks as well. The last time I drank with a
friend from UT Austin, he put it very well: "vi has two modes: one which
beeps at me, and one which mangles my file". A mode-oriented editor
either requires you to set a bit in your brain for which mode it is in,
or be prepared to hit Esc button before doing anything to know with some
certainty which mode you are in. 

Oh, and be prepared to retrain your br@n3 when coming back to windows.
Apparently Notepad does not care much for trying to end a file by typing
"Esc :wq", though the version I had when I had that trouble was nice
enough to beep at me, just like vi. 

 In any vi made in the last 10 years or so you can probably ":set showmode"
 to fix the awkward problem off not knowing when you're in insert mode..

Re #10:  In just about every version of emacs I've used, ^s and ^q are 
bound to the functions "isearch-forward" (incremental search) and 
"quoted-insert" (for inserting control characters and such in the 
buffer), respectively.  I can't recall ever having a problem with them 
working correctly in an emacs terminal session.  I'm sure emacs 
accomplishes this by putting the terminal in raw or cbreak mode.

Stallman has a lengthy explanation somewhere as to why he thinks this is 
appropriate and that binding ^s and ^q to XOFF and XON is "wrong".

I posted a lengthy response on M-Net recently about vi vs. emacs and why 
I prefer the latter for source code and some other kinds of highly 
structured text.  Will repost it here eventually, possibly shortened.

It's not a question of binding ^S and ^Q to XOFF and XON,
they /are/ XOFF and XON by virtue of being DC3 and DC1!  If
you're on a link that's using hardware flow control and
ignoring software flow control, it's no problem.  If you're
on a link that requires (or respects) software flow control,
you're screwed.

 You're not getting the meaning I intended -- perhaps I was unclear.
 What I meant was that (presumably because of their flow control functions)
 emacs doesn't by default bind anything to ^S or ^Q.  But some sites choose
 to override the defaults, especially if they're mostly editing in an 
 environment where serial flow control is not a big issue for users.
 That can, of course, create problems when people are logging in remotely
 over some types of connections.  None of which is RMS's responsibility..

Re #16: "emacs doesn't by default bind anything to ^S or ^Q."

Maybe I'm misunderstanding you, but on the face of it that's contrary 
to all the documentation I've ever seen, e.g. this from the tutorial
that comes with GNU emacs:

    The command to initiate a search is C-s for forward search, and C-r
    for reverse search.

Or this, from http://www.phys.unsw.edu.au/~mcba/newunix/node6.html:

    One problem with emacs is that the author, Richard Stallman, has
    used C-q and C-s as commands. The difficulty with this is that
    these two characters are used by most terminals and computers for
    flow control (i.e., if a computer receives a C-s it stops sending
    output to the terminal until it receives a C-q). There are two ways
    around this problem...  [The author goes on describe a fix to the
    problem Andy describes in #15.]

Besides ^S for forward search, emacs uses ^S as parts of other commands,
e.g. ^X^S for "save file".

 I stand corrected, then.  And yeah, that's a pretty darn stupid thing to do.

I use vi unless I'm on a terminal that messes up my arrow keys. Then I use
pico. I'm not sure if it's really vi or vim that I use, but the shift-v thing
to highlight text, which you can then save in a separate file and later bring
back just by using :r is pretty handy in a terminal. Also the auto-indentation
stuff is nice for C, and the language-specific color coding is pretty handy,
but I think most of the editors have that feature by now. . .

All of that is vim. (Strict vi doesn't allow arrow keys at all, but most
variants have added that.)

 Autoindent has been an option in VI for as long as I can remember.
 It's not very smart about it, though..

Re #20: "Strict" vi has supported arrow keys since the 1980s when 
properly specified in the termcap.  Given the terminals and slow 
connection speeds of those times, they often didn't work very well.

Re #21: In vi, doesn't the "autoindent" option simply consist of 
indenting each line the same amount as the previous line, with special 
keys (^T, ^D) to increase and decrease the indentation level?  Right - 
not smart.

Smart indenting requires teaching the editor something about the grammar 
of the language being edited.  Thanks to emacs' extensibility via its 
embedded lisp interpreter, you can do that in emacs. It has a great C 
mode   that indents and exdents automatically - e.g. "{" increases the 
indentation level, "}" decreases it.  Recent versions also do color 
syntax highlighting.  I find these things very helpful when editing 
source code; they're a major reason I prefer emacs for editing 
structured text.  Standard emacs distributions now come standard with 
editing modes for a number of languages - Perl, PHP, Pythong, Ruby, etc.

#22, first paragraph: I seem to have sent my copy of _UNIX Power Tools_ home
ahead of me; it has an article on the subject as its first or second article in
the chapter on vi. Most of what that article says that I was going to quote
here is that strict vi is a modal editor; use of arrow keys in command mode may
be permissible, but in an insertion mode it either inserts the control sequence
or just beeps. Most vendors have extended strict vi to allow arrow keys even in
insertion modes, but that leads to user confusion between the modes.

In re your third paragraph: Vim has all of those features by now, too.

Right - early arrow key support allowed it only in command mode, not 
insert mode.

You're right, vim has similar features, and is extensible via a scripting 
language.  I haven't looked at it closely enough to know how it compares 
in power to emacs lisp.

One nice feature of emacs is vi-mode, a pretty accurate and complete vi 
emulation.  You can switch in and out of it with a single keystroke (^Z in 
my setup), and it gives me access to a few operations that are easier in 
vi than emacs (e.g. repeated search-and-replace, or filtering text through 
an external command) without leaving emacs.  Best of both worlds.

Bash has a vi mode, too. I'll look up how to do it when I get home. Yes, I'm
stuck on a Windows box ATM.

I usually use vi because the small editing jobs I do mean I like to have a
quick-to-start up editor. However, since I'm making a concerted effort to
learn programming, and I'm starting with LISP, it seemed sensible to use
Emacs, not least because of SLIME and the fact that Emacs is programmed in
a dialect of LISP. So since I don't shut my machine down, I just loaded up
Emacs, loaded up SLIME, and left it.

#24: "early arrow key support allowed it only in command mode, not insert
mode." 

There's a reason I kept saying "strict vi" above (beyond that vim offers a "vi
compatibility" mode; I suspect arrow keys would work even in that). Vi is a
modal editor; there's a mode in which you enter commands, a mode in which you
insert text, and (in strict vi, I think, but not in vim) a mode that allows
some commands but allows you to insert text. Movement is a command, so of
*course* you can't use the arrow keys to move in insert mode. In open mode
perhaps (I haven't used a version that supported open mode in years, though I
miss it), and definitely in command mode, but allowing a certain class of
commands in insert mode can only confuse users.

What text editor would be best for typing rtf tags?  Can vi or emacs to
macros?  I need to produce something WORD can import and I don't want to use
a gui wordprocessor.  I am looking at tex, which can be converted to pdf (I
can view the pdf with a CLI svgalib program called svp).  pdf files seem to
be larger and harder to read with a text editor.  Meanwhile I continue to use
Wordperfect 5.1 for DOS.

I'm surprised that WordPerfect 5.1 for DOS cannot produce RTF.

At any rate, both vi and emacs have macro capabilities.  Given that you are
a frequent pico user, I'd suggest emacs as being philosophically closer.

Wordperfect itself can be imported into WORD, but does not work (CLI version)
under linux with dosemu or qemu.  Would tex or rtf be easier or faster to
type?  A friend in Lithuania likes tex/latex and has been sending me links
to instructions for it.  

RTF no, but TeX yes.

http://www.ctan.org/tex-archive/info/lshort/english/lshort.pdf

is an excellent LaTeX guide in case anyone is interested.

My Lithuanian friend put together a minimal tex package and also recommends
the above pdf guide  (2MB), which is also available in dvi form (1MB) and as
'src.tar.gz' (200K) - tex?  Or 3MB ps.  He included tex, tex.fmt, dvips, and
some fonts.  I suggested also dvilj in case I want to print - not much use
for ps.  He made another pdftex package, and an xdvi package for viewing in
X, but suggested a couple of svgalib viewers (tmview).  I am looking at
dviware programs - dvilj4 dvipng dvivga (?).   dvilj4 is supposed to also work
with LJIIIP and maybe also plain LJ (which should include deskjets that
support PCL3?).  dvivga is a previewer that supports VGA and seems to need
PK fonts (which he included).  THere is also an
'epson' (printer driver?), a laserjet (that needs PXL fonts), tmview (works
in framebuffer, svgalib, or X),xdvi (this is a large one), dvidjc for deskjet
500 series, catdvi to convert to plain text, dvipdf....

I use vi because I know it.  I don't use emacs because I don't.

I use "cat > FILENAME" because I never make mistakes.

 Too much work.  I wait until the bits I need are coming up in /dev/random
 and then capture them to a file.  It requires a fine sense of timing but
 it avoids a lot of pointless drudgery.

Regarding #34; Under Plan 9, the window system is responsible for most of
the traditional character handling and so on usually done by the line
discipline in the TTY subsystem in Unix.  Plan 9 has no TTY interface:
you're either on the console, in which case you have a bitmap display,
keyboard, and mouse, or you're on a UART, where you have something else.  In
either case, it is expected that some other piece of code will handle
dealing with your input and any special treatment that it needs.  e.g.,
translating Del into an interrupt note sent to the currently running process
group (similar to ^C generating a SIGINT that is sent to the current session
leading process group for that TTY under Unix).  There is no notion of
POSIX-style sessions, job control, or any of the rest of it (and believe me;
the kernel internals for the TTY subsystem under Unix are incredibly
complex, arguably more so than any other subsystem).

However, one neat feature of this is that the window system ends up getting
the opportunity to handle a lot more than just generating the native
equivalent of signals, and in the current implementation, input to processes
running in a window is entirely managed by the window system.  All text in
such a window is editable, and for each window there is a notion of an
`output point' at which text is inserted by the window system, presumably
after being output by whatever programs are running in that window.  Text
entered by the user (or by pasting) after the output point is sent as input
to the process currently running in the window when a newline is
encountered.  Text entered or modified *before* the output point is not sent
anywhere, but remains visible in the window.  Cutting, pasting, command line
editing, etc, is thus all handled by the window system transparently to
whatever is running in the window.

Furthermore, typing Esc in the window puts that window into `hold mode,' in
which no text will be sent to any processes running in the window until Esc
is typed again (returning the window to normal mode).  Hence, `cat > file'
followed by Esc and whatever text you want, editted as you like, followed by
Esc again and then ^D makes a very effective text editor for short files
under Plan 9 (assuming you're using the window system).

And it's even cooler than that.  The window system (and indeed, the entire
graphics subsystem) exports a filesystem interface using the standard Plan 9
file protocol (9P).  This can be imported and mounted over a network,
providing network transparency for the window system, but without the need
for a special protocol ala X11.  In fact, each window has a little
filesystem that it exports, so you can import only a single window, or the
entire thing, or any combination anywhere else on the network.  You get all
the authentication, encryption, etc of the underlying network protocol built
into the window system for free.

http://plan9.bell-labs.com/plan9dist/

Well that's nice, but I don't need all that extra flexibility because,
as I said, I never make mistakes.  :)

Seriously, it sounds like a nifty design.

Heh.

 The bit about putting the window in "hold mode" reminds me of the
 windowing environment in Domain/OS, Apollo's Unix-like (but not
 *sufficiently* Unix-like) OS offering from the mid-to-late 1980s.

 The windows that shells ran in were split into two panes -- the 
 majority of the window, and a one-line input pane at the bottom.
 Input that you typed in the input pane at the bottom wasn't handed
 over to the shell until you hit a carriage return, at which point
 it was handed over to whatever program you were running.  This was
 really nice because at the time unix shells mostly didn't have
 command-line editing, but under this scheme you could do all your
 editing in the input pad in the windowing system and then send it
 to the program.  If you needed to edit multiple lines, the keyboard
 had a "hold" key which would act as you describe "hold" above --
 it would stop the processing of input until you hit "hold" again,
 in the meantime giving you an expanded edit area in the windowing
 system where you could use the cursor keys, mouse pointer, cut and
 paste, etc, to work on editing your text.

 Programs that used character-by-character input modes (e.g. cbreak)
 wouldn't work with this system (the separate edit line would disappear
 into the main window, if I recall properly, while you were running
 such a program) but for things that used a line-by-line input mode
 it was great.

 I still maintain that Domain/OS was *WAY* ahead of its time. 
 In 1987 (wow!  20 years ago!) it had a really nicely-integrated
 windowing system with a very cool facility called "edit pads"
 which were extremely well integrated with special dedicated keys
 on the expanded keyboard, transparent distributed network file system,
 unified object and user registry, full-featured filesystem acls, 
 and other nifty features I'm almost certainly forgetting..

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss