GNU bug report logs - #11906
24.1; completion-at-point failures

Previous Next

Full log

View this message in rfc822 format

From: Leo Liu <sdl.web <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 11906 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: bug#11906: 24.1; completion-at-point failures
Date: Sat, 07 Dec 2013 10:05:20 +0800

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.