> > 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.
> > 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.
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.
--
--
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.
