Re: matchparen bug?
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
Re: matchparen bug?
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
Re: matchparen bug?
On Wed, Jun 07, 2006 at 03:07:49PM -0700, Gary Johnson wrote: > On 2006-06-07, Jared <[EMAIL PROTECTED]> wrote: > > On 06/07/2006 15:10, Gary Johnson wrote: > > > On 2006-06-07, Jared <[EMAIL PROTECTED]> 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
Re: matchparen bug?
On 2006-06-07, Jared <[EMAIL PROTECTED]> wrote: > On 06/07/2006 15:10, Gary Johnson wrote: > > On 2006-06-07, Jared <[EMAIL PROTECTED]> 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 and the cursor went to the 'o' in 'another' in all three cases. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: matchparen bug?
On 06/07/2006 15:10, Gary Johnson wrote: > On 2006-06-07, Jared <[EMAIL PROTECTED]> 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
Re: matchparen bug?
On 2006-06-07, Jared <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: matchparen bug?
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 do you have the cursor > >after the parentheses, with the parentheses highlighted? > > > Yes, I do. And after doing 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
Re: matchparen bug?
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 do you have the cursor after the parentheses, with the parentheses highlighted? Yes, I do. And after doing I have cursor after 'r' in 'another'. HTH --Benji Fisher
Re: matchparen bug?
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 > > > >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 > > 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 do you have the cursor after the parentheses, with the parentheses highlighted? HTH --Benji Fisher
Re: matchparen bug?
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 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 and cursor is to the left of 'o' in 'onmifunc'.
Re: matchparen bug?
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 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
Re: matchparen bug?
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.
matchparen bug?
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
