Christian wrote:
> Hi Gary!
>
> On Di, 10 Feb 2015, Gary Johnson wrote:
>
> > On 2015-02-10, Christian Brabandt wrote:
> > > Am 2015-02-10 04:15, schrieb Gary Johnson:
> > > >Given a file with the following contents,
> > > >
> > > >ape(x
> > > >boy(y
> > > >cat(
> > > >dog(z
> > > >emu(
> > > >
> > > >and opened with
> > > >
> > > > vim -N -u NONE file
> > > >
> > > >this search command,
> > > >
> > > > /(/e+1
> > > >
> > > >will first move the cursor to the 'x' at the end of the first line,
> > > >as expected. Typing 'n' will then move the cursor to
> > > >
> > > > - the 'y' at the end of the second line (OK)
> > > > - the 'd' at the start of the fourth line (odd)
> > > > - the 'z' at the end of the fourth line (OK)
> > > > - the '(' at the end of the last line (odd)
> > > >
> > > >Typing 'n' again will not move the cursor (bad).
> > > >
> > > >It seems odd that the match wraps to the start of line 4, but I can
> > > >accept that. That typing 'n' does not continue the search from the
> > > >start of the file is really annoying.
> > >
> > > Where should the cursor move for the last line? To line 1 if wrapscan
> > > is set?
> >
> > I don't know. Since Vim patterns don't span lines unless the
> > newline is accounted for specially, it seems odd to me that the e
> > offset spans lines. I'm not saying it's wrong, it just feels odd to
> > me. That could be because I used vi for so long before using Vim.
> >
> > Regardless of where the cursor should be for the last line, it seems
> > wrong that the cursor gets stuck there. It gets stuck at the end of
> > the file for any pattern and offset that would place the cursor
> > beyond the last character in the buffer.
>
> That happens, because it finds the end over and over again.
>
> > Vim can't place the cursor beyond the last character in the buffer,
> > though, so it actually puts the cursor on the last character in the
> > buffer. Typing 'n' at that point should move the cursor to the next
> > match, even if that would be some virtual character to the right of
> > the cursor location.
> >
> > I thought there was a precedent for advancing the cursor to the next
> > match if it would otherwise get stuck in some pattern loop, but I
> > can't think of exactly what it was. There is a precedent for
>
> ; for when the 't' was used?
>
> > remembering where the cursor _would_ be if a character was there:
> > the movement of j and k over lines shorter than the cursor column.
> > As long as you only use j and k, the cursor column is remembered.
> > There could be something similar for this case: a cursor character
> > location where the cursor would be if a character was there. As
> > long as the only commands typed are n or N, the next search would
> > begin from where the cursor would be, not where it actually is.
>
> Here is a patch, that makes 'n'/'N' check, whether the cursor moved and
> if not, retry with an incremented count. That works for your particular
> case. That won't help for the case of the cursor being on the last
> character of a buffer and typing /(/e+1
> But pressing n afterwards should work.
Thanks!
How about a test?
--
>From the classified section of a city newspaper:
Dog for sale: eats anything and is fond of children.
/// 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/d/optout.
