Doesn't this have the (albeit infrequently occurring) weakness that if you add/delete some code you could still be at the same place but get the wrong completion? My original plan was to add a unique ID to each request (just an integer that increases with each request) and ignore responses that aren't the latest request. It takes a little bit more fiddling to add the ID to the python request, but it's not a big deal.

That is indeed a drawback, but the solution with the ID has been tried by me before in ClangCC. It is worse in the sense that if the user advances without performing a new CC request (like pressing enter and having the cursor on an empty line, or clicking somewere else), the completion-menu appears anyway and let that be the situations that are annoying to me. Also the calibration cursor point is at the start of the word, not the point where cc was requested, it solves some corner cases (but not all as you noted) and this way the user can type more letters of the word cc is calculating in the mean time.

Sorry that was dumb of me. I actually have a simplified request counter in place anyway, which I think takes care of stale requests (but maybe has bugs?). So your change is a useful addition on top of that.

But in addition to cursor movement we should try to monitor for any change in editor state and block the cc popups, right?

That is a possibility, but this can be very tricky. I kind of like the current behaviour that a CC-request is running in the background and that you can continue on typing without the need of a new CC-request (that is what that column-calculation is for). What would be possible though is an editor-event-handler do a check that if the cursor arrives before the CC-position for whatever reason, cancel out the outstanding CC-request.

Merged (finally!). Thanks.