On Tue, May 02, 2006 at 09:04:06PM +0200, Bram Moolenaar wrote:
>
> Charles Campbell wrote:
>
> > >>This one appears to be a ctrl-f (and ctrl-b) bug. Here's the setup:
> > >>(using Linux,vim-7.0g, huge)
> > >>
> > >>.vimrc :
> > >> set nocp
> > >>
> > >>.gvimrc :
> > >> set lines=21
> > >>
> > >>no .vim/ directory.
> > >>
> > >>Now, for the problem:
> > >>
> > >>gvim -geometry "139x22+0+4" netrw.vim
> > >>11j<space>
> > >>z<cr>
> > >>4j<space>6k4j
> > >><ctrl-f>
> > >>
> > >>Note that the <ctrl-f> does not advance a page; instead, the cursor
> > >>returns to the top line (which is a fold). Similar misbehavior
> > >>happens with a ctrl-b. I have to use hit ctrl-e several times to move
> > >>the folds off the top; then, ctrl-f works again.
> > >
> > >I don't see the problem. Perhaps you can tell us what the display looks
> > >like after each command. I'm not sure I have the same version of
> > >netrw.vim (there have been quite a few!).
> > >
> > >Also, it's easier if you start with "gvim -u NONE -N ...".
> >
> > Using another command line option, I get the same misbehavior with
> > .vimrc and .gvimrc as shown above,
> >
> > gvim --noplugin -geometry "139x22+0+4" netrw.vim
> >
> > and using the same directions.
>
> If I do that I get all my vimrc settings, including 'scrolloff', and
> that probably avoids the problem you notice. Please start with "-u NONE
> -N", otherwise it's hard to reproduce. If you don't see it with "-u
> NONE -N" then there must be something on your system that triggers it.
> What?
Bram, maybe you missed Charles's "with .vimrc and .gvimrc as shown
above," which is almost as good as starting with -u NONE. But I agree
that I cannot reproduce the problem. I compiled with huge features on
Linux/GTK2 and started gvim with
$ gvim -u NONE -U NONE --noplugin -geometry "139x22+0+4" +"set nocp
lines=21" ../runtime/autoload/netrw.vim
and tried the experiment, did not see anything unusual.
HTH --Benji Fisher
