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

Previous Next

Package: emacs;

Reported by: Leo <sdl.web <at> gmail.com>

Date: Wed, 11 Jul 2012 06:00:01 UTC

Severity: normal

Found in version 24.1

Done: Dmitry Gutov <dgutov <at> yandex.ru>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Leo <sdl.web <at> gmail.com>
Subject: bug#11906: closed (Re: bug#11906: 24.1; completion-at-point failures)
Date: Sat, 07 Dec 2013 16:14:04 +0000
[Message part 1 (text/plain, inline)]
Your bug report

#11906: 24.1; completion-at-point failures

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 11906 <at> debbugs.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: 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.


[Message part 3 (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



This bug report was last modified 11 years and 164 days ago.

Previous Next


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