Re: Question regarding :normal

[Quinn Strahl]

On Friday, 28 August 2015 18:46:00 UTC-4, Justin M. Keyes  wrote:
> On Aug 27, 2015 3:45 PM, "Gary Johnson"  wrote:
> 
> >
> 
> > On 2015-08-27, Christian Brabandt wrote:
> 
> > > Hi Quinn!
> 
> > >
> 
> > > On Do, 27 Aug 2015, Quinn Strahl wrote:
> 
> > >
> 
> > > > I was just reminded of another little grievance I have with
> 
> > > > :g/^/norm -- it sets the last search pattern to /^/, a very
> 
> > > > unintended side-effect.
> 
> > >
> 
> > > But that is what :g is for.
> 
> >
> 
> > Yes, but Quinn's point is that it wouldn't be necessary to use :g
> 
> > and a dummy pattern if :normal worked the way that :g does, that is,
> 
> > if ":{range}normal {commands}" first marked the lines in {range},
> 
> > then went back and executed {commands} on those marked lines.
> 
> Use
> 
>  :keeppatterns g/^/...
> 
> to avoid setting @/.

*Of course* there is a command for that. :)

Thank you, Justin, and thank you, Christian. Between a patch and a workaround I 
don't think I could ask for a better response.

Cheers!

-- 
-- 
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/d/optout.

Re: Question regarding :normal

[Christian Brabandt]

On Do, 27 Aug 2015, Gary Johnson wrote:

 On 2015-08-27, Christian Brabandt wrote:
  Hi Quinn!
  
  On Do, 27 Aug 2015, Quinn Strahl wrote:
  
   I was just reminded of another little grievance I have with
   :g/^/norm -- it sets the last search pattern to /^/, a very
   unintended side-effect.
  
  But that is what :g is for.
 
 Yes, but Quinn's point is that it wouldn't be necessary to use :g
 and a dummy pattern if :normal worked the way that :g does, that is,
 if :{range}normal {commands} first marked the lines in {range},
 then went back and executed {commands} on those marked lines.

Okay, I can understand that. So here is a patch.

It is a little bit tricky, since if you simply mark the lines while a :g 
command is running, this would cancel your :g command (because we need 
to clear the marks once the :normal is done). So here is an approach, 
that only marks the lines, if no :g command is running, else we fall 
back to the old behaviour.

E.g. for this file
1
2

This is a bit a silly example, but it explains my point:
:g/^/1,2norm! yyp
will still behave like the old behaviour (since we can't mark the lines, 
as then after the :norm! finishes all marks for the :g would be gone)
e.g. result in:
1
1
1
1
1
2

But :g/^/norm yyp and :%norm! yyp will result in 

1
1
2
2

Included in the patch is a test and updated documentation.


Best
Christian
-- 
Stilblüten aus Schreiben von Versicherungsnehmern:
Der Unfall ist dadurch entstanden, daß der Volkswagen weiterfuhr. Er
mußte verfolgt werden, ehe er schließlich anhielt. Als wir ihm eine
Tracht Prügel verabreichten, geschah es.

-- 
-- 
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/d/optout.
diff --git a/runtime/doc/various.txt b/runtime/doc/various.txt
--- a/runtime/doc/various.txt
+++ b/runtime/doc/various.txt
@@ -214,9 +214,12 @@ 8g8			Find an illegal UTF-8 byte sequenc
 :{range}norm[al][!] {commands}*:normal-range*
 			Execute Normal mode commands {commands} for each line
 			in the {range}.  Before executing the {commands}, the
-			cursor is positioned in the first column of the range,
-			for each line.  Otherwise it's the same as the
-			:normal command without a range.
+			lines in the range will be marked (similar to how the
+			|:global| command works) unless a |:g| command is active
+			and the cursor is positioned on each marked line in
+			the first column of the range.
+			Otherwise it's the same as the :normal command
+			without a range.
 			{not in Vi}
 			{not available when |+ex_extra| feature was disabled
 			at compile time}
diff --git a/src/ex_docmd.c b/src/ex_docmd.c
--- a/src/ex_docmd.c
+++ b/src/ex_docmd.c
@@ -9967,6 +9967,7 @@ ex_normal(eap)
 int		save_insertmode = p_im;
 int		save_finish_op = finish_op;
 int		save_opcount = opcount;
+linenr_T	lnum = 0;
 #ifdef FEAT_MBYTE
 char_u	*arg = NULL;
 int		l;
@@ -10066,21 +10067,39 @@ ex_normal(eap)
 	 * range given, execute it just once, without positioning the cursor
 	 * first.
 	 */
+	if (eap-addr_count != 0  !global_busy)
+	{
+	/* mark the lines on which to act */
+	for (lnum = eap-line1; lnum = eap-line2; ++lnum)
+		ml_setmarked(lnum);
+	}
+
 	do
 	{
 	if (eap-addr_count != 0)
 	{
-		curwin-w_cursor.lnum = eap-line1++;
+		/* do not mark the lines, if called from :global */
+		if (!global_busy)
+		lnum = ml_firstmarked();
+		else
+		/* go line by line */
+		lnum = eap-line1++;
+		if (lnum == 0)
+		break;
+		curwin-w_cursor.lnum = lnum;
 		curwin-w_cursor.col = 0;
 	}
-
 	exec_normal_cmd(
 #ifdef FEAT_MBYTE
 		arg != NULL ? arg :
 #endif
 		eap-arg, eap-forceit ? REMAP_NONE : REMAP_YES, FALSE);
 	}
-	while (eap-addr_count  0  eap-line1 = eap-line2  !got_int);
+	while (!got_int  (eap-addr_count  0  eap-line1 = eap-line2));
+
+	/* clear rest of the marks */
+	if (!global_busy)
+	ml_clearmarked();
 }
 
 /* Might not return to the main loop when in an event handler. */
diff --git a/src/testdir/Make_amiga.mak b/src/testdir/Make_amiga.mak
--- a/src/testdir/Make_amiga.mak
+++ b/src/testdir/Make_amiga.mak
@@ -57,6 +57,7 @@ SCRIPTS = test1.out test3.out test4.out 
 		test_marks.out \
 		test_match_conceal.out \
 		test_nested_function.out \
+		test_normal.out \
 		test_options.out \
 		test_perl.out \
 		test_qf_title.out \
diff --git a/src/testdir/Make_dos.mak b/src/testdir/Make_dos.mak
--- a/src/testdir/Make_dos.mak
+++ b/src/testdir/Make_dos.mak
@@ -56,6 +56,7 @@ SCRIPTS =	test3.out test4.out test5.out 
 		test_marks.out \
 		test_match_conceal.out \
 		test_nested_function.out \
+		test_normal.out \
 		

Re: Question regarding :normal

[Justin M. Keyes]

On Aug 27, 2015 3:45 PM, Gary Johnson garyj...@spocom.com wrote:

 On 2015-08-27, Christian Brabandt wrote:
  Hi Quinn!
 
  On Do, 27 Aug 2015, Quinn Strahl wrote:
 
   I was just reminded of another little grievance I have with
   :g/^/norm -- it sets the last search pattern to /^/, a very
   unintended side-effect.
 
  But that is what :g is for.

 Yes, but Quinn's point is that it wouldn't be necessary to use :g
 and a dummy pattern if :normal worked the way that :g does, that is,
 if :{range}normal {commands} first marked the lines in {range},
 then went back and executed {commands} on those marked lines.

Use

:keeppatterns g/^/...

to avoid setting @/.

-- 
-- 
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/d/optout.

Re: Question regarding :normal

[Quinn Strahl]

I was just reminded of another little grievance I have with :g/^/norm -- it 
sets the last search pattern to /^/, a very unintended side-effect.

-- 
-- 
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/d/optout.

Re: Question regarding :normal

[Christian Brabandt]

Hi Quinn!

On Do, 27 Aug 2015, Quinn Strahl wrote:

 I was just reminded of another little grievance I have with :g/^/norm -- it 
 sets the last search pattern to /^/, a very unintended side-effect.

But that is what :g is for.


Best,
Christian
-- 
Neue Meldungen von Windows 2000:
Netscape.exe. Falscher Dateiname. Systemintegrität verletzt.
Internet-Explorer wird installiert.

-- 
-- 
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/d/optout.

Re: Question regarding :normal

[Gary Johnson]

On 2015-08-27, Christian Brabandt wrote:
 Hi Quinn!
 
 On Do, 27 Aug 2015, Quinn Strahl wrote:
 
  I was just reminded of another little grievance I have with
  :g/^/norm -- it sets the last search pattern to /^/, a very
  unintended side-effect.
 
 But that is what :g is for.

Yes, but Quinn's point is that it wouldn't be necessary to use :g
and a dummy pattern if :normal worked the way that :g does, that is,
if :{range}normal {commands} first marked the lines in {range},
then went back and executed {commands} on those marked lines.

Regards,
Gary

-- 
-- 
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/d/optout.

Re: Question regarding :normal

[Charles Campbell]

Quinn Strahl wrote:
 On Wednesday, 26 August 2015 01:31:34 UTC-4, Justin M. Keyes  wrote:
 On Tue, Aug 25, 2015 at 10:00 PM, Quinn Strahl qstr...@gmail.com wrote:
 A difference in behaviour between :g and :rangenormal recently frustrated 
 me, and I wonder if it's up for debate:

 :g does a pass on matching lines and marks them before performing the 
 operation; this allows it to be generally undeterred by operations that 
 include addition/deletion of lines.

 :rangenormal does not do this, and as a result, it can get thrown off 
 by such operations. For (a trivial) example, on the hypothetical file:

 foo
 bar
 baz

 Performing :1,3normal yyp would produce the following result:

 foo
 foo
 foo
 foo
 bar
 baz

 Whereas the more intuitive result would be:

 foo
 foo
 bar
 bar
 baz
 baz

 There does exist a workaround, in the form of :rangeg/^/normal yyp -- 
 simply using :g in a way guaranteed to match every line in the desired 
 range -- but this is a bit of a compositional kludge.

 Would it be feasible to add the marking behaviour of :g to :normal, or is 
 that not worth implementing / a feature?
 Why do you want them to behave the same? They serve different
 purposes. Or rather, :g serves a purpose, and :normal is behaving in
 the typical way for a range command that performs edits/changes.


 Justin M. Keyes
 I have on many occasions run into situations where it would be very handy if 
 :normal worked the way :g does with respect to how it handles changes in 
 number of lines during operation, and I have not run into any case (nor can I 
 imagine one) where the current behaviour is favourable. It seems less 
 intuitive and less useful for it to behave this way.

Why not use

:[range]g/pattern/norm whatever

Regards,
Chip Campbell

-- 
-- 
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/d/optout.

Re: Question regarding :normal

[Quinn Strahl]

On Wednesday, 26 August 2015 12:15:44 UTC-4, Charles Campbell  wrote:
 Quinn Strahl wrote:
  On Wednesday, 26 August 2015 01:31:34 UTC-4, Justin M. Keyes  wrote:
  On Tue, Aug 25, 2015 at 10:00 PM, Quinn Strahl qstr...@gmail.com wrote:
  A difference in behaviour between :g and :rangenormal recently 
  frustrated me, and I wonder if it's up for debate:
 
  :g does a pass on matching lines and marks them before performing the 
  operation; this allows it to be generally undeterred by operations that 
  include addition/deletion of lines.
 
  :rangenormal does not do this, and as a result, it can get thrown off 
  by such operations. For (a trivial) example, on the hypothetical file:
 
  foo
  bar
  baz
 
  Performing :1,3normal yyp would produce the following result:
 
  foo
  foo
  foo
  foo
  bar
  baz
 
  Whereas the more intuitive result would be:
 
  foo
  foo
  bar
  bar
  baz
  baz
 
  There does exist a workaround, in the form of :rangeg/^/normal yyp -- 
  simply using :g in a way guaranteed to match every line in the desired 
  range -- but this is a bit of a compositional kludge.
 
  Would it be feasible to add the marking behaviour of :g to :normal, or is 
  that not worth implementing / a feature?
  Why do you want them to behave the same? They serve different
  purposes. Or rather, :g serves a purpose, and :normal is behaving in
  the typical way for a range command that performs edits/changes.
 
 
  Justin M. Keyes
  I have on many occasions run into situations where it would be very handy 
  if :normal worked the way :g does with respect to how it handles changes in 
  number of lines during operation, and I have not run into any case (nor can 
  I imagine one) where the current behaviour is favourable. It seems less 
  intuitive and less useful for it to behave this way.
 
 Why not use
 
 :[range]g/pattern/norm whatever
 
 Regards,
 Chip Campbell

That's the workaround I'm using right now, but there are many cases where I 
want to operate on every line in the range, forcing me to use something like my 
previous example:

:rangeg/^/norm whatever

It feels hacky; I'm essentially trying to avoid what is arguably the primary 
function of :g (matching a subset of lines) just to get that line-marking 
behaviour for the :normal operation. It makes me wonder, is there any reason 
for :normal to lack that behaviour? It seems like an objective improvement.

-- 
-- 
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/d/optout.

Re: Question regarding :normal

[Quinn Strahl]

On Wednesday, 26 August 2015 01:31:34 UTC-4, Justin M. Keyes  wrote:
 On Tue, Aug 25, 2015 at 10:00 PM, Quinn Strahl qstr...@gmail.com wrote:
  A difference in behaviour between :g and :rangenormal recently frustrated 
  me, and I wonder if it's up for debate:
 
  :g does a pass on matching lines and marks them before performing the 
  operation; this allows it to be generally undeterred by operations that 
  include addition/deletion of lines.
 
  :rangenormal does not do this, and as a result, it can get thrown off 
  by such operations. For (a trivial) example, on the hypothetical file:
 
  foo
  bar
  baz
 
  Performing :1,3normal yyp would produce the following result:
 
  foo
  foo
  foo
  foo
  bar
  baz
 
  Whereas the more intuitive result would be:
 
  foo
  foo
  bar
  bar
  baz
  baz
 
  There does exist a workaround, in the form of :rangeg/^/normal yyp -- 
  simply using :g in a way guaranteed to match every line in the desired 
  range -- but this is a bit of a compositional kludge.
 
  Would it be feasible to add the marking behaviour of :g to :normal, or is 
  that not worth implementing / a feature?
 
 Why do you want them to behave the same? They serve different
 purposes. Or rather, :g serves a purpose, and :normal is behaving in
 the typical way for a range command that performs edits/changes.
 
 
 Justin M. Keyes

I have on many occasions run into situations where it would be very handy if 
:normal worked the way :g does with respect to how it handles changes in number 
of lines during operation, and I have not run into any case (nor can I imagine 
one) where the current behaviour is favourable. It seems less intuitive and 
less useful for it to behave this 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/d/optout.

Re: Question regarding :normal

[Justin M. Keyes]

On Tue, Aug 25, 2015 at 10:00 PM, Quinn Strahl qstr...@gmail.com wrote:
 A difference in behaviour between :g and :rangenormal recently frustrated 
 me, and I wonder if it's up for debate:

 :g does a pass on matching lines and marks them before performing the 
 operation; this allows it to be generally undeterred by operations that 
 include addition/deletion of lines.

 :rangenormal does not do this, and as a result, it can get thrown off by 
 such operations. For (a trivial) example, on the hypothetical file:

 foo
 bar
 baz

 Performing :1,3normal yyp would produce the following result:

 foo
 foo
 foo
 foo
 bar
 baz

 Whereas the more intuitive result would be:

 foo
 foo
 bar
 bar
 baz
 baz

 There does exist a workaround, in the form of :rangeg/^/normal yyp -- 
 simply using :g in a way guaranteed to match every line in the desired range 
 -- but this is a bit of a compositional kludge.

 Would it be feasible to add the marking behaviour of :g to :normal, or is 
 that not worth implementing / a feature?

Why do you want them to behave the same? They serve different
purposes. Or rather, :g serves a purpose, and :normal is behaving in
the typical way for a range command that performs edits/changes.


Justin M. Keyes

-- 
-- 
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/d/optout.