Re: gUgn not repeated with .
On Monday, August 12, 2013 9:22:21 PM UTC+2, Christian Brabandt wrote:
On Do, 08 Aug 2013, Dimitar DIMITROV wrote:
As per the subject :)
Can you check, whether the attached patch fixes it for you?
regards,
Christian
--
Was die Welt in diesem Augenblick sucht, ist viel weniger ein
Gleichgewicht als eine Sprache.
-- Jean Giraudoux
I'd like to bring this up again. I was surprised that `gUgn` wasn't repeatable
and took a dive into the code. I solved it in a different way and found this
topic while I wanted to submit my patch.
I discovered that the `gn` command used the `redobuff` in a differend way [1]
than most commands. The command `dgn` would write `gnd` to the `redobuff`
instead of the more natuaral `dgn`. To make redo work, there was some special
code [2] needed to read the `d` after `gn` to issue the deletion.
This breaks when using two character operators. The command `gUgn` writes
`gngU` to the stuffbuff. The `.` command would now only get one extra char
after `gn`, leading to the repeated command `gng`, which does nothing.
Getting another extra char in that case would probably work, but instead I
tried to reverse the `redobuff`. Instead of `gngU` from [1] I wrote `gUgn` to
the `stuffbuff` and suddenly everything worked. When repeated, the `gU` command
pends, `gn` selects the next match and the pending operator makes it uppercase.
After that I could remove the special behavior mentioned in [2].
Here is a small test case to demonstrate the difference. The following vim
invocation inserts vim vim, searches for vim, uppercases the first match,
but fails to uppercase the second match upon repetition. Result: VIM vim
./vim -c ':exe norm 2Ivim \Escx#gUgn.'
The same invocation with the attached `gugn_repeat.patch` applied, yields the
expected VIM VIM.
Bonus: In the `gn` implementation `current_search` there is an early return [3]
that doesn't restore the 'wrapscan' option. This happens when the search
pattern cannot be found.
So after you deleted all occurences of a pattern by repeating `dgn`, the
'nowrapscan' option will remain set. I fixed this by restoring 'wrapscan'
before returning.
Test case: Start vim with this invocation and execute the ex command `:set ws?`
to verify that 'nowrapscan' is set.
./vim -c ':let @/=a|norm dgn'
The same invocation with the attached `gn_wrapscan.patch` applied, still has
'wrapscan' set as expected.
@ Christian Brabandt: Was there any intention in the reversed `stuffbuff` order
that I might have missed?
[1] normal.c
1800 /* gn and gN are a bit different */
1801 prep_redo(oap-regname, 0L, NUL, cap-cmdchar,
cap-nchar,
1802 get_op_char(oap-op_type),
1803 get_extra_op_char(oap-op_type));
[2] normal.c
965 /* For gn from redo, need to get one more char to determine
the
966 * operator */
967 if (ca.nchar == 'r' || ca.nchar == '\'' || ca.nchar == '`'
968|| ca.nchar ==
Ctrl_BSL
969 || ((ca.nchar == 'n' || ca.nchar == 'N')
!stuff_empty()))
[3] search.c
4544 /* Is the pattern is zero-width? */
4545 one_char = is_one_char(spats[last_idx].pat);
4546 if (one_char == -1)
4547 return FAIL; /* invalid pattern */
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
diff -r 34a3b852ec05 src/normal.c
--- a/src/normal.c Tue Nov 12 18:09:29 2013 +0100
+++ b/src/normal.c Wed Nov 13 23:54:13 2013 +0100
@@ -962,11 +962,8 @@
#ifdef FEAT_CMDL_INFO
need_flushbuf |= add_to_showcmd(ca.nchar);
#endif
- /* For gn from redo, need to get one more char to determine the
- * operator */
if (ca.nchar == 'r' || ca.nchar == '\'' || ca.nchar == '`'
- || ca.nchar == Ctrl_BSL
- || ((ca.nchar == 'n' || ca.nchar == 'N') !stuff_empty()))
+ || ca.nchar == Ctrl_BSL)
{
cp = ca.extra_char; /* need to get a third character */
if (ca.nchar != 'r')
@@ -1797,10 +1794,9 @@
* otherwise it might be the second char of the operator. */
if (cap-cmdchar == 'g' (cap-nchar == 'n'
|| cap-nchar == 'N'))
- /* gn and gN are a bit different */
- prep_redo(oap-regname, 0L, NUL, cap-cmdchar, cap-nchar,
- get_op_char(oap-op_type),
- get_extra_op_char(oap-op_type));
+ prep_redo(oap-regname, cap-count0,
+ get_op_char(oap-op_type), get_extra_op_char(oap-op_type),
+
Re: gUgn not repeated with .
On Thursday, November 14, 2013 12:23:03 AM UTC+1, Christian Wellenbrock wrote:
On Monday, August 12, 2013 9:22:21 PM UTC+2, Christian Brabandt wrote:
On Do, 08 Aug 2013, Dimitar DIMITROV wrote:
As per the subject :)
Can you check, whether the attached patch fixes it for you?
regards,
Christian
--
Was die Welt in diesem Augenblick sucht, ist viel weniger ein
Gleichgewicht als eine Sprache.
-- Jean Giraudoux
I'd like to bring this up again. I was surprised that `gUgn` wasn't
repeatable and took a dive into the code. I solved it in a different way and
found this topic while I wanted to submit my patch.
I discovered that the `gn` command used the `redobuff` in a differend way [1]
than most commands. The command `dgn` would write `gnd` to the `redobuff`
instead of the more natuaral `dgn`. To make redo work, there was some special
code [2] needed to read the `d` after `gn` to issue the deletion.
This breaks when using two character operators. The command `gUgn` writes
`gngU` to the stuffbuff. The `.` command would now only get one extra char
after `gn`, leading to the repeated command `gng`, which does nothing.
Getting another extra char in that case would probably work, but instead I
tried to reverse the `redobuff`. Instead of `gngU` from [1] I wrote `gUgn` to
the `stuffbuff` and suddenly everything worked. When repeated, the `gU`
command pends, `gn` selects the next match and the pending operator makes it
uppercase.
After that I could remove the special behavior mentioned in [2].
Here is a small test case to demonstrate the difference. The following vim
invocation inserts vim vim, searches for vim, uppercases the first match,
but fails to uppercase the second match upon repetition. Result: VIM vim
./vim -c ':exe norm 2Ivim \Escx#gUgn.'
The same invocation with the attached `gugn_repeat.patch` applied, yields the
expected VIM VIM.
Bonus: In the `gn` implementation `current_search` there is an early return
[3] that doesn't restore the 'wrapscan' option. This happens when the search
pattern cannot be found.
So after you deleted all occurences of a pattern by repeating `dgn`, the
'nowrapscan' option will remain set. I fixed this by restoring 'wrapscan'
before returning.
Test case: Start vim with this invocation and execute the ex command `:set
ws?` to verify that 'nowrapscan' is set.
./vim -c ':let @/=a|norm dgn'
The same invocation with the attached `gn_wrapscan.patch` applied, still has
'wrapscan' set as expected.
@ Christian Brabandt: Was there any intention in the reversed `stuffbuff`
order that I might have missed?
[1] normal.c
1800 /* gn and gN are a bit different */
1801 prep_redo(oap-regname, 0L, NUL, cap-cmdchar,
cap-nchar,
1802 get_op_char(oap-op_type),
1803 get_extra_op_char(oap-op_type));
[2] normal.c
965 /* For gn from redo, need to get one more char to
determine the
966 * operator */
967 if (ca.nchar == 'r' || ca.nchar == '\'' || ca.nchar == '`'
968|| ca.nchar ==
Ctrl_BSL
969 || ((ca.nchar == 'n' || ca.nchar == 'N')
!stuff_empty()))
[3] search.c
4544 /* Is the pattern is zero-width? */
4545 one_char = is_one_char(spats[last_idx].pat);
4546 if (one_char == -1)
4547 return FAIL; /* invalid pattern */
Small update: There is some more special `gn` code [1] that can be removed
after changing the `stuffbuff` order. Find updated patch attached.
[1] normal.c
1091 else if ((ca.nchar == 'n' || ca.nchar == 'N') ca.cmdchar ==
'g')
1092 ca.oap-op_type = get_op_type(*cp, NUL);
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
diff -r 34a3b852ec05 src/normal.c
--- a/src/normal.c Tue Nov 12 18:09:29 2013 +0100
+++ b/src/normal.c Thu Nov 14 00:33:06 2013 +0100
@@ -962,11 +962,8 @@
#ifdef FEAT_CMDL_INFO
need_flushbuf |= add_to_showcmd(ca.nchar);
#endif
- /* For gn from redo, need to get one more char to determine the
- * operator */
if (ca.nchar == 'r' || ca.nchar == '\'' || ca.nchar == '`'
- || ca.nchar == Ctrl_BSL
- || ((ca.nchar == 'n' || ca.nchar == 'N') !stuff_empty()))
+ || ca.nchar == Ctrl_BSL)
{
cp = ca.extra_char; /* need to get a third character
Re: gUgn not repeated with .
On Thu, November 14, 2013 00:23, Christian Wellenbrock wrote: On Monday, August 12, 2013 9:22:21 PM UTC+2, Christian Brabandt wrote: On Do, 08 Aug 2013, Dimitar DIMITROV wrote: As per the subject :) Can you check, whether the attached patch fixes it for you? I'd like to bring this up again. I was surprised that `gUgn` wasn't repeatable and took a dive into the code. I solved it in a different way and found this topic while I wanted to submit my patch. I discovered that the `gn` command used the `redobuff` in a differend way [1] than most commands. The command `dgn` would write `gnd` to the `redobuff` instead of the more natuaral `dgn`. To make redo work, there was some special code [2] needed to read the `d` after `gn` to issue the deletion. This breaks when using two character operators. The command `gUgn` writes `gngU` to the stuffbuff. The `.` command would now only get one extra char after `gn`, leading to the repeated command `gng`, which does nothing. Getting another extra char in that case would probably work, but instead I tried to reverse the `redobuff`. Instead of `gngU` from [1] I wrote `gUgn` to the `stuffbuff` and suddenly everything worked. When repeated, the `gU` command pends, `gn` selects the next match and the pending operator makes it uppercase. After that I could remove the special behavior mentioned in [2]. Here is a small test case to demonstrate the difference. The following vim invocation inserts vim vim, searches for vim, uppercases the first match, but fails to uppercase the second match upon repetition. Result: VIM vim ./vim -c ':exe norm 2Ivim \Escx#gUgn.' The same invocation with the attached `gugn_repeat.patch` applied, yields the expected VIM VIM. Bonus: In the `gn` implementation `current_search` there is an early return [3] that doesn't restore the 'wrapscan' option. This happens when the search pattern cannot be found. Good catch. Thanks. So after you deleted all occurences of a pattern by repeating `dgn`, the 'nowrapscan' option will remain set. I fixed this by restoring 'wrapscan' before returning. Test case: Start vim with this invocation and execute the ex command `:set ws?` to verify that 'nowrapscan' is set. ./vim -c ':let @/=a|norm dgn' The same invocation with the attached `gn_wrapscan.patch` applied, still has 'wrapscan' set as expected. @ Christian Brabandt: Was there any intention in the reversed `stuffbuff` order that I might have missed? Not that I remember. I think, this is ok, since this removes to special case the 'gn' operator. Thanks, Christian -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: gUgn not repeated with .
On Do, 08 Aug 2013, Dimitar DIMITROV wrote:
As per the subject :)
Can you check, whether the attached patch fixes it for you?
regards,
Christian
--
Was die Welt in diesem Augenblick sucht, ist viel weniger ein
Gleichgewicht als eine Sprache.
-- Jean Giraudoux
--
--
You received this message from the vim_dev maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
vim_dev group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
diff --git a/src/normal.c b/src/normal.c
--- a/src/normal.c
+++ b/src/normal.c
@@ -1089,7 +1089,14 @@
idx = find_command(ca.cmdchar);
}
else if ((ca.nchar == 'n' || ca.nchar == 'N') ca.cmdchar == 'g')
- ca.oap-op_type = get_op_type(*cp, NUL);
+ {
+ int d = NUL;
+
+ if (*cp == 'g' !stuff_empty())
+ d = plain_vgetc(); /* need to get another char */
+
+ ca.oap-op_type = get_op_type(*cp, d);
+ }
else if (*cp == Ctrl_BSL)
{
long towait = (p_ttm = 0 ? p_ttm : p_tm);
gUgn not repeated with .
As per the subject :) Dimitar --- GPG Key: 2048R/160C6FA8 2012-10-11 Dimitar Dimitrov (kurkale6ka) mitk...@yahoo.fr -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: gUgn not repeated with .
On Thursday, August 8, 2013 9:27:27 AM UTC-5, Dimitar DIMITROV wrote: As per the subject :) Verified that . has no effect after a gUgn that capitalized a match for the last search, on 7.3.822 Windows, and also 7.4b.14 on Solaris. -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: gUgn not repeated with .
As per the subject :) Verified that . has no effect after a gUgn that capitalized a match for the last search, on 7.3.822 Windows, and also 7.4b.14 on Solaris. Doesn't work for g~ either (or ~ with 'top set). Haven't checked the others Dimitar -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: gUgn not repeated with .
Dimitar Dimitrov wrote: As per the subject :) Verified that . has no effect after a gUgn that capitalized a match for the last search, on 7.3.822 Windows, and also 7.4b.14 on Solaris. Doesn't work for g~ either (or ~ with 'top set). Haven't checked the others Using . in Visual mode is not supported. I suppose it could be added, when the last command was operating on an area or movement, it could operate on the current Visual selection. -- hundred-and-one symptoms of being an internet addict: 60. As your car crashes through the guardrail on a mountain road, your first instinct is to search for the back button. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: gUgn not repeated with .
On Thursday, August 8, 2013 11:37:38 AM UTC-5, Bram Moolenaar wrote: Dimitar Dimitrov wrote: As per the subject :) Verified that . has no effect after a gUgn that capitalized a match for the last search, on 7.3.822 Windows, and also 7.4b.14 on Solaris. Doesn't work for g~ either (or ~ with 'top set). Haven't checked the others Using . in Visual mode is not supported. I suppose it could be added, when the last command was operating on an area or movement, it could operate on the current Visual selection. Where does visual mode come in? gn starts visual mode when used by itself, but the help just says if an operator is pending, operates on the match without mentioning visual mode. You can repeat dgn, cgn, and the like; I'd expect gUgn to work in the same way. -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: gUgn not repeated with .
Ben Fritz wrote: On Thursday, August 8, 2013 11:37:38 AM UTC-5, Bram Moolenaar wrote: Dimitar Dimitrov wrote: As per the subject :) Verified that . has no effect after a gUgn that capitalized a match for the last search, on 7.3.822 Windows, and also 7.4b.14 on Solaris. Doesn't work for g~ either (or ~ with 'top set). Haven't checked the others Using . in Visual mode is not supported. I suppose it could be added, when the last command was operating on an area or movement, it could operate on the current Visual selection. Where does visual mode come in? gn starts visual mode when used by itself, but the help just says if an operator is pending, operates on the match without mentioning visual mode. You can repeat dgn, cgn, and the like; I'd expect gUgn to work in the same way. Somehow I assumed starting in Visual mode. OK, now I understand the reported problem. You can see how a one liner is not a good bug report. -- hundred-and-one symptoms of being an internet addict: 61. Your best friends know your e-mail address, but neither your phone number nor the address where you live. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups vim_dev group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
