Rick Howe wrote:
> > > My proposal always sets next_match_id to be maximum of IDs + 1
> > > even if it is manual or not, so nex_match_id will not collide.
> > > For example:
> > > firstly
> > > matchaddpos('ToDo', [[1]], 10) returns 4
> > > then
> > > matchaddpos('ToDo', [[1]], 10, 1000) returns 1000
> > > then
> > > matchaddpos('ToDo', [[1]], 10) returns 1001
> >
> > The problem is that if someone uses a manual ID of 1000, then most
> > likely it will use 1001 next. That clashes with the automatically
> > assigned ID.
>
> Yes, but even currently, there is a chance to crash IDs between
> different plugins.
> A workaroud here is to return, for example, 11000 instead of 1001,
> by adding 10000 (or something else) istead of 1 to next_match_id,
> to reserve contineous manual IDs and to avoid as many clashes as possible.
That sounds acceptable, add 1000 (or 1111) above the highest manual ID.
> > > then
> > > matchaddpos('ToDo', [[1]], 10) returns 1002
> > > then
> > > matchaddpos('ToDo', [[1]], 10, 500) returns 500
> > > then
> > > matchaddpos('ToDo', [[1]], 10) returns 1003
> > > then
> > > matchaddpos('ToDo', [[1]], 10, 2000) returns 2000
> > > then
> > > matchaddpos('ToDo', [[1]], 10) returns 2001
> > >
> > > One of concerns in my proposal is that once a manual ID is too big
> > > nex_match_id could eventually become integer overflow.
> >
> > We should take care of that as well, although I would expect in most
> > cases all matches to be cleared, in which case we can reset the max ID.
>
> When match_delete() deletes the last ID and clear_matches() is called,
> it is possible to initialize next_match_id to 4. Is there any side effect?
>
> > > Please let me know if there is still a chance to collide the IDs.
> >
> > As mentioned above. I'm not sure how important this is.
>
> As I mentioned, matchaddpos() gradually becomes slower
> to highlight more lines/colulms because it always search the assined IDs
> from scratch many times until finding availabe ID.
> As I showed, no need to search with my simple change, and it can be
> 2 times faster.
>
> > One might just
> > use the same manual ID over and over again, and not increment it.
>
> Even with my change, next_match_id stays the same in that case.
>
> > Also, you need to make sure that setmatches() restores the next ID.
>
> setmatches() internally calls clear_matches() then next_match_id
> can be initialized.
The pair of getmatches() and setmatches() is supposed to save and
restore the state. Having it restore the next ID too matches that.
> Anyway, there is no 0% clashes without a fundamental change of ID
> assignments. 2 times faster is not so negligible, but I will follow
> your decision if you could accept my simple change or not.
Just trying to make it a bit better. The whole mechanism is a bit risky
when using a manual ID anyway. But I haven't heard complaints, so no
reason to fix a problem that doesn't exist.
The nested while loop is defenitely something we should get rid of.
--
hundred-and-one symptoms of being an internet addict:
249. You've forgotten what the outside looks like.
/// Bram Moolenaar -- [email protected] -- 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
