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

matchparen bug?

Expand Messages
  • Jared
    I think I found a bug in in the matchparen feature of Vim 7. I m using the 7.0 binary release for Windows XP. When I m in Insert mode and moving across lines,
    Message 1 of 13 , Jun 1, 2006
    • 0 Attachment
      I think I found a bug in in the matchparen feature of Vim 7. I'm using the
      7.0 binary release for Windows XP.

      When I'm in Insert mode and moving across lines, if the cursor passes over a
      paren (defined here as any character in the matchpairs option), the cursor
      will stay in the column position when moving to the next line. See the
      following code for an example:

      let g:loaded_autoit_completion = 1
      let s:cache_name = []
      " This function is used for the 'omnifunc' option.

      Now, if my cursor is on the '1' in the first line and I press down twice,
      I'd expect the cursor to end up on the 'o' in 'omnifunc' in the third line.
      However, if I'm in Insert mode and matchparen is active, then my cursor
      will instead end up on the 'e' in 'used'.

      If I'm in Normal mode, this does not happen. If I issue :NoMatchParen, this
      does not happen. However, if I reissue :DoMatchParen and enter Insert mode,
      the problem reoccurs.

      Can anyone else confirm this? I do have a lot of customizations in my vimrc
      files, so I'm not entirely sure it's not a problem that I'm causing myself,
      but I've reviewed my vimrc pretty carefully and I can't find anything that
      should cause this issue. If anyone else would like to check, you can find
      both vimrc files here:

      http://www.legroom.net/~jbreland/transfer/Packages/Vim_7.0/support/_vimrc
      http://www.legroom.net/~jbreland/transfer/Packages/Vim_7.0/support/_gvimrc

      Please let me know if this is an actual Vim bug. Thanks.

      --
      Jared
    • Ilya
      ... I do not have this bug. I m having VIM - Vi IMproved 7.0 (2006 May 7, compiled May 25 2006 04:17:33) MS-Windows 32 bit GUI version with OLE support
      Message 2 of 13 , Jun 1, 2006
      • 0 Attachment
        Jared wrote:
        > [...]
        > When I'm in Insert mode and moving across lines, if the cursor passes over a
        > paren (defined here as any character in the matchpairs option), the cursor
        > will stay in the column position when moving to the next line. See the
        > following code for an example:
        >
        > let g:loaded_autoit_completion = 1
        > let s:cache_name = []
        > " This function is used for the 'omnifunc' option.
        >
        > Now, if my cursor is on the '1' in the first line and I press down twice,
        > I'd expect the cursor to end up on the 'o' in 'omnifunc' in the third line.
        > However, if I'm in Insert mode and matchparen is active, then my cursor
        > will instead end up on the 'e' in 'used'.
        >
        > [...]
        I do not have this bug.

        I'm having

        VIM - Vi IMproved 7.0 (2006 May 7, compiled May 25 2006 04:17:33)
        MS-Windows 32 bit GUI version with OLE support
        Included patches: 1-17

        that I've compiled myself from current CVS version.

        Matchparen.vim is dated 2006 May 11.
      • Benji Fisher
        ... I can reproduce it. Perhaps we just need more explicit instructions on how to reproduce it. Using the text above, go to the g:loaded_autoit_completion
        Message 3 of 13 , Jun 5, 2006
        • 0 Attachment
          On Thu, Jun 01, 2006 at 10:16:44PM +0300, Ilya wrote:
          > Jared wrote:
          > >[...]
          > >When I'm in Insert mode and moving across lines, if the cursor passes over
          > >a
          > >paren (defined here as any character in the matchpairs option), the cursor
          > >will stay in the column position when moving to the next line. See the
          > >following code for an example:
          > >
          > >let g:loaded_autoit_completion = 1
          > >let s:cache_name = []
          > >" This function is used for the 'omnifunc' option.
          > >
          > >Now, if my cursor is on the '1' in the first line and I press down twice,
          > >I'd expect the cursor to end up on the 'o' in 'omnifunc' in the third line.
          > > However, if I'm in Insert mode and matchparen is active, then my cursor
          > >will instead end up on the 'e' in 'used'.
          > >
          > >[...]
          > I do not have this bug.

          I can reproduce it. Perhaps we just need more explicit
          instructions on how to reproduce it. Using the text above, go to the
          g:loaded_autoit_completion line and (starting in Normal mode) type

          $i<Down><Down>

          to reproduce.

          I can see the problem in $VIMRUNTIME/plugin/matchparen.vim . In
          this situation, the plugin moves the cursor left one character, onto the
          "]", and then back. When this happens, vim forgets that it is trying to
          keep the cursor in the same column as the "1".

          I do not see any way to fix this in the plugin. Perhaps the
          getpos() and setpos() functions can be changed so that they will keep
          the information that is being lost.

          HTH --Benji Fisher
        • Ilya
          ... Hm, strange, but it does not happen to me, even if I do as you say.... My action: 1. Open gvim. 2. Paste text from first mail. 3. $i and cursor
          Message 4 of 13 , Jun 5, 2006
          • 0 Attachment
            Benji Fisher wrote:
            > I can reproduce it. Perhaps we just need more explicit
            > instructions on how to reproduce it. Using the text above, go to the
            > g:loaded_autoit_completion line and (starting in Normal mode) type
            >
            > $i<Down><Down>
            >
            > to reproduce.
            >
            > I can see the problem in $VIMRUNTIME/plugin/matchparen.vim . In
            > this situation, the plugin moves the cursor left one character, onto the
            > "]", and then back. When this happens, vim forgets that it is trying to
            > keep the cursor in the same column as the "1".
            >
            > I do not see any way to fix this in the plugin. Perhaps the
            > getpos() and setpos() functions can be changed so that they will keep
            > the information that is being lost.
            >
            > HTH --Benji Fisher
            >
            Hm, strange, but it does not happen to me, even if I do as you say....

            My action:
            1. Open gvim.
            2. Paste text from first mail.
            3. $i<Down><Down>

            and cursor is to the left of 'o' in 'onmifunc'.
          • Benji Fisher
            ... Perhaps you have set matchpairs so that it does not include [:] ? Since you snipped the three sample lines, here is another example: long line ()
            Message 5 of 13 , Jun 6, 2006
            • 0 Attachment
              On Mon, Jun 05, 2006 at 04:24:38PM +0300, Ilya wrote:
              > Benji Fisher wrote:
              > > I can reproduce it. Perhaps we just need more explicit
              > >instructions on how to reproduce it. Using the text above, go to the
              > >g:loaded_autoit_completion line and (starting in Normal mode) type
              > >
              > > $i<Down><Down>
              > >
              > >to reproduce.
              > >
              > > I can see the problem in $VIMRUNTIME/plugin/matchparen.vim . In
              > >this situation, the plugin moves the cursor left one character, onto the
              > >"]", and then back. When this happens, vim forgets that it is trying to
              > >keep the cursor in the same column as the "1".
              > >
              > > I do not see any way to fix this in the plugin. Perhaps the
              > >getpos() and setpos() functions can be changed so that they will keep
              > >the information that is being lost.
              > >
              > >HTH --Benji Fisher
              > >
              > Hm, strange, but it does not happen to me, even if I do as you say....
              >
              > My action:
              > 1. Open gvim.
              > 2. Paste text from first mail.
              > 3. $i<Down><Down>
              >
              > and cursor is to the left of 'o' in 'onmifunc'.

              Perhaps you have set 'matchpairs' so that it does not include
              "[:]"? Since you snipped the three sample lines, here is another
              example:

              long line
              ()
              another

              After going to "long line" and doing $i<Down> do you have the cursor
              after the parentheses, with the parentheses highlighted?

              HTH --Benji Fisher
            • Ilya
              ... matchpairs does include [:] - as by default. And brackets are highlighted when cursor is near one of them. ... Yes, I do. And after doing I have
              Message 6 of 13 , Jun 6, 2006
              • 0 Attachment
                Benji Fisher wrote:
                > Perhaps you have set 'matchpairs' so that it does not include
                > "[:]"?
                matchpairs does include "[:]" - as by default. And brackets are
                highlighted when cursor is near one of them.
                > Since you snipped the three sample lines, here is another
                > example:
                >
                > long line
                > ()
                > another
                >
                > After going to "long line" and doing $i<Down> do you have the cursor
                > after the parentheses, with the parentheses highlighted?
                >
                Yes, I do. And after doing <Down> I have cursor after 'r' in 'another'.
                > HTH --Benji Fisher
                >
                >
                >
              • Benji Fisher
                ... I am stumped. I tried it with $ vim -u NONE ... and I still get the cursor on the o in the third line. --Benji Fisher
                Message 7 of 13 , Jun 6, 2006
                • 0 Attachment
                  On Tue, Jun 06, 2006 at 05:11:13PM +0300, Ilya wrote:
                  > Benji Fisher wrote:
                  > > Perhaps you have set 'matchpairs' so that it does not include
                  > >"[:]"?
                  > matchpairs does include "[:]" - as by default. And brackets are
                  > highlighted when cursor is near one of them.
                  > > Since you snipped the three sample lines, here is another
                  > >example:
                  > >
                  > > long line
                  > > ()
                  > > another
                  > >
                  > >After going to "long line" and doing $i<Down> do you have the cursor
                  > >after the parentheses, with the parentheses highlighted?
                  > >
                  > Yes, I do. And after doing <Down> I have cursor after 'r' in 'another'.

                  I am stumped. I tried it with

                  $ vim -u NONE
                  :set nocp
                  :runtime plugin/matchparen.vim

                  and I still get the cursor on the "o" in the third line.

                  --Benji Fisher
                • Gary Johnson
                  ... I haven t been following this discussion very closely, but I just tried the experiment on Red Hat Linux 9, SunOS 5.8 and Windows XP with vim 7.0, no
                  Message 8 of 13 , Jun 7, 2006
                  • 0 Attachment
                    On 2006-06-07, Jared <list-vim@...> wrote:
                    > On 06/06/2006 23:47, Benji Fisher wrote:
                    > > I am stumped. I tried it with
                    > >
                    > > $ vim -u NONE
                    > > :set nocp
                    > > :runtime plugin/matchparen.vim
                    > >
                    > > and I still get the cursor on the "o" in the third line.
                    >
                    > Benji, Ilya,
                    >
                    > I appreciate both of you taking the time to investigate. I'm a little
                    > puzzled why Benji and I are seeing this issue, but Ilya is not.
                    >
                    > Can anyone else either confirm or refute this? Is it perhaps a
                    > Windows-specific bug? I only currently have access to Vim 7 on a Windows
                    > system, so I'm unable to test it under Linux.

                    I haven't been following this discussion very closely, but I just
                    tried the experiment on Red Hat Linux 9, SunOS 5.8 and Windows XP
                    with vim 7.0, no patches, and the cursor always goes to the 'o' in
                    the third line. Is that what you were looking for?

                    HTH,
                    Gary

                    --
                    Gary Johnson | Agilent Technologies
                    garyjohn@... | Wireless Division
                    | Spokane, Washington, USA
                  • Jared
                    ... Which test case are you using? My original snippet: let g:loaded_autoit_completion = 1 let s:cache_name = [] This function is used for the omnifunc
                    Message 9 of 13 , Jun 7, 2006
                    • 0 Attachment
                      On 06/07/2006 15:10, Gary Johnson wrote:
                      > On 2006-06-07, Jared <list-vim@...> wrote:
                      > I haven't been following this discussion very closely, but I just
                      > tried the experiment on Red Hat Linux 9, SunOS 5.8 and Windows XP
                      > with vim 7.0, no patches, and the cursor always goes to the 'o' in
                      > the third line. Is that what you were looking for?

                      Which test case are you using? My original snippet:

                      let g:loaded_autoit_completion = 1
                      let s:cache_name = []
                      " This function is used for the 'omnifunc' option.

                      Or Benji's:

                      long line
                      ()
                      another

                      Reason I'm asking is because if you're using mine, then you do NOT see the
                      bug. If you're using Benji's then you do see the bug. It's an unfortunate
                      coincidence that 'o' signifies a success in one case but a failure in the other.

                      Thanks.

                      --
                      Jared
                    • Gary Johnson
                      ... I was using Benji s. To be precise, I started vim at the shell prompt in Unix and at the Command Prompt in Windows as vim -u NONE Then I executed ... Then
                      Message 10 of 13 , Jun 7, 2006
                      • 0 Attachment
                        On 2006-06-07, Jared <list-vim@...> wrote:
                        > On 06/07/2006 15:10, Gary Johnson wrote:
                        > > On 2006-06-07, Jared <list-vim@...> wrote:
                        > > I haven't been following this discussion very closely, but I just
                        > > tried the experiment on Red Hat Linux 9, SunOS 5.8 and Windows XP
                        > > with vim 7.0, no patches, and the cursor always goes to the 'o' in
                        > > the third line. Is that what you were looking for?
                        >
                        > Which test case are you using? My original snippet:
                        >
                        > let g:loaded_autoit_completion = 1
                        > let s:cache_name = []
                        > " This function is used for the 'omnifunc' option.
                        >
                        > Or Benji's:
                        >
                        > long line
                        > ()
                        > another
                        >
                        > Reason I'm asking is because if you're using mine, then you do NOT see the
                        > bug. If you're using Benji's then you do see the bug. It's an unfortunate
                        > coincidence that 'o' signifies a success in one case but a failure in the other.

                        I was using Benji's. To be precise, I started vim at the shell
                        prompt in Unix and at the Command Prompt in Windows as

                        vim -u NONE

                        Then I executed

                        :set nocp

                        Then I either typed or pasted

                        long line
                        ()
                        another

                        and deleted the empty line 4, if present, so that the buffer
                        contained only those three lines. Then I executed

                        :runtime plugin/matchparen.vim

                        And finally, I moved the cursor to the first line, typed

                        $i<down><down>

                        and the cursor went to the 'o' in 'another' in all three cases.

                        Regards,
                        Gary

                        --
                        Gary Johnson | Agilent Technologies
                        garyjohn@... | Wireless Division
                        | Spokane, Washington, USA
                      • Benji Fisher
                        ... I call that reproducing the bug. That makes three of us who see the bug, one who does not. Looking at the plugin, I think I understand what causes it. I
                        Message 11 of 13 , Jun 7, 2006
                        • 0 Attachment
                          On Wed, Jun 07, 2006 at 03:07:49PM -0700, Gary Johnson wrote:
                          > On 2006-06-07, Jared <list-vim@...> wrote:
                          > > On 06/07/2006 15:10, Gary Johnson wrote:
                          > > > On 2006-06-07, Jared <list-vim@...> wrote:
                          > > > I haven't been following this discussion very closely, but I just
                          > > > tried the experiment on Red Hat Linux 9, SunOS 5.8 and Windows XP
                          > > > with vim 7.0, no patches, and the cursor always goes to the 'o' in
                          > > > the third line. Is that what you were looking for?
                          > >
                          > > Which test case are you using? My original snippet:
                          > >
                          > > let g:loaded_autoit_completion = 1
                          > > let s:cache_name = []
                          > > " This function is used for the 'omnifunc' option.
                          > >
                          > > Or Benji's:
                          > >
                          > > long line
                          > > ()
                          > > another
                          > >
                          > > Reason I'm asking is because if you're using mine, then you do NOT see the
                          > > bug. If you're using Benji's then you do see the bug. It's an unfortunate
                          > > coincidence that 'o' signifies a success in one case but a failure in the other.
                          >
                          > I was using Benji's. ...

                          I call that reproducing the bug. That makes three of us who see
                          the bug, one who does not. Looking at the plugin, I think I understand
                          what causes it. I explained that a few posts back, didn't I?

                          HTH --Benji Fisher
                        • Mathias Michaelis
                          Hi * ... Bram has fixed this bug already a month ago ;-) See: http://groups.yahoo.com/group/vimdev/message/43639 Best regards Mathias
                          Message 12 of 13 , Jun 8, 2006
                          • 0 Attachment
                            Hi *

                            > I call that reproducing the bug. That makes three of us who see
                            > the bug, one who does not. Looking at the plugin, I think I
                            > understand what causes it. I explained that a few posts back,
                            > didn't I?
                            >
                            Bram has fixed this bug already a month ago ;-)

                            See: http://groups.yahoo.com/group/vimdev/message/43639

                            Best regards

                            Mathias
                          • Jared
                            ... Sigh. Good news, but I wish we knew this 13 e-mails ago. :-) Thanks to everyone that looked into this. -- Jared
                            Message 13 of 13 , Jun 8, 2006
                            • 0 Attachment
                              On 06/08/2006 04:14, Mathias Michaelis wrote:
                              > Bram has fixed this bug already a month ago ;-)
                              >
                              > See: http://groups.yahoo.com/group/vimdev/message/43639

                              Sigh. Good news, but I wish we knew this 13 e-mails ago. :-)

                              Thanks to everyone that looked into this.

                              --
                              Jared
                            Your message has been successfully submitted and would be delivered to recipients shortly.