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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#11906: closed (24.1; completion-at-point failures)
Date: Sat, 07 Dec 2013 16:14:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Sat, 07 Dec 2013 18:13:36 +0200
with message-id <52A34930.7080908 <at> yandex.ru>
and subject line Re: bug#11906: 24.1; completion-at-point failures
has caused the debbugs.gnu.org bug report #11906,
regarding 24.1; completion-at-point failures
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
11906: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11906
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Leo <sdl.web <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.1; completion-at-point failures
Date: Wed, 11 Jul 2012 13:54:00 +0800

Hello Stefan,

Despite these critical points, I have witnessed great improvement over
completions in earlier versions of Emacs. So thanks.

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$

i.e. succeeding completion failed to remove previous one before
inserting its own, it is, in this case, due to : in the completions. But
the problem is general, completion-at-point can be tripped over by chars
in the completion candidates. I can imagine it fails too if completion
contains spaces.

I dug a bit and realised that completion-at-point depended too much on
members in completion-at-point-functions. Those functions are called
multiple times for each trigger of completion. So it can be extremely
slow when the calculation is slow. For example, preparing the completion
table in ObjC could take a few seconds for libclang to analyse the
source and turn the output into something suitable for consumption in
Emacs. It seems completion-at-point should be able to do its entire work
after obtaining once the data from those functions. This would free
users of completion-at-point-functions from worrying about caching.

completion-at-point also invokes those functions in order to decide when
to exit. This causes problems illustrated at the beginning of this
report and, for example, I have also experienced delay in inserting
space, dot, etc following a completion.

Leo

[Message part 3 (message/rfc822, inline)]

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 11906-done <at> debbugs.gnu.org
Subject: Re: bug#11906: 24.1; completion-at-point failures
Date: Sat, 07 Dec 2013 18:13:36 +0200

On 07.12.2013 04:40, Leo Liu wrote:
> [snipped 9 lines]

I think you skipped the most important practical point - that your 
initial Object-C example can be made to work properly using the current 
completion-at-point-functions interface.

> These are good points. I think we need a new way for completion. Thanks
> for your work and feel free to close this bug.

Sure, no problem.

Previous Next

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