[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#11906: closed (24.1; completion-at-point failures)

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#11906: closed (24.1; completion-at-point failures)
Date: Sat, 07 Dec 2013 16:14:02 +0000

Your message dated Sat, 07 Dec 2013 18:13:36 +0200
with message-id <address@hidden>
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

11906: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11906
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- 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:

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.


--- End Message ---
--- Begin Message --- Subject: Re: bug#11906: 24.1; completion-at-point failures Date: Sat, 07 Dec 2013 18:13:36 +0200 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
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.

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]