...making Linux just a little more fun!
Peter Knaggs [peter.knaggs at gmail.com]
Wed, 6 Dec 2006 01:30:25 -0800
Greetings!
I guess Emacs users (and all non-vim users) can cheerfully skip this question.
Have you ever noticed when you're typing quickly in "vim" that things sometimes go haywire? I only recently got around to figuring out how to reproduce this "vim" glitch, I guess because I was so used to "vi" that I didn't consciously remember the names of the keys I was pressing.
So anyways, if you open a file with some text in it, then pick a line of reasonable length, and use shift A to append, then press the Esc key to leave append mode, then immediately press shift O to insert a new line above and start typing immediately, bad things happen. It seems that occasionally after pressing shift O that it takes vim almost half a second to catch up, during which I guess it's not yet in insert mode.
Does the same thing happen for you?
And why only for shift O, not for any of the other ways of getting into insert mode?
I didn't find the answer in the vim FAQ. I guess I might have to go to the source code, any hints on where to start looking?
Cheers, Peter.
Thomas Adam [thomas.adam22 at gmail.com]
Wed, 6 Dec 2006 11:49:44 +0000
On Wed, Dec 06, 2006 at 01:30:25AM -0800, Peter Knaggs wrote:
> Does the same thing happen for you?
I bet it's not so bad if you do:
:syn offto turn of syntax hilighting.
-- Thomas Adam
-- "Wanting to feel; to know what is real. Living is a lie." -- Purpoise Song, by The Monkees.
Benjamin A. Okopnik [ben at linuxgazette.net]
Wed, 6 Dec 2006 09:26:34 -0500
Hi, Peter -
You're probably unaware of this, but you sent your message in HTML format. This doubled the size of your message without any benefit in return, and will create extra work for our Mailbag editor.
Please change your mailer's settings to stop it from doing this. For more info, please see <https://expita.com/nomime.html>.
On Wed, Dec 06, 2006 at 01:30:25AM -0800, Peter Knaggs wrote:
> > Greetings! > I guess Emacs users (and all non-vim users) can cheerfully skip this > question. > Have you ever noticed when you're typing quickly in "vim" that things > sometimes go haywire?
Can't say I have. I imagine that this would happen if you had mapped some sort of key combination in which the first key was that same as a common command key in Vim, though.
Example:
imap OX :s/sheep/ox/<CR>If you did this, then Vim would wait for that half a second (or whatever you've changed the standard delay to) every time you typed 'O' - it would be checking to see if you're going to add an 'X' after it. Needless to say, You Shouldn't Do That.
> I only recently got around to figuring out how to reproduce this "vim" > glitch, I guess because > I was so used to "vi" that I didn't consciously remember the names of the > keys I was pressing. > So anyways, if you open a file with some text in it, then pick a line of > reasonable length, > and use shift A to append, then press the Esc key to leave append mode, then > immediately > press shift O to insert a new line above and start typing immediately, bad > things happen. > It seems that occasionally after pressing shift O that it takes vim almost > half a second to > catch up, during which I guess it's not yet in insert mode. > Does the same thing happen for you?
Nope. I've just tried it several times, and I don't see any glitches.
> And why only for shift O, not for any of the other ways of getting into > insert mode?
Try typing 'map O' at your Vim command line, and see what it says. Just for reference, mine says 'No mapping found'. You might also want to check your /etc/vimrc (although I doubt that the Vim folks would leave you a nasty present like that) and your ~/.vimrc - which is where the problem is mostly likely to be. Also, test it without a .vimrc (use the '-u' option with an empty file as an argument) and see if it persists.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
John Karns [johnkarns at gmail.com]
Wed, 6 Dec 2006 11:25:38 -0500
Note: I'm replying via the gmail web interface and don't know if it sends in html format or not. So apologies if it does.
On 12/6/06, Benjamin A. Okopnik <ben@linuxgazette.net> wrote:
> Hi, Peter - >
> On Wed, Dec 06, 2006 at 01:30:25AM -0800, Peter Knaggs wrote: > > > > Greetings! > > I guess Emacs users (and all non-vim users) can cheerfully skip this > > question. > > Have you ever noticed when you're typing quickly in "vim" that things > > sometimes go haywire? > > Can't say I have. I imagine that this would happen if you had mapped > some sort of key combination in which the first key was that same as a > common command key in Vim, though.
Indeed it would have to be due to vim being busy with executing a macro during that time. Which macro gets executed may be dependent on the extension of the file name you're opening for edit, and how your distro has vim configured.
Ben's suggestion of using the "-u" option flag should confirm that.
-- John Karns
Peter Knaggs [peter.knaggs at gmail.com]
Wed, 6 Dec 2006 10:14:20 -0800
On 12/6/06, Benjamin A. Okopnik <ben@linuxgazette.net> wrote:
> Hi, Peter - > > You're probably unaware of this, but you sent your message in HTML > format. This doubled the size of your message without any benefit in > return, and will create extra work for our Mailbag editor.
Hi Ben,
Thanks for letting me know about the HTML issue: I had apparently
replied to an HTML message in the past, and doing that seems to "flip"
gmail over into "Rich text" mode. Once it's in that mode, though, it
stays with it for all subsequent new messages. So effectively, the
"Compose Mail" is actually a modal button. Not something I'd have
expected from a user interface for an email client. But I guess if I'm
lazy and don't run my own email server, I can hardly complain
> Please change your mailer's settings to stop it from doing this. For > more info, please see <https://expita.com/nomime.html>.
I hope it's OK this time, there's no "Rich formatting", and I tested by sending an email to myself and it doesn't show any HTML.
> Can't say I have. I imagine that this would happen if you had mapped > some sort of key combination in which the first key was that same as a > common command key in Vim, though.
You guys are the greatest, thanks for Thomas and John's comments too. It turns out the problem happens for me if I have any vimrc whatsoever. So once I remove $HOME/.vimrc and /usr/share/vim/vimrc then the problem goes away. Putting back /usr/share/vim/vimrc causes the problem to come back. I'm using Ubuntu Dapper Drake at the moment, but I've seen this problem on almost all the distros I've ever used.
> Nope. I've just tried it several times, and I don't see any glitches.
It does take a bit of trial and error. Maybe this is a better sequence to reproduce it: Pick a line with some text. Type the number key "0", the "A" key, then "Esc" key. Now press the "O" key. It seems to only happen intermittently, so try it a few times with that sequence.
> > > And why only for shift O, not for any of the other ways of getting into > > insert mode?
Indeed, it's probably my bad habit
Well, I can't make up my mind whether I want to add text above
or below the line I'm currently on. So oftentimes, I'm about to use
"A" to append
and then I realize I need to stick the stuff in above the line and
not below it.
So I hit "Esc". Well now you see "O" is the natural choice to insert above.
Otherwise, I have to use "ko" and after that I'm unconscious for a while
> Try typing 'map O' at your Vim command line, and see what it says. > Just for reference, mine says 'No mapping found'.
It says No mapping found for me too.
> You might also want to > check your /etc/vimrc (although I doubt that the Vim folks would leave > you a nasty present like that) and your ~/.vimrc - which is where the > problem is mostly likely to be. Also, test it without a .vimrc (use the > '-u' option with an empty file as an argument) and see if it persists.
Indeed, using a blank file works fine, no glitch. So I guess my new favorite way of using vim is going to be something like: touch $HOME/empty_file vim -u $HOME/empty_file file_I_want_to_edit_without_fear_of_glitch
Cheers, Peter.
Benjamin A. Okopnik [ben at linuxgazette.net]
Thu, 7 Dec 2006 18:10:18 -0500
On Wed, Dec 06, 2006 at 10:14:20AM -0800, Peter Knaggs wrote:
> On 12/6/06, Benjamin A. Okopnik <ben@linuxgazette.net> wrote: > > Hi, Peter - > > > > You're probably unaware of this, but you sent your message in HTML > > format. This doubled the size of your message without any benefit in > > return, and will create extra work for our Mailbag editor. > > Hi Ben, > Thanks for letting me know about the HTML issue: I had apparently > replied to an HTML message in the past, and doing that seems to "flip" > gmail over into "Rich text" mode. Once it's in that mode, though, it > stays with it for all subsequent new messages. So effectively, the > "Compose Mail" is actually a modal button. Not something I'd have > expected from a user interface for an email client.
Neither would I; in fact, I'd probably start looking for an alternate explanation and doing a bit of testing to narrowit down to the exact cause. That interface sounds like it was written by a maniac who's realized that he can't stick forks in people's yes over the Net but has thought up an electronic equivalent.
> > Please change your mailer's settings to stop it from doing this. For > > more info, please see <https://expita.com/nomime.html>. > > I hope it's OK this time, there's no "Rich formatting", and I tested > by sending an email to myself and it doesn't show any HTML.It looks fine now - although I don't know that thinking of plain text as "Poor formatting" would be useful.
> > You might also want to > > check your /etc/vimrc (although I doubt that the Vim folks would leave > > you a nasty present like that) and your ~/.vimrc - which is where the > > problem is mostly likely to be. Also, test it without a .vimrc (use the > > '-u' option with an empty file as an argument) and see if it persists. > > Indeed, using a blank file works fine, no glitch. > So I guess my new favorite way of using vim is going to be something like: > touch $HOME/empty_file > vim -u $HOME/empty_file file_I_want_to_edit_without_fear_of_glitch
Why not find the offending line (either by using the "divide and
conquer" method, or via deleting one line at a time if it's reasonably
short) instead? That way, you'd know what to avoid in the future. In
fact, once you found it, you could file a bug report with the Vim
maintainers. That could be, you know, kinda like Open Source and stuff.
Might even benefit other people.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Peter Knaggs [peter.knaggs at gmail.com]
Thu, 7 Dec 2006 17:22:36 -0800
On 12/7/06, Benjamin A. Okopnik <ben@linuxgazette.net> wrote:
> On Wed, Dec 06, 2006 at 10:14:20AM -0800, Peter Knaggs wrote: > > Hi Ben, > > Thanks for letting me know about the HTML issue: I had apparently > > replied to an HTML message in the past, and doing that seems to "flip" > > gmail over into "Rich text" mode. Once it's in that mode, though, it > > stays with it for all subsequent new messages. So effectively, the > > "Compose Mail" is actually a modal button. Not something I'd have > > expected from a user interface for an email client. > > Neither would I; in fact, I'd probably start looking for an alternate > explanation and doing a bit of testing to narrowit down to the exact > cause. That interface sounds like it was written by a maniac who's > realized that he can't stick forks in people's yes over the Net but has > thought up an electronic equivalent. > > > Indeed, using a blank file works fine, no glitch. > > So I guess my new favorite way of using vim is going to be something like: > > touch $HOME/empty_file > > vim -u $HOME/empty_file file_I_want_to_edit_without_fear_of_glitch > > Why not find the offending line (either by using the "divide and > conquer" method, or via deleting one line at a time if it's reasonably > short) instead? That way, you'd know what to avoid in the future. In > fact, once you found it, you could file a bug report with the Vim > maintainers. That could be, you know, kinda like Open Source and stuff. > Might even benefit other people.
I find that the presence of the following line in /usr/share/vim/vimrc is perhaps the entire cause of the glitch:
runtime! debian.vimAs it is ominously preceded by the following comments, I'm wondering is it safe to remove?
" This line should not be removed as it ensures that various options are " properly set to work with the Vim-related packages available in Debian.Or does it just mean that the rabit-hold goes deeper, and I need to look into what a debian.vim runtime consists of?
Thanks, Peter.
Benjamin A. Okopnik [ben at linuxgazette.net]
Thu, 7 Dec 2006 21:01:51 -0500
On Thu, Dec 07, 2006 at 05:22:36PM -0800, Peter Knaggs wrote:
> > I find that the presence of the following line > in /usr/share/vim/vimrc is perhaps the entire cause of the glitch: > > runtime! debian.vim
Ah-hah! Well done, Peter.
> As it is ominously preceded by the following comments, > I'm wondering is it safe to remove? > > " This line should not be removed as it ensures that various options are > " properly set to work with the Vim-related packages available in Debian. > > Or does it just mean that the rabit-hold goes deeper, > and I need to look into what a debian.vim runtime consists of?
Indeed you should - as an extension of the troubleshooting process I suggested. 'runtime', incidentally, is similar to the 'source' command: it loads all rc files from the "runtimepath" defined by Vim ($HOME/.vim, $VIM/vimfiles, $VIMRUNTIME, $VIM/vimfiles/after, $HOME/.vim/after in Unix.) So, the right thing to do is to look in those directories, find "debian.vim", and troubleshoot it the same way that I suggested.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Peter Knaggs [peter.knaggs at gmail.com]
Sat, 9 Dec 2006 11:27:39 -0800
Hi Gang,
Sorry it took me so long, I've gotten the vim glitch narrowed down to just turning on one option: set nocompatible I'm pretty sure now that's the culprit, because the glitch happens even if I entirely remove
$HOME/.vimrc
/usr/share/vim/vimrc
/usr/share/vim/vim64
so that the strace of vim startup only shows $HOME/.viminfo being opened.
Assuming no other config files are involved at this point, so if I have '' cat $HOME/config_glitch set nocompatible '' and then start up vim using essentially just that config file using the -u option:
vi -u $HOME/config_glitchwill reproduce the slow-insert-line-above glitch using this sequence: Pick a line with some text. Type the number key "0", the "A" key, then "Esc" key. Now press the "O" key. It seems to sometimes happen intermittently, so try it over again a few times with that sequence.
It seems that I can't just comment out the "set nocompatible" because then none of the startup macros will work, e.g. one that I tend to use a lot to restart editing at the same place as when I closed the file, goes like this:
set nocompatible
if has("autocmd")
filetype plugin off
autocmd BufReadPost *
\ if line("'\"") > 0 && line ("'\"") <= line("$") |
\ exe "normal! g'\"" |
\ endif
endif
So it looks like the next thing is going to involve diving into
the vim source to see how the codepath changes with or without
the "set nocompatible" flag. It's usually easy to debug C stuff,
I'll give it a try, hopefully get enough to file a bug with the vim folks.
Thanks for all the help narrowing down the problem and suggesting the "-u" option. Cheers, Peter.
Peter Knaggs [peter.knaggs at gmail.com]
Sat, 9 Dec 2006 16:06:51 -0800
On 12/9/06, Peter Knaggs <peter.knaggs@gmail.com> wrote:
> > cat $HOME/config_glitch > set nocompatible > > and then start up vim using essentially just that config file using > the -u option: > > vi -u $HOME/config_glitch > > will reproduce the slow-insert-line-above glitch using this sequence: > Pick a line with some text. Type the number key "0", the "A" key, > then "Esc" key. Now press the "O" key. It seems to sometimes happen > intermittently, so try it over again a few times with that sequence. > > So it looks like the next thing is going to involve diving into > the vim source to see how the codepath changes with or without > the "set nocompatible" flag. It's usually easy to debug C stuff, > I'll give it a try, hopefully get enough to file a bug with the vim folks. >
So the vim sources are pretty interesting, there's lots of stuff in there to keep me busy for a while. But anyways, I've found where the "glitch" is coming from: there's a 1000 millisecond "wait" for nothing. There are no characters available when it calls RealWaitForChar with a 1000 millisecond timeout, which causes a long pause. I attached gdb to vim compiled with debug like this
cvs -z3 -d:pserver:anonymous@vim.cvs.sf.net:/cvsroot/vim checkout vim7
cd vim7
CFLAGS=-g make
then put a breakpoint on getchar.c:1519 and entered my testcase
all in one fell swoop (i.e. "cont" in gdb, then pressing A Esc O one after the
other in the vim window). Then I used single-step in gdb using the
"step" command.
It was a lot of tracing, I didn't include it all here. But if you hold
down the Enter key
in gdb it will quickly re-do the "step" command over and over. Then, I
just watch
for a "gap" (see below). The "gap" means that vim is doing something (waiting
on "select" in this case), when it should be doing useful work getting back to
interact with the user (yours truly, in this instance). The trace
looks like the
following, but the reason why it's doing this call to RealWaitForChar with a
one-second timeout I still need to go back and figure out. At least it's some
progress for one day Cheers, Peter.
WaitForChar (msec=1000) at os_unix.c:4463 4463 if (rest != 0) (gdb) 4476 avail = RealWaitForChar(read_cmd_fd, msec, NULL); (gdb) RealWaitForChar (fd=0, msec=1000, check_for_gpm=0x0) at os_unix.c:4534 4534 if (msec > 0 && ( (gdb) 4551 gettimeofday(&start_tv, NULL); (gdb) 4556 if (busy) (gdb) 4565 int finished = TRUE; /* default is to 'loop' just once */ (gdb) 4693 long towait = msec; (gdb) 4710 if (towait >= 0) (gdb) 4712 tv.tv_sec = towait / 1000; (gdb) 4713 tv.tv_usec = (towait % 1000) * (1000000/1000); (gdb) 4714 tvp = &tv; (gdb) 4722 FD_ZERO(&rfds); /* calls bzero() on a sun */ (gdb) 4723 FD_ZERO(&efds); (gdb) 4724 FD_SET(fd, &rfds); (gdb) 4727 FD_SET(fd, &efds); (gdb) 4729 maxfd = fd; (gdb) 4741 if (xterm_Shell != (Widget)0) (gdb) 4743 FD_SET(ConnectionNumber(xterm_dpy), &rfds); (gdb) 4744 if (maxfd < ConnectionNumber(xterm_dpy)) (gdb) 4745 maxfd = ConnectionNumber(xterm_dpy); (gdb) 4758 if (xsmp_icefd != -1) (gdb) 4760 FD_SET(xsmp_icefd, &rfds); (gdb) 4761 FD_SET(xsmp_icefd, &efds); (gdb) 4762 if (maxfd < xsmp_icefd) (gdb) 4772 ret = select(maxfd + 1, &rfds, NULL, &efds, tvp); (gdb) 4792 if (ret > 0 && xterm_Shell != (Widget)0 (gdb) 4815 if (ret > 0 && xsmp_icefd != -1) (gdb) 4839 if (finished || msec == 0) (gdb) 4862 return (ret > 0); (gdb) 4863 }
Benjamin A. Okopnik [ben at linuxgazette.net]
Sat, 9 Dec 2006 20:53:17 -0500
On Sat, Dec 09, 2006 at 11:27:39AM -0800, Peter Knaggs wrote:
> Hi Gang, > > Sorry it took me so long, I've gotten the vim glitch > narrowed down to just turning on one option: > set nocompatible
[skipping a recount of the tracing procedure]
Good job, Peter! You've hunted it down, clearly; I'd suggest reporting it to the Vim maintainers.
The curious thing is, 'set nocp' is supposed to be the default setting for Vim:
(from the 'help nocompatible' entry in Vim)
By default this option is on and the Vi defaults are used for the options. This default was chosen for those people who want to use Vim just like Vi, and don't even (want to) know about the 'compatible' option.I wonder what happens if you try living without it - the above documentation implies (elsewhere in the same entry) that 'set cp' is an interesting option to explore for people who want to use Vim as Vim, instead of as Vi.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Peter Knaggs [peter.knaggs at gmail.com]
Sat, 9 Dec 2006 19:21:37 -0800
On 12/9/06, Benjamin A. Okopnik <ben@linuxgazette.net> wrote:
> > Good job, Peter! You've hunted it down, clearly; I'd suggest reporting > it to the Vim maintainers.
I'm here at Rick's consipre linux meeting, and got a lot of hints:
It turns out that after setting "TERM=linux" instead of using "TERM=xterm",
the glitch no longer occurs. So it doesn't occur by default when using the
console, which is reassuring
Another hint, was to use "strace -r -p <pid_of_vim>" and then type
the sequence into the vim session. The strace output shows in the
left hand column the elapsed time of the previous system call. So
it's easy to spot where the one-second pause is coming from
> > The curious thing is, 'set nocp' is supposed to be the default setting > for Vim:
Hmm, true. But I think they mean non-compatible with vi, as opposed
to non-compatible with vim. I'm still puzzled
> > (from the 'help nocompatible' entry in Vim) > `` > By default this option is on and the Vi defaults are used for the > options. This default was chosen for those people who want to use Vim > just like Vi, and don't even (want to) know about the 'compatible' > option.
This explanation seems pretty confusing to me. In the context, am I supposed to interpret "vi" as meaning "vim"?
> I wonder what happens if you try living without it - the above > documentation implies (elsewhere in the same entry) that 'set cp' is an > interesting option to explore for people who want to use Vim as Vim, > instead of as Vi.
Hmm, I find that using "set cp" causes the following macro not to work, I have to change it back to "set nocp":
set cp
if has("autocmd")
filetype plugin off
autocmd BufReadPost *
\ if line("'\"") > 0 && line ("'\"") <= line("$") |
\ exe "normal! g'\"" |
\ endif
endif
Guess it's time to file a bug, we've come a fair ways
to getting a solid testcase, and learned a good few
useful tricks for debugging stuff along the way Cheers, Peter.
Benjamin A. Okopnik [ben at linuxgazette.net]
Sat, 9 Dec 2006 23:16:34 -0500
On Sat, Dec 09, 2006 at 07:21:37PM -0800, Peter Knaggs wrote:
> On 12/9/06, Benjamin A. Okopnik <ben@linuxgazette.net> wrote: > > > > > Good job, Peter! You've hunted it down, clearly; I'd suggest reporting > > it to the Vim maintainers. > > I'm here at Rick's consipre linux meeting, and got a lot of hints:
Oh, I didn't realize you were geographically-capable of conspiring with Rick. Next time I'm in the area, it would be nice to meet you F2F - not that I make it out to the West coast all that often these days. In fact, rather than warm and sunny California, I'm headed for Madison, Wisconsin tomorrow... anybody have a pair of snowshoes I could use?
> It turns out that after setting "TERM=linux" instead of using "TERM=xterm", > the glitch no longer occurs. So it doesn't occur by default when using the > console, which is reassuring
That's really odd - and solidifies my concept of it as a bug. I'd been thinking that it was possible to "configure it out", but if it's coll[ui]ding with an essentially random factor like the TERM setting, it needs to go.
> Another hint, was to use "strace -r -p <pid_of_vim>" and then type > the sequence into the vim session. The strace output shows in the > left hand column the elapsed time of the previous system call. So > it's easy to spot where the one-second pause is coming fromOh, good call. I hadn't even thought of that, although I'm certainly used to looking for something that can trigger a watch condition when I'm troubleshooting. I guess that interval sequences are a "human-only" watch condition, and I'm usually searching for the other kind.
> > The curious thing is, 'set nocp' is supposed to be the default setting > > for Vim: > > Hmm, true. But I think they mean non-compatible with vi, as opposed > to non-compatible with vim. I'm still puzzled
Now that I've re-parsed it... yeah, it doesn't make a whole lot of sense either. Does 'nocp' mean "make Vim not compatible with *itself*"??? That would be an example of taking the English language around the bend, beating it silly, and stealing its shoes.
> > I wonder what happens if you try living without it - the above
> > documentation implies (elsewhere in the same entry) that 'set cp' is an
> > interesting option to explore for people who want to use Vim as Vim,
> > instead of as Vi.
>
> Hmm, I find that using "set cp" causes the following macro not to work,
> I have to change it back to "set nocp":
>
> set cp
> if has("autocmd")
> filetype plugin off
If you look up ':help filetype', the reason is stated immediately above the definition: "{Vi does not have any of these commands}".
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Brian Bilbrey [bilbrey at orbdesigns.com]
Sun, 10 Dec 2006 09:07:14 -0500
On Sat, Dec 09, 2006 at 11:16:34PM -0500, Benjamin A. Okopnik wrote:
[snip through partial quoting from :help nocompatible ]
> > This explanation seems pretty confusing to me. > > In the context, am I supposed to interpret "vi" as meaning "vim"? > > Now that I've re-parsed it... yeah, it doesn't make a whole lot of sense > either. Does 'nocp' mean "make Vim not compatible with *itself*"??? That > would be an example of taking the English language around the bend, > beating it silly, and stealing its shoes.
Let's give that a little more context:
'compatible' *'cp'* 'nocompatible' *'nocp'*
'compatible' 'cp' boolean (default on, off when a |vimrc| or |gvimrc|
file is found)
global
{not in Vi}
This option has the effect of making Vim either more Vi-compatible, or
make Vim behave in a more useful way.
This is a special kind of option, because when it's set or reset,
other options are also changed as a side effect. CAREFUL: Setting or
resetting this option can have a lot of unexpected effects: Mappings
are interpreted in another way, undo behaves differently, etc. If you
set this option in your vimrc file, you should probably put it at the
very start.
By default this option is on and the Vi defaults are used for the
options. This default was chosen for those people who want to use Vim
just like Vi, and don't even (want to) know about the 'compatible'
option.
...
So, observe that the paragraph in question is actually talking about the
"compatible" option, not the "nocompatible" option (which are really two
sides of a coin, after all. It goes on to say that once a .vimrc is found
(either global or ~), that setting flips implicitly to nocp, and turns on
all the non-VI-like behavior that Vim is capable of.
Sometimes I think it's better to have options like this:
# set compatible = 1 # Default [1] is option and command compatible # with Vi. Disable this option [0] to use all # of the Vim enhancements and extensions.So that when discussing the options in a help file, there's no confusion about whether the text refers to the option or it's opposite. But that's not the path that Bram chose, so ....
best,
.brian
-- Brian Bilbrey : https://www.orbdesigns.com/ "Kirk to Enterprise -- beam down yeoman Rand and a six-pack."
Peter Knaggs [peter.knaggs at gmail.com]
Sun, 10 Dec 2006 14:38:42 -0800
On 12/9/06, Benjamin A. Okopnik <ben@linuxgazette.net> wrote:
> > Oh, I didn't realize you were geographically-capable of conspiring with > Rick. Next time I'm in the area, it would be nice to meet you F2F - not > that I make it out to the West coast all that often these days. In fact, > rather than warm and sunny California, I'm headed for Madison, Wisconsin > tomorrow... anybody have a pair of snowshoes I could use?
No snowshoes here. Don't penguins like us just grip the ice with our claws, give a shove, then slide along the rest of the way on our tummies?
> That's really odd - and solidifies my concept of it as a bug. I'd been > thinking that it was possible to "configure it out", but if it's > coll[ui]ding with an essentially random factor like the TERM setting, it > needs to go.
I sent the following email over to the vim-dev list, in the meantime reading the vim sources. It'll take time, hopefully the vim-dev folks have some hints on where to look.
Hi All,
I'm new to this list, and would like to help with looking into this apparent timing bug in vim (on the Linux platform).
When vim is running with "set nocompatible" and with TERM=xterm the following sequence (when typed fairly quickly) on a blank line in an empty file causes an asterisk (*) character, instead of the expected "j" character, to be inserted in the file:
A Esc O j Esc (typed quickly) The result is: *
The A causes vim to go into insert mode, Escape leaves insert mode again. The O inserts a new line above the blank line, and the lower case "j" should normally become the contents of the new line. So the result should be: j
But instead, a single line containing only an asterisk is the result.
When running with TERM=linux or with the setting "set compatible", a single "j" on a line by itself above a blank line is the result, which I think is what is expected.
Another aspect of the same bug can be seen by looking at the timeout value passed to the "select()" call in the routine "RealWaitForChar()", when the following sequence is entered into an empty vim session:
A Esc O
Using "strace -r -p <pid>" where <pid> is the process id of the vim process, I can see there is a one-second timeout of a select call. Using gdb, I find that it's from the "RealWaitForChar()" which is called with msec=1000 from the following call stack:
Breakpoint 1, RealWaitForChar (fd=0, msec=1000, check_for_gpm=0x0)
at os_unix.c:4772
4772 ret = select(maxfd + 1, &rfds, NULL, &efds, tvp);
(gdb) where
#0 RealWaitForChar (fd=0, msec=1000, check_for_gpm=0x0) at os_unix.c:4772
#1 0x0811c29b in WaitForChar (msec=1000) at os_unix.c:4476
#2 0x08118f09 in mch_inchar (buf=0x81a3b6c "", maxlen=62, wtime=1000,
tb_change_cnt=68) at os_unix.c:328
#3 0x08171c96 in ui_inchar (buf=0x81a3b6c "", maxlen=62, wtime=1000,
tb_change_cnt=68) at ui.c:189
#4 0x080bd166 in inchar (buf=0x81a3b6c "", maxlen=188, wait_time=1000,
tb_change_cnt=68) at getchar.c:2899
#5 0x080bce41 in vgetorpeek (advance=1) at getchar.c:2685
#6 0x080bb7ca in vgetc () at getchar.c:1536
#7 0x080bbbc3 in safe_vgetc () at getchar.c:1733
#8 0x0805997f in edit (cmdchar=65, startln=0, count=1) at edit.c:708
#9 0x081026c7 in invoke_edit (cap=0xbfef9fa0, repl=0, cmd=65, startln=0)
at normal.c:8725
#10 0x0810266c in nv_edit (cap=0xbfef9fa0) at normal.c:8698
#11 0x080f7086 in normal_cmd (oap=0xbfefa02c, toplevel=1) at normal.c:1136
#12 0x080c77ca in main_loop (cmdwin=0, noexmode=0) at main.c:1154
#13 0x080c7395 in main (argc=1, argv=0xbfefa214) at main.c:934
From what I understand, the timeout (during which "O" is displayed by vim)
is happening because there are no further input characters from the user.
But the one-second delay before the newly-inserted line "opens up" seems
somewhat disconcerting. As the sequence "A Esc O j Esc" shows, the
mode that vim is in during this one-second "window" doesn't appear to
properly be "insert mode", and so an opportunity for stray characters
to be inserted into the file appears to exist.
Similarly, the following sequences result in unexpected "+" and "-" being entered, so there appears to be enough scope for this behavior to cause typos or unexpected characters to be entered by a hurried typist:
A Esc O k Esc
Result:
+
A Esc O m Esc
Result:
-
I'm still looking into the vim sources, and also trying to understand
why the
TERM=xterm
setting influences this behavior, whereas with the setting
TERM=linux
vim works fine and the above sequences all give the expected result.
Is there a bugzilla or another way for reporting vim bugs? Please feel free to point me in the right direction.
I'm new to this list, and would like to help with vim in future.
Thanks, Peter.
Peter Knaggs [peter.knaggs at gmail.com]
Mon, 11 Dec 2006 15:26:24 -0800
On 12/9/06, Benjamin A. Okopnik <ben@linuxgazette.net> wrote:
> On Sat, Dec 09, 2006 at 07:21:37PM -0800, Peter Knaggs wrote: > > On 12/9/06, Benjamin A. Okopnik <ben@linuxgazette.net> wrote: > > > > > > > > Good job, Peter! You've hunted it down, clearly; I'd suggest reporting > > > it to the Vim maintainers.
OK. Here's the thread that was the result, it covers a lot of ground:
https://marc.theaimsgroup.com/?l=vim-dev&m=116578941422995&w=2 (Keep clicking on the "[next in thread]", it goes on for a ways).
The vim-dev folks are amazingly friendly and helpful, and explained the various aspects of the problem. The timeout behavior is needed because as you can see from ":set termcap" when TERM=xterm, there are a bunch of terminal keys whose escape sequence starts with Esc O, so vim has to wait for potentially more input before deciding there isn't any and opening up the new line in insert mode. The simplest workaround is to decrease the "ttimeoutlen" setting :set ttimeoutlen=250 when using TERM=xterm locally. Over remote connection, sticking with the vim defaults and waiting a bit after pressing Esc O would be safer.
Cheers, Peter.
Rick Moen [rick at linuxmafia.com]
Mon, 11 Dec 2006 18:21:55 -0800
Quoting Peter Knaggs (peter.knaggs@gmail.com):
> I'm here at Rick's conspire linux meeting, and got a lot of hints:
In case anyone's simultaneously confused by the above and also cares: There's a Linux user group called CABAL that, for quite a few years after losing its meeting space in San Francisco, has met, twice monthly, at my and my wife's house, about 60km south of S.F. It operates a mailing list called (what else?) "conspire".
Benjamin A. Okopnik [ben at linuxgazette.net]
Sat, 16 Dec 2006 18:23:56 -0600
On Mon, Dec 11, 2006 at 03:26:24PM -0800, Peter Knaggs wrote:
> On 12/9/06, Benjamin A. Okopnik <ben@linuxgazette.net> wrote: > > On Sat, Dec 09, 2006 at 07:21:37PM -0800, Peter Knaggs wrote: > > > On 12/9/06, Benjamin A. Okopnik <ben@linuxgazette.net> wrote: > > > > > > > > > > > Good job, Peter! You've hunted it down, clearly; I'd suggest reporting > > > > it to the Vim maintainers. > > OK. Here's the thread that was the result, it covers a lot of ground: > > https://marc.theaimsgroup.com/?l=vim-dev&m=116578941422995&w=2 > (Keep clicking on the "[next in thread]", it goes on for a ways). > > The vim-dev folks are amazingly friendly and helpful, and explained > the various aspects of the problem. The timeout behavior is needed > because as you can see from ":set termcap" when TERM=xterm, there > are a bunch of terminal keys whose escape sequence starts with Esc O, > so vim has to wait for potentially more input before deciding there isn't > any and opening up the new line in insert mode. > The simplest workaround is to decrease the "ttimeoutlen" setting > :set ttimeoutlen=250 > when using TERM=xterm locally. Over remote connection, sticking with > the vim defaults and waiting a bit after pressing Esc O would be safer.
Interesting that you'd have to do that - and now I know the reason that mine doesn't need it, although my TERM is indeed set to 'xterm'. I've just looked at the above setting in my Vim, and -
:set ttimeoutlen ttimeoutlen=-1According to Vim:
'ttimeoutlen' 'ttm' number (default -1)
global
{not in Vi}
The time in milliseconds that is waited for a key code or mapped key
sequence to complete. Also used for CTRL-\ CTRL-N and CTRL-\ CTRL-G
when part of a command has been typed.
Normally only 'timeoutlen' is used and 'ttimeoutlen' is -1. When a
different timeout value for key codes is desired set 'ttimeoutlen' to
a non-negative number.
[ ... ]
My 'timeoutlen' is set to 1000, but that does not appear to create the
problem you're describing.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Peter Knaggs [peter.knaggs at gmail.com]
Sat, 16 Dec 2006 23:11:28 -0800
On 12/16/06, Benjamin A. Okopnik <ben@linuxgazette.net> wrote:
> On Mon, Dec 11, 2006 at 03:26:24PM -0800, Peter Knaggs wrote: > > On 12/9/06, Benjamin A. Okopnik <ben@linuxgazette.net> wrote: > > > On Sat, Dec 09, 2006 at 07:21:37PM -0800, Peter Knaggs wrote: > > > > On 12/9/06, Benjamin A. Okopnik <ben@linuxgazette.net> wrote: > > > > > > > > > > > > > > Good job, Peter! You've hunted it down, clearly; I'd suggest reporting > > > > > it to the Vim maintainers. > > > > OK. Here's the thread that was the result, it covers a lot of ground: > > > > https://marc.theaimsgroup.com/?l=vim-dev&m=116578941422995&w=2 > > (Keep clicking on the "[next in thread]", it goes on for a ways). > > > > The vim-dev folks are amazingly friendly and helpful, and explained > > the various aspects of the problem. The timeout behavior is needed > > because as you can see from ":set termcap" when TERM=xterm, there > > are a bunch of terminal keys whose escape sequence starts with Esc O, > > so vim has to wait for potentially more input before deciding there isn't > > any and opening up the new line in insert mode. > > The simplest workaround is to decrease the "ttimeoutlen" setting > > :set ttimeoutlen=250 > > when using TERM=xterm locally. Over remote connection, sticking with > > the vim defaults and waiting a bit after pressing Esc O would be safer. > > Interesting that you'd have to do that - and now I know the reason that > mine doesn't need it, although my TERM is indeed set to 'xterm'. I've > just looked at the above setting in my Vim, and - > > `` > :set ttimeoutlen > ttimeoutlen=-1 > '' > > According to Vim: > > `` > 'ttimeoutlen' 'ttm' number (default -1) > global > {not in Vi} > The time in milliseconds that is waited for a key code or mapped key > sequence to complete. Also used for CTRL-\ CTRL-N and CTRL-\ CTRL-G > when part of a command has been typed. > Normally only 'timeoutlen' is used and 'ttimeoutlen' is -1. When a > different timeout value for key codes is desired set 'ttimeoutlen' to > a non-negative number. > > [ ... ] > '' > > My 'timeoutlen' is set to 1000, but that does not appear to create the > problem you're describing.
It involves some nifty-fast typing, but if you try this sequence over a few times in an empty vim session, you'll eventually get it to produce a "*" instead of the expected "j" if your TERM=xterm and you haven't modified the default timeoutlen or ttimeoutlen settings.
A Esc O j EscOne second seems like such a long time, but it even takes my fingers a while to "warm up" enough to get it to give me an "*".
The thread https://marc.theaimsgroup.com/?l=vim-dev&m=116578941422995&w=2 over on vim-dev shows some nifty tricks to type in the sequence really fast, using vim's ":normal" command, and ends with an explanation of where the mysterious "*" is coming from.
One way to be free of the bug by default is to use gvim, the graphical vim from the package "vim-gnome", but that seems overkill compared to just setting ttimeoutlen a little shorter. I've been setting it to 1 with no bad consequences thus far.