bug#11906: 24.1; completion-at-point failures

[Leo Liu <sdl.web@gmail.com>]

On 2013-12-07 01:35 +0800, Stefan Monnier wrote:
[snipped 5 lines]
> This would be a bug (probably in the completion-at-point-function).
[snipped 4 lines]
> That should "never" be necessary.

On 2013-12-07 01:36 +0800, Stefan Monnier wrote:
[snipped 3 lines]
> There's no technical reason not to, but... why would we want to do that?
[snipped 3 lines]

For this case:

--8<---------------cut here---------------start------------->8---
Assume three candidates (ObjC selectors) for completion and
completion-cycle-threshold is 5:

  1. stringWithContentsOfFile:
  2. stringWithContentsOfFile:encoding:error:
  3. stringWithContentsOfFile:usedEncoding:error:

After cycling a few times, I see:
[NSString stringWithContentsOfFile:stringWithContentsOfFile:encoding:error:stringWithContentsOfFile:usedEncodin$
--8<---------------cut here---------------end--------------->8---

So indeed it is the capf's failure to go back to the proper starting
point after the insertion of the first completion candidate. But the
capf could have no idea what chars the completion candidates can be made
of. In the example it is : that capf needs to handle. sometimes it is
SPC or [ or { or whatever. How can this be handled reliably? Thus my
proposal to use marker. i.e. in the beginning of a completion session
set a start marker.

In general the idea is to make the completion machinery in minibuffer.el
only have to ask capf for information once for each completion session.

Leo