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

Previous Next

Full log

Message #17 received at 11906 <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 11906 <at> debbugs.gnu.org
Subject: Re: bug#11906: 24.1; completion-at-point failures
Date: Sat, 11 May 2013 09:50:43 +0800

On 2013-05-11 04:36 +0800, Stefan Monnier wrote:
> <fiddling around some more>
>
> Ah, OK.
> so I should type RET before "history 10", so history shows me the last
> commands run by octave.

Sorry, I wasn't clear.

> The difference between 2 and 3 calls shouldn't be sufficiently large to
> go from "acceptable" to "terrible delay".

It is a difference between 1 and 3 calls because a user can also run
octave in terminal and find that how responsive it actually is.

I noticed this long delay when completing empty strings
(octave-completion-at-point used to allow empty strings). Emacs will be
busy for a few seconds (something like 3 ~ 5 seconds in my laptop).
Given how often I use the TAB key, it was terrible experience.

> Using a cache is a good idea: when there's no completion, the completion
> code may call the completion-table many more times than just 3 times
> (typically, it will call it at least once per completion-style).

I just want to point out these problems in the completion-at-point
machinery.

I think if completion-at-point can work well when there is a 2-second
cost in a completion-at-point function, it can provide an excellent
experience.

>         Stefan

Thanks,
Leo

Previous Next

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