Loading ...
Sorry, an error occurred while loading the content.

gvim + X + geometry + set line + cttrl-f + folding (whew!) : a bug

Expand Messages
  • Charles E. Campbell, Jr.
    Hello! 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/
    Message 1 of 5 , May 1, 2006
    • 0 Attachment
      Hello!

      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.

      Regards,
      Chip Campbell
    • Bram Moolenaar
      ... 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
      Message 2 of 5 , May 2, 2006
      • 0 Attachment
        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 ...".

        --
        ARTHUR: Be quiet! I order you to shut up.
        OLD WOMAN: Order, eh -- who does he think he is?
        ARTHUR: I am your king!
        OLD WOMAN: Well, I didn't vote for you.
        "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ download, build and distribute -- http://www.A-A-P.org ///
        \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
      • Charles E Campbell Jr
        ... 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
        Message 3 of 5 , May 2, 2006
        • 0 Attachment
          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.

          Regards,
          Chip Campbell
        • Bram Moolenaar
          ... 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 ,
          Message 4 of 5 , May 2, 2006
          • 0 Attachment
            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?

            --
            The only way the average employee can speak to an executive is by taking a
            second job as a golf caddie.
            (Scott Adams - The Dilbert principle)

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
            \\\ download, build and distribute -- http://www.A-A-P.org ///
            \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
          • Benji Fisher
            ... 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
            Message 5 of 5 , May 8, 2006
            • 0 Attachment
              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
            Your message has been successfully submitted and would be delivered to recipients shortly.