nmap <Space> i<Space><Esc>
It lets me enter spaces without leaving normal mode.
Or used to ..
Fairly recently, this stopped working as expected:
What happens if I hit space in normal mode, is that vim inserts an
unlimited number of spaces, apparently one at a time.
I could be wrong about this, but it happens rather quickly and I can't
think of a way to have it played in slow motion.
What I see is this:
Say I have one line in my buffer with these characters:
abcdef
^
The cursor is on the 'd'.
If I hit <Space>, the 'def' start moving rapidly to the right, on to the
next line, etc. until it disappears at the bottom of the screen.
I have to hit Ctrl-C for this to stop.
I have verified via the 'ga' command that the characters that are
inserted are indeed spaces (0x20) not lookalikes.
The spaces are inserted at a rate of about 100 per second on my machine
and when this happens, Vim immediately starts using all the CPU.
:map lists the mapping for <Space> exactly as it is in my .vimrc.
Starting vim --no-plugin doesn't make any difference but vim -u with a
quasi-empty .vimrc does.
Any suggestions as to how I could have vim tell me what it is actually
doing when this happens?
Thanks,
CJ
make an almost null .vimrc, which you seem to have done, then
gradually add stuff from your real .vimrc back to the one you are
using, testing each time, til you see the weird behavior
space could be mapped other places, and my first reaction was to
say woah, you should be using nnoremap, but i don't presume to
know what is going on with this
test with incrementally more relevant .vimrcs, is the best i can
recommend
sc
Did you mean nnoremap?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> make an almost null .vimrc, which you seem to have done, then
> gradually add stuff from your real .vimrc back to the one you are
> using, testing each time, til you see the weird behavior
Yes I did that.
I would probably leave out about half of the existing stuff and test,
etc. otherwise this is going to take forever.
> space could be mapped other places, and my first reaction was to
> say woah, you should be using nnoremap, but i don't presume to
> know what is going on with this
But shouldn't :map tell me if it's mapped elsewhere?
CJ
I must have seen that 'nmap' was for normal mode and since it worked at
the time, I didn't read the rest of the manual :-)
Generally speaking, I don't remap much of anything and as a result, I
know very little about it.
As recommended (and after having read the relevant bits in the manual,
in particular usr_40.txt, I tried to change the mapping to:
nnoremap <Space> i<Space><Esc>
I started a vim instance, and saw that this had taken care of the crazy
animation, only one space is now inserted, but there's another strange
issue.
Not only is a space inserted when hitting the space bar in normal mode,
but the cursor is moved forward what looks like 12 characters, or to the
end of the line if there are less than 12 characters in the buffer:
If I have this in the buffer:
1234567890
1234567890 1234567890
With the cursor on line 1, column 1, after hitting the space bar, a
single space is inserted and everything else in line 1 is moved one
column to the right:
1234567890
1234567890 1234567890
^
But something I didn't except happens: the cursor ends up over the '3'
in line 2 ..!!!
If I undo and move the cursor to the '2' on line 1, column 2, I end up
with the cursor over the '4' in line 2, etc.
1 234567890
1234567890 1234567890
^
It looks like the cursor jumps 12 characters/cells forward after
completing the space insertion.
Must be some side-effect of something I have 'set' in my .vimrc, but I
can't think of what.
Thanks,
CJ
you don't have 12 spaces after your nnoremap command, do you? I.e.,
:nnoremap <Space> i<Space><Esc>____________
where every underscore means a literal space character. If that's the
case and the 'whichwrap' option includes a lower case 's' your mapping
would move 12 characters to the right, continuing in the next line if
the current line is not long enough.
Regards,
Jürgen
--
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us. (Calvin)
Excellent catch!
> you don't have 12 spaces after your nnoremap command, do you? I.e.,
>
> :nnoremap <Space> i<Space><Esc>____________
My mistake, there are thirteen of them :-)
> where every underscore means a literal space character. If that's the
> case and the 'whichwrap' option includes a lower case 's' your mapping
> would move 12 characters to the right, continuing in the next line if
> the current line is not long enough.
I certainly do.
Now, let me read all about the 's' in 'set whichwrap' and see if I can
get rid of it - since I'd rather like to keep a comment in my .vimrc,
like so:
nnoremap <Space> i<Space><Esc> " what this does..
I don't suppose I could escape all these spaces and stick with my
current whichwrap?
CJ
Chris Jones wrote:
>
> Now, let me read all about the 's' in 'set whichwrap' and see if I can
> get rid of it - since I'd rather like to keep a comment in my .vimrc,
> like so:
>
> nnoremap <Space> i<Space><Esc> " what this does..
it's best to never write a comment after a mapping -- just put it in a
separate line above or below.
Apart from the additional movement this line also results in an error,
because the space after the quote character is not a valid register
name. You should have heard a beep or seen Vim's window flash.
If you really want to put the comment on the same line insert a bar
immediately after the last character of you mapping, i.e.,
nnoremap <Space> i<Space><Esc>| " what this does..
The bar ends the nnoremap and starts a new command -- which solely
consists of a single comment.
[..]
> > nnoremap <Space> i<Space><Esc> " what this does..
>
> it's best to never write a comment after a mapping -- just put it in a
> separate line above or below.
That habit of mine is going to be difficult to break.
> Apart from the additional movement this line also results in an error,
> because the space after the quote character is not a valid register
> name. You should have heard a beep or seen Vim's window flash.
Beeping and visual bells have been disabled for so long here that I
don't even remember how I did it. And all the time I had a feeling it
would come back and bite me at some point.
> If you really want to put the comment on the same line insert a bar
> immediately after the last character of you mapping, i.e.,
>
> nnoremap <Space> i<Space><Esc>| " what this does..
Perfect. Although, now I don't have enough space left on the line to
make a note of what that bar is for.. :-)
> The bar ends the nnoremap and starts a new command -- which solely
> consists of a single comment.
I was a bit suprised to see that the :map command displayed the comment
from my .vimrc but I failed to put two and two together: since the
output of :map showed my comment, I should have suspected that vim
considered it part of the mapping, not a comment.
Thanks,
CJ
This map looks quite recursive; the i<Space> invokes the map again
(recursively), and repeats ad infinitum. Seems to me you want a
no-remap; try
nno <Space> i<Space><Esc>
Haven't tested this, though, and I haven't finished reading all the
other replies yet (so this may be a repeat!)
Regards,
Chip Campbell
[..]
> This map looks quite recursive; the i<Space> invokes the map again
> (recursively), and repeats ad infinitum. Seems to me you want a
> no-remap; try
> nno <Space> i<Space><Esc>
> Haven't tested this, though, and I haven't finished reading all the
> other replies yet (so this may be a repeat!)
Yes, that's definitely what caused the initial problem with the
recursive insertion of spaces. Someone else recommended :nno and I did a
bit of reading on the subject. It hadn't occurred to me that having
<Space> in both halves of the remap would cause recursion :-\
What started this in the first place, is that a couple of months ago, I
decided to tidy up my .vimrc and among many other different things I
blissfully decided to change:
:nmap <Space> i <Esc>
to:
:nmap <Space> i<Space><Esc>
This looked pretty harmless and I remember thinking that it would look
much 'cleaner' to have explicitly coded <Space> rather than a literal
space, because the literal space being by nature invisible, it could be
a space, a tab, or any other non-printable character.
I went back to the first version above just to make sure I understood
the whole thing, and verified via a test that the first :nmap version of
the mapping does not cause recursion. That's why it had worked without
problems for at least a year.
Naturally, by the time I had finished tidying up my .vimrc and
eventually noticed the crazy animation sequence where hitting <Space> in
normal mode in the middle of a line caused all following text to start
running away rightwards at something like a hundred characters per
seconds, well, I had made so many changes in my .vimrc that I didn't
even remember having touched that mapping.
For the record, it's even worse when you are at the end of a file, and
there is nothing visible after the cursor because what happens is that
the cursor disappears. So I had not clue what was happening since I
didn't see anything. Only that vim had become unresponsive. Purely by
accident, I found that hitting Ctrl-C would take me out of this funny
mode and that an undo appeared to clear up any changes to the buffer.
But I was still a quantum step away from suspecting what was going on.
It just goes to show, that I should have taken it one step at time and
tested each individual change like a pro :-\
It's only after I changed the mapping to
:nnoremap <Space> i<Space><Esc> " some comment
that I ran into the second unrelated problem where the map command not
being immediately terminated by an <eol> - caused the cursor to jump
forward thirteen columns.
I never imagined even trivial mappings could be that tricky and cause so
much grief!
Thank you for your comments, and thanks to all who helped me straighten
this out!
CJ
thanks for the instructive lesson on small causes and big effects!
jan