35 new of 80 responses total.
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: