Up/Down U and D keys work weird

[James Beck]

Hi,

Ever since I started using Vim (years ago), I've noticed that (very)
infrequently, the Ctrl+u (up a half-page) and Ctrl+d (down a half-page)
commands behave strangely. For example, right at this moment, when I press
Ctrl+u, the page scrolls up 5 lines (instead of 25 or so). But Ctrl+d
works like normal. Wait, now Ctrl+d is doing the same thing! It was
working five seconds ago!

So you can see why this is driving me nuts.

Oooh, even more weird, it's misbehaving in ONE window, but not the other!
Same buffer, different window. And if I press Ctrl+W, R, to switch the
windows around, the behavior follows the window! In other words, now it's
happening in the left window instead of the right.

I've always assumed it was my terminal. But after three separate terminals
running in Windows, CentOS, and Kubuntu, it's happening in all of them.
What the heck key am I accidentally pressing that's putting Vim in
"act-weird-mode"?

Thanks!
James

[Tim Chase]

This doesn't sound "normal" and I can see how it would drive you
bonkers :)

Given that I've never experienced anything like this in the 10+
years I've been vimming, my first suspicion is that it's some
sort of plugin/filetype issue. A couple questions:

- does it occur in one file-type in particular or in multiple
file-types? (only with Ruby source files; only with Apache config
files, etc)

- do you have any plugins/scripts enabled? (and correspondingly,
does it ever happen if you start vim with no plugins/vimrc loaded?)

- as an off-chance, do you ever have issues with those key-chords
in other applications (such as underlining with ^U in word
processors)? You mention using Win32, CentOS, and Kubuntu, but
you don't mention whether they're in VMs or multi-boot on the
same box (and thus the same potentially flaky hardware) or if
they're each separate machines with their own hardware. I've had
keyboards where a modifier key such as ctrl/shift/alt/win/meta
was stuck and I had to slap it around to free it up. Or perhaps
if you have a snazzy "enhanced" keyboard that tries to do smart
macro-ish things with certain keystrokes.

- since the behavior follows the window focus, do you have any
WinEnter/WinLeave or Buf* events defined?

If the answers to the above questions don't help indicate
anything obvious, it might help to post your vimrc file(s) and
perhaps a dump of your $HOME/.vim directory listing ("find
~/.vim" or "dir /s/b %USERPROFILE%\vimfiles" something like that)
to see if there's anything glaringly suspicious.

-tim

[Tony Mechelynck]

Put the cursor in Normal mode in the misbehaving window, then type

:verbose map <C-U>
:verbose map <C-D>
:verbose set scroll?

It could be either that something set a buffer-local mapping, or that
you inadvertently pressed a digit key just before the Ctrl-U or Ctrl-D.

See also
:help CTRL-U
:help CTRL-D
:help 'scroll'

Best regards,
Tony.
--
"One basic notion underlying Usenet is that it is a cooperative."

Having been on USENET for going on ten years, I disagree with this.
The basic notion underlying USENET is the flame.
-- Chuq Von Rospach

[Bill Hudacek]

Tim Chase related the following on 03/22/2010 10:57 AM:

> James Beck wrote:
>
>> Ever since I started using Vim (years ago), I've noticed that (very)
>> infrequently, the Ctrl+u (up a half-page) and Ctrl+d (down a half-page)
>> commands behave strangely. For example, right at this moment, when I press
>> Ctrl+u, the page scrolls up 5 lines (instead of 25 or so). But Ctrl+d
>> works like normal. Wait, now Ctrl+d is doing the same thing! It was
>> working five seconds ago!
>>
>> So you can see why this is driving me nuts.
>>
>> Oooh, even more weird, it's misbehaving in ONE window, but not the other!
>> Same buffer, different window. And if I press Ctrl+W, R, to switch the
>> windows around, the behavior follows the window! In other words, now it's
>> happening in the left window instead of the right.
>>
>> I've always assumed it was my terminal. But after three separate terminals
>> running in Windows, CentOS, and Kubuntu, it's happening in all of them.
>> What the heck key am I accidentally pressing that's putting Vim in
>> "act-weird-mode"?
>>
>
>

I believe this is one of those commands that takes a repeat number
before the command.

Further, if you type 8 C-U ALL control-U (AND control-D) key strikes
henceforth will scroll 8 lines.

From help:

CTRL-U Scroll window Upwards in the buffer. The number of
lines comes from the 'scroll' option (default: half a
screen). If [count] given, first set the 'scroll'
option to [count]. The cursor is moved the same
number of lines up in the file (if possible; when
lines wrap and when hitting the end of the file there
may be a difference). When the cursor is on the first
line of the buffer nothing happens and a beep is
produced. See also 'startofline' option.
{difference from vi: Vim scrolls 'scroll' screen
lines, instead of file lines; makes a difference when
lines wrap}

/Bill

[James Beck]

> I believe this is one of those commands that takes a repeat number
> before the command.
>
> Further, if you type 8 C-U ALL control-U (AND control-D) key strikes
> henceforth will scroll 8 lines.

HA! That is correct! And that makes it behave like I was experiencing.
AND, that's something I tend to do (infrequently) with other commands. I
understand now what Tony was talking about.

I did NOT expect Ctrl-U/D to act like this. Why is the number persistent?
Normally, the number represents the current action, not all future actions.

James

[Charles Campbell]

Well, I'd expect [count]Ctrl-U (or -D) would repeat ctrl-u [count]
times; that doesn't happen, of course. So it is an oddity -- but it
also is vi compatible behavior. Thus, its not going to be changed.
C'est la vie!

Regards,
Chip Campbell