|
Grex > Jelly > #74: The Great Text-Editor Holy War Item. | |
|
| Author |
Message |
| 25 new of 80 responses total. |
remmers
|
|
response 50 of 80:
| 
Aug 23 09:47 UTC 2007 |
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?
|
cross
|
|
response 51 of 80:
|
Aug 23 13:30 UTC 2007 |
Regarding #50; Like I said, it's a matter of personal preference.
|
remmers
|
|
response 52 of 80:
|
Aug 23 14:10 UTC 2007 |
Absolutely. Why don't you care for auto-indenting?
|
keesan
|
|
response 53 of 80:
|
Aug 23 15:55 UTC 2007 |
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?
|
unicorn
|
|
response 54 of 80:
|
Aug 23 18:21 UTC 2007 |
#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.
|
cross
|
|
response 55 of 80:
|
Aug 23 22:48 UTC 2007 |
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.
|
mcnally
|
|
response 56 of 80:
|
Aug 25 03:13 UTC 2007 |
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.
|
unicorn
|
|
response 57 of 80:
|
Aug 26 01:00 UTC 2007 |
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.
|
mcnally
|
|
response 58 of 80:
|
Aug 26 02:19 UTC 2007 |
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.
|
unicorn
|
|
response 59 of 80:
|
Aug 26 03:19 UTC 2007 |
#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.
|
remmers
|
|
response 60 of 80:
|
Aug 26 13:03 UTC 2007 |
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".
|
kentn
|
|
response 61 of 80:
|
Aug 26 22:58 UTC 2007 |
In vim, see :he expandtab to get spaces when you indent.
|
mcnally
|
|
response 62 of 80:
|
Aug 27 03:25 UTC 2007 |
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..
|
gull
|
|
response 63 of 80:
|
Aug 28 20:59 UTC 2007 |
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.
|
cross
|
|
response 64 of 80:
|
Aug 28 21:27 UTC 2007 |
No it doesn't.
|
gull
|
|
response 65 of 80:
|
Aug 28 23:02 UTC 2007 |
There's a way to do it other than "d [space]"?
|
cross
|
|
response 66 of 80:
|
Aug 28 23:22 UTC 2007 |
Yes, `x' will delete the current character.
|
sholmes
|
|
response 67 of 80:
|
Aug 29 01:45 UTC 2007 |
But you have to press ESC first to get into the command mode ?
|
unicorn
|
|
response 68 of 80:
|
Aug 29 03:58 UTC 2007 |
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.
|
cross
|
|
response 69 of 80:
|
Aug 29 04:13 UTC 2007 |
Regarding #67; What Chuck said. But if you're doing d-whatever, then you're
already in command mode.
|
remmers
|
|
response 70 of 80:
|
Aug 29 17:36 UTC 2007 |
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.
|
remmers
|
|
response 71 of 80:
|
Feb 1 16:56 UTC 2008 |
http://xkcd.com/378/
|
cross
|
|
response 72 of 80:
|
Feb 4 00:50 UTC 2008 |
Nice.
|
remmers
|
|
response 73 of 80:
|
Feb 23 15:08 UTC 2008 |
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
|
mcnally
|
|
response 74 of 80:
|
Feb 23 23:49 UTC 2008 |
Finally agreed to take that job working for Microsoft, eh?
:-p
|