gv bug?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

gv bug?

Tim Chase
To replicate

  $ vi -u NONE
  :r !jot 15

(or use `seq 15` to get the numbers 1-15 in your file)

  3GVG:g/5/d

This should delete lines 5 and 15 because they contain a "5".
However, issueing

  gv

does not reselect the text.  If instead you have 16 numbers

  $ vim -u NONE
  :r !jot 16

and do

  3GVGk:g/5/d

(selecting through the penultimate line, so the same text selected
as before, followed by the same command, just with a line below '>
containing "16") followed by

  gv

it works, adjusting the '> mark to the line containing "16".  So
there's clearly some "the last line of my visual range was deleted,
so we need to adjust it" logic, but it doesn't seem to check if that
adjusment runs of the end of the file and back it off instead.

Thanks!

-tim

(brought to my attention in this thread
https://www.reddit.com/r/vim/comments/htfc78/vimscript_deletion_inside_visual_selection/
where it caused some odd edge-cases)


--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20200719082430.385c0664%40bigbox.attlocal.net.
Reply | Threaded
Open this post in threaded view
|

Re: gv bug?

Bram Moolenaar

Tim Chase wrote:

> To replicate
>
>   $ vi -u NONE
>   :r !jot 15
>
> (or use `seq 15` to get the numbers 1-15 in your file)
>
>   3GVG:g/5/d
>
> This should delete lines 5 and 15 because they contain a "5".
> However, issueing
>
>   gv
>
> does not reselect the text.

For me it does.  I cannot guess why it doesn't work for you.

> If instead you have 16 numbers
>
>   $ vim -u NONE
>   :r !jot 16
>
> and do
>
>   3GVGk:g/5/d
>
> (selecting through the penultimate line, so the same text selected
> as before, followed by the same command, just with a line below '>
> containing "16") followed by
>
>   gv
>
> it works, adjusting the '> mark to the line containing "16".  So
> there's clearly some "the last line of my visual range was deleted,
> so we need to adjust it" logic, but it doesn't seem to check if that
> adjusment runs of the end of the file and back it off instead.
>
> Thanks!

--
It was recently discovered that research causes cancer in rats.

 /// Bram Moolenaar -- [hidden email] -- 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_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/202007191518.06JFI61v237518%40masaka.moolenaar.net.
Reply | Threaded
Open this post in threaded view
|

Re: gv bug?

Tim Chase
On 2020-07-19 17:18, Bram Moolenaar wrote:

> Tim Chase wrote:
> > To replicate
> >
> >   $ vi -u NONE
> >   :r !jot 15
> >
> > (or use `seq 15` to get the numbers 1-15 in your file)
> >
> >   3GVG:g/5/d
> >
> > This should delete lines 5 and 15 because they contain a "5".
> > However, issueing
> >
> >   gv
> >
> > does not reselect the text.  
>
> For me it does.  I cannot guess why it doesn't work for you.

I just went to reproduce it and there seems to be something to the
order of how the lines are selected.  I slightly tweaked the order of
the commands to make it clear what range I was selecting, assuming
that a-range-was-a-range.  Sorry about that confusion.

If I do the selection from top to bottom, it does indeed work as you
encountered:

  $ vim -u NONE
  :r !jot 15
  3GVG:g/5/d
  gv

But if I select them from bottom-to-top

  $ vim -u NONE
  :r !jot 15
  V3G:g/5/d
  gv

I get the (mis)behavior I was seeing...the "gv" doesn't reselect the
available range.

Again, sorry I messed up reproducing that situation.

-tim



--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20200719135401.17ecbbaf%40bigbox.attlocal.net.
Reply | Threaded
Open this post in threaded view
|

Re: gv bug?

Bram Moolenaar

Tim Chase wrote:

> > > To replicate
> > >
> > >   $ vi -u NONE
> > >   :r !jot 15
> > >
> > > (or use `seq 15` to get the numbers 1-15 in your file)
> > >
> > >   3GVG:g/5/d
> > >
> > > This should delete lines 5 and 15 because they contain a "5".
> > > However, issueing
> > >
> > >   gv
> > >
> > > does not reselect the text.  
> >
> > For me it does.  I cannot guess why it doesn't work for you.
>
> I just went to reproduce it and there seems to be something to the
> order of how the lines are selected.  I slightly tweaked the order of
> the commands to make it clear what range I was selecting, assuming
> that a-range-was-a-range.  Sorry about that confusion.
>
> If I do the selection from top to bottom, it does indeed work as you
> encountered:
>
>   $ vim -u NONE
>   :r !jot 15
>   3GVG:g/5/d
>   gv
>
> But if I select them from bottom-to-top
>
>   $ vim -u NONE
>   :r !jot 15
>   V3G:g/5/d
>   gv
>
> I get the (mis)behavior I was seeing...the "gv" doesn't reselect the
> available range.
>
> Again, sorry I messed up reproducing that situation.

Hmm, now I can reproduce it.  The mark on the last line has become
invalid.  ":marks" shows the "<" mark as "invalid".  Weird thing is that
when using "'<" it works, but it actually jumps to the ">" mark
position.  The code shows that this is intentional.

I suppose that when the Visual mark is beyond the end of the file, it's
best to put it on the last line.

--
Light travels faster than sound.  This is why some people
appear bright until you hear them speak

 /// Bram Moolenaar -- [hidden email] -- 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_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/202007192010.06JKA8At313362%40masaka.moolenaar.net.