Hi Bram,
On Thu, May 2, 2019 at 9:25 AM Yegappan Lakshmanan <yegapp...@gmail.com> wrote:
>
> > > Yegappan wrote:
> > >
> > > > > > > > We will then have the following commands:
> > > > > > > >
> > > > > > > > cbelow - Go to an error line below the current line in the
> > > > > > > > current file
> > > > > > > > cabove - Go to an error line above the current line in the
> > > > > > > > current file
> > > > > > > > cbefore - Go to an error before the current column in the
> > > > > > > > current file
> > > > > > > > cafter - Go to an error after the current column in the current
> > > > > > > > file
> > > > > > >
> > > > > > > Right. And when giving a count to cbelow/cabove it counts all the
> > > > > > > errors in the same line as one. Thus if there are three matches
> > > > > > > in the
> > > > > > > line above and one two lines up, then ":2cabove" goes two lines
> > > > > > > up.
> > > > > > >
> > > > > >
> > > > > > The latest updated pull request implements the above behavior.
> > > > > > Currently
> > > > > > only the cabove and cbelow commands are implemented.
> > > > > >
> > > > > > The current implementation supports count only after the command
> > > > > > name
> > > > > > and not before the command. I did this to support only positive
> > > > > > numbers
> > > > > > for the count and not use the range specification from the buffer.
> > > > >
> > > > > :2cabove should work. Use "RANGE" and "ADDR_OTHER" in the command
> > > > > spec.
> > > >
> > > > I was using RANGE in the command spec. But when a negative count is
> > > > supplied to the command, it uses the current line number from the
> > > > buffer and
> > > > subtracts the specified count. I wanted to display an error for
> > > > negative values.
> > > > I can use RANGE, if the value is negative, it will ignore the supplied
> > > > count.
> > >
> > > I looked into the way the type of range is specified, but it has a long
> > > history of subtle ways things work not quite as expected. Therefore
> > > ADDR_OTHER will default to using buffer lines.
> > >
> > > We could add a new address type, that does not use the buffer lines.
> > > Not sure what to call it. ADDR_NOT_LINES is not quite right.
> > > I did do a bit of cleanup and removed NOTADR from the command flags.
> > > It seemed a duplicate of using ADDR_OTHER, but it turns out it isn't
> > > quite so.
> > >
> >
> > I updated the PR to use the new ADDR_NONE for the cbelow and cabove
> > commands. Now the negative and invalid ranges are properly passed to
> > the command function and the function checks for the invalid values and
> > displays an error message. This works on Linux and Mac (Travis CI builds).
> > But on Windows (Appveyor), the test fails. It looks like on MS-Windows,
> > the negative range is still converted into a buffer line number relative to
> > the current line number.
> >
> > https://travis-ci.org/vim/vim/builds/527133913
> > https://ci.appveyor.com/project/chrisbra/vim/build/job/iw0t4ik7b28mwq1r
> >
>
> This is caused by the difference in size of the long type (64-bit vs 32-bit)
> between the Linux/Mac and MS-Windows builds. To check for the negative
> values, I am casting the long value to an integer. This works for the
> 64-bit long value and not for the 32-bit long value.
>
I have addressed this issue in the updated PR. The get_address()
function was not properly returning the count passed to commands
with ADDR_NONE. It was returning MAXLNUM - {count}. I have
modified it to return the actual count supplied by the user.
- Yegappan
--
--
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.
