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

Re: virtualedit bug

Expand Messages
  • A. J. Mechelynck
    ... [...] 1. Not even in visual block mode? (I can.) If you can move the cursor in visual block mode, then there is no bug, see :help virtualedit . 2. If
    Message 1 of 5 , Mar 1, 2006
      Ralf Wildenhues wrote:
      > I noted a regression introduced recently:
      >
      > With a ~/.vimrc containing only
      >
      > set nocompatible
      > if has("virtualedit")
      > set virtualedit=block
      > endif
      >
      > no other own configuration files, and then typing
      > vim
      > i[
      >
      > the cursor does not move past the inserted bracket. It is not possible with
      > movements to get behind the bracket. Same with parentheses.
      >
      > Please Cc: me on replies -- thanks.
      >
      > Cheers,
      > Ralf
      >
      > :ve
      > VIM - Vi IMproved 7.0aa ALPHA (2006 Feb 28, compiled Mar 1 2006 13:09:39)
      > Compiled by ralf@localhost
      > Normal version with GTK2 GUI. Features included (+) or not (-):
      [...]

      1. Not even in visual block mode? (I can.) If you can move the cursor in
      visual block mode, then there is no bug, see ":help 'virtualedit'".
      2. If you can't move the cursor past the end in visual block mode when
      the last character is a (round, square or curly) bracket, then does it
      change something if you invoke gvim with the --noplugin command-line option?
      3. If it does, does it make a difference if (without --noplugin) you
      execute the ex-command

      :NoMatchParen

      defined in a very recent new plugin?
      4. If it does, then $VIMRUNTIME/plugin/matchparen.vim is the culprit. It
      was "last modified" on 27 February; I didn't notice its action before
      that date. Its help file is pi_paren.txt. If you know Vim script
      language well enough, you may try to fix the bug.


      Note: I'm not seeing that bug on my W32 "big" gvim version of the same
      date as yours.



      Best regards,
      Tony.
    • Ralf Wildenhues
      Hi Tony, ... In visual block mode, I can move past it. But not in Insert Mode. ... Yes, there is a bug. Starting in Normal Mode, I type ia[bESC and the line
      Message 2 of 5 , Mar 1, 2006
        Hi Tony,

        A. J. Mechelynck <antoine.mechelynck <at> skynet.be> writes:
        > Ralf Wildenhues wrote:
        > >
        > > typing
        > > vim
        > > i[
        > >
        > > the cursor does not move past the inserted bracket. It is not possible with
        > > movements to get behind the bracket. Same with parentheses.

        > 1. Not even in visual block mode? (I can.)

        In visual block mode, I can move past it. But not in Insert Mode.

        > If you can move the cursor in
        > visual block mode, then there is no bug, see ":help 'virtualedit'".

        Yes, there is a bug. Starting in Normal Mode, I type
        ia[bESC

        and the line contains three characters "ab[" in that order.

        > 2. If you can't move the cursor past the end in visual block mode when
        > the last character is a (round, square or curly) bracket, then does it
        > change something if you invoke gvim with the --noplugin command-line option?

        Yes. "vim --noplugin" seems to work as expected.

        [ Aside: I never use the GUI version, but that does not make a difference ]

        > 3. If it does, does it make a difference if (without --noplugin) you
        > execute the ex-command
        >
        > :NoMatchParen
        >
        > defined in a very recent new plugin?

        Yes, that seems to make it work as expected, too.

        > 4. If it does, then $VIMRUNTIME/plugin/matchparen.vim is the culprit.

        Ah, thanks. So I can reproduce this now with this sequence:
        vim -u NONE
        :set nocompatible virtualedit=block
        :so $VIMRUNTIME/plugin/matchparen.vim

        > If you know Vim script
        > language well enough, you may try to fix the bug.

        Let's see. The problem seems to go away if I comment out both line 85:
        call cursor(c_lnum, c_col - before)
        and line 90:
        exe 'normal ' . vcol . '|'

        The problem seems to go away if I change line 90 to be
        call cursor(0, vcol)
        instead of the normal mode command. I believe the normal mode command is
        wrong here, because we are in Insert Mode, but the vcol is not accessible
        in normal mode by the '|' movement as it's after the last character in the
        line.

        I hope this babble made a bit of sense to someone more knowledgeable.
        There is a comment above the code in question that should be adjusted, too.

        Cheers, and thanks for the quick reply!
        Ralf
      • Bram Moolenaar
        ... It is caused by the new matchparen plugin. You can disable it with :NoMatchParen . Or include this patch: diff -u -r1.1 matchparen.vim ... +++
        Message 3 of 5 , Mar 1, 2006
          Ralf Wildenhues wrote:

          > I noted a regression introduced recently:
          >
          > With a ~/.vimrc containing only
          >
          > set nocompatible
          > if has("virtualedit")
          > set virtualedit=block
          > endif
          >
          > no other own configuration files, and then typing
          > vim
          > i[
          >
          > the cursor does not move past the inserted bracket. It is not possible with
          > movements to get behind the bracket. Same with parentheses.

          It is caused by the new matchparen plugin. You can disable it with
          ":NoMatchParen". Or include this patch:

          diff -u -r1.1 matchparen.vim
          --- ../runtime/plugin/matchparen.vim 27 Feb 2006 23:47:59 -0000 1.1
          +++ ../runtime/plugin/matchparen.vim 1 Mar 2006 14:10:34 -0000
          @@ -81,6 +81,8 @@
          if before > 0
          if &ve != ''
          let vcol = virtcol('.')
          + let old_ve = &ve
          + set ve=all
          endif
          call cursor(c_lnum, c_col - before)
          endif
          @@ -88,6 +90,7 @@
          if before > 0
          if &ve != ''
          exe 'normal ' . vcol . '|'
          + let &ve = old_ve
          else
          call cursor(0, c_col)
          endif


          --
          Anyone who is capable of getting themselves made President should on no
          account be allowed to do the job.
          -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

          /// 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://www.ICCF.nl ///
        • Ralf Wildenhues
          Hi Bram, ... Yes. Both the patch and the command fix the issue I observed. Thanks! Ralf
          Message 4 of 5 , Mar 1, 2006
            Hi Bram,

            Bram Moolenaar <Bram <at> moolenaar.net> writes:
            >
            > It is caused by the new matchparen plugin. You can disable it with
            > ":NoMatchParen". Or include this patch:

            Yes. Both the patch and the command fix the issue I observed.

            Thanks!
            Ralf
          Your message has been successfully submitted and would be delivered to recipients shortly.