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..
Yeah, I've heard some pretty good things about Domain/OS, but never used it. My understanding was that it was heavily influenced (if not outright inspired) by Multics.
Another feature of Domain/OS that I think should've become more widespread was the ability to create variable symlinks -- that is, you could create mylink -> //server/usr/local/$platform/bin and the $platform part would be interpreted at runtime by the filesystem calls, based on the user's environment variables. This made possible some very flexible ways of supporting different platforms and alternative environments that could be easily selected by altering environment variables.
AFS did something similar. Plan 9 got that right by having per-process namespaces that were mutable by the user. You could, e.g., bind /$cputype/bin onto /bin and all your executables would appear to be under /bin, and would be of the correct type.
I think DragonFlyBSD aims to do this.
resp:12: That made me laugh out loud. I consider myself reasonably proficient at vi, but I still routinely manage to do things like insert 27 copies of the letter "a" because I forgot which mode I'm in. I recently started using Emacs, mostly xemacs. (Before this I was pretty rigidly wedded to "joe.") It's the "official" supported editor for the department I'm working in, so I figured I'd better learn it. I've actually become fond of it quite quickly, mostly because its syntax-highlighting and automatic indenting are light-years ahead of anything else I've used.
Right, Emacs' syntax highlighting and automatic indenting really are better, which is one big reason why I still favor it for programming.
Er, vim? By default it has syntax highlighting (provided the terminal supports it) and displays the current mode.
How about auto-indenting?
Yeah, it has it too. Personally, I don't like autoindenting of any kind, but that's why this is `The Great Text-Editor Holy War Item.'
I just put these two lines in my .vimrc, and the autoindenting works the way I want it when I want it, and not when I don't: autocmd BufRead *.c set cindent autocmd BufRead *.y set cindent I think there may be other indents besides cindent for other languages.
Re #48: Besides helping to make code readable with less work on my part, I also like auto-indenting because it helps catch syntax errors. E.g. if I omit a terminating semicolon, the next line isn't indented as I expect, making the error immediately obvious. Re #49: Okay, I tried that with vim; had to have the line "set nocompatible" as well to get it to work. Seems to auto-indent intelligently, but I'd have to do more playing around to see if it's as smart about it as emacs. For instance, does it know about comments?
Regarding #50; Like I said, it's a matter of personal preference.
Absolutely. Why don't you care for auto-indenting?
I am trying to read a text in Cyrillic, iso 8859-5. I loaded the console font. Character 155 (e) displays as a blank. The other Cyrillic fonts also display 155 as a blank. pico vi or 'less -r'. Is there some way around this other than using X fonts? Opera displays the text properly with its built-in Cyrillic font. I am told 155 is a control character. cp1251 uses it for half of an integral sign, and cp866 for a box character, but 8859-5 and koi8-r have vowels at 155. So I designed cp1251 font. Also will nano or vi or joe let you type up something that wraps at 80 columns, and then unwrap it before you import it into a wordprocessor?
#50: I'm surprised you had to use "set nocompatible". I thought that was the default when vim detects the presence of .vimrc, even if it's empty. And yes, it does know about comments.
Regarding #52; Inevitably, it does something that I don't like and then I have to fiddle with it to get things the way that I want them.
re #52: One reason I don't care for the auto-indent feature in vi is that it inserts tabs instead of spaces in some situations. I'm reasonably sure there's an easy way to defeat this "feature" if I really wanted to, but I am easily bothered by that behavior.
I believe it has to do with the size of the indent. In addition to
the two lines mentioned, I also have "set shiftwidth=4" in my .vimrc,
which makes my autoindent work four spaces at a time. An eight space
indent will still be done by inserting a tab. My indents typically
go:
1st indent 4 spaces
2nd indent 1 tab
3rd indent 1 tab + 4 spaces
4th indent 2 tabs
5th indent 2 tabs + 4 spaces
etc.
You can easily shift a line or group of lines in or out to a different
indent level using << and >>. I haven't tried to see if spaces could
be substituted for tabs in all cases or not. The above has been
acceptable to me for now.
Autoindent in vi doesn't care what your shiftwidth is set to, it cares where the first non-whitespace character on the line above it is. Not sure if that's true about vim in one of its special syntax modes. The problem I have with tab-substitution on auto-indenting doesn't require any single indent to be 8 characters from the previous one, it happens on any line where the first non-whitespace character is in the 8th or greater column.
#59: > Autoindent in vi doesn't care what your shiftwidth is set to, > it cares where the first non-whitespace character on the line > above it is. Not sure if that's true about vim in one of its > special syntax modes. I'd have to experiment to find out what it does in all cases, but I know that vim does as you describe, but recognizes when it should indent another level or end a level and go back to the previous level. When indenting a level it uses my shiftwidth, although it doesn't use my shiftwidth when breaking up a long line into two shorter lines, an which case, if I remember correctly, it uses tabs, and I sometimes have to adjust them to suit my preferences, but I'd have to do that anyway. Sometimes, I want to align things in a certain way, and I don't think you can automate something like that for all cases. > The problem I have with tab-substitution on auto-indenting > doesn't require any single indent to be 8 characters from the > previous one, it happens on any line where the first non-whitespace > character is in the 8th or greater column. As I said, indents of more than eight spaces will use tabs as much as possible, and then spaces when an additional tab would go too far to the right. I don't know offhand if that can be overridden to use only spaces or not. Does emacs not use tabs for autoindent? It's been awhile since I tried playing around with emacs, but I thought it did.
Re #58 and #59: Right, classical auto-indent in vi is pretty primitive compared to the language-specific formatting that modern editors like vim and emacs can do. Maybe the latter should be called "auto-formatting" rather than "auto-indent".
In vim, see :he expandtab to get spaces when you indent.
Hmmm.. thanks, I'll check that out and set up my .vimrc accordingly. It certainly beats getting exasperated and piping everything through "expand" every so often..
I think it mostly comes to personal preference. I just don't like vi/vim's two modes. I prefer a non-modal editor. Having to switch modes messes with my workflow, especially when I forget and find myself typing in the wrong mode. (And then having to delete the 27 copies of the letter 'a' I just inserted.) I also find deletions in vi pretty awkward; deleting a single character requires two keystrokes.
No it doesn't.
There's a way to do it other than "d [space]"?
Yes, `x' will delete the current character.
But you have to press ESC first to get into the command mode ?
Not if you're already in command mode. And if you're not, then you most likely want to delete the last character entered, in which case, the backspace key works just fine.
Regarding #67; What Chuck said. But if you're doing d-whatever, then you're already in command mode.
Like David, my preference is for non-modal over modal; when editing text, it's more convenient in most cases to be in insert mode by default, and, if you need to do some special command, to be returned to insert mode automatically rather than having to type something like "i" to get back into it. It's not a strong preference, though. I've done so much vi-ing that it's hard-coded in my brain now, so I'm comfortable using it even though I prefer emacs. Guess that means I'm bi-editorial.
http://xkcd.com/378/
Nice.
A bit of editor news: Richard Stallman is stepping down as Emacs maintainer after 32 years. http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02140.html
Finally agreed to take that job working for Microsoft, eh? :-p
Maybe his Emacs Pinky Syndrome is playing up again.
/emote "toys with the idea of writing a 'Princess Bride' parody where Stallman is consumed with searching for the six-fingered man who killed his father." It would explain so much..
re #74 Maybe he's going to help Bill Gates with his new LinkedIn account?
resp: 56 - I believe this should remedy that behavior by converting the \\t to four spaces. IIRC, even auto-indenting will respect that. set tabstop=4 -DTK
resp:76 "My name is Richard Stallman. You killed my AI lab. Prepare to die."
Ed, man! !man ed When I'm feeling lazy, Emacs is comfortable like lasagne. vi is fine for a light snack (not bloaty vim - if I want bloat, I'll load Emacs), or nano. I actually do use ed for quickly creating small files or when I'm on an under-powered or limited-keyboard terminal, like my smartphone. When I'm retro-computing, I like to learn the default editor for the system I'm using, TECO and pre-GNU EMACS on ITS or EDIT/EDT on VMS.
You have several choices: