[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11906: 24.1; completion-at-point failures
From: |
Stefan Monnier |
Subject: |
bug#11906: 24.1; completion-at-point failures |
Date: |
Fri, 10 May 2013 16:36:05 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
>>> 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.
>> Can you explain how "this causes problems"? What makes you think
>> it's related?
> OK, I just hit another performance issue with this repetitive invoking
> of completion functions by completion-at-point. To see this issue:
> 1. emacs -q (choose an emacs that doesn't have the fix in revision 112539)
> 2. M-x run-octave
> 3. Type 'uint <TAB>'
> 4. Type 'history 10'
I don't understand this recipe: where should I type "history 10"? right
there after the "uint" text?
> You should see:
> 1040 completion_matches ("uint");
> 1041 completion_matches ("uint");
> 1042 completion_matches ("uint");
> 1043 history 5
Where should I see it?
<fiddling around some more>
Ah, OK.
so I should type RET before "history 10", so history shows me the last
commands run by octave.
> So basically computation for the matches against 'uint' has been done
> three times.
Fine, yes. There can be various reasons why the completion table is run
several times. In the present case, 2 is the minimum: once to try and
complete "uint" (which just returns "uint") and once to get the
completion candidates. Why there's a third call? I couldn't tell you
off the top of my head. Maybe it's an inefficiency somewhere.
> Now when the computation is expensive (such as against the
> empty string "") one should observe a terrible delay.
The difference between 2 and 3 calls shouldn't be sufficiently large to
go from "acceptable" to "terrible delay".
> I have to work around this issue in octave by revision 112539.
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).
Stefan
- bug#11906: 24.1; completion-at-point failures, Leo Liu, 2013/05/10
- bug#11906: 24.1; completion-at-point failures,
Stefan Monnier <=
- bug#11906: 24.1; completion-at-point failures, Leo Liu, 2013/05/10
- bug#11906: 24.1; completion-at-point failures, Stefan Monnier, 2013/05/10
- bug#11906: 24.1; completion-at-point failures, Leo Liu, 2013/05/11
- bug#11906: 24.1; completion-at-point failures, Stefan Monnier, 2013/05/11
- bug#11906: 24.1; completion-at-point failures, Leo Liu, 2013/05/12
- bug#11906: 24.1; completion-at-point failures, Stefan Monnier, 2013/05/13
- bug#11906: 24.1; completion-at-point failures, Leo Liu, 2013/05/13
- bug#11906: 24.1; completion-at-point failures, Stefan Monnier, 2013/05/13
- bug#11906: 24.1; completion-at-point failures, Leo Liu, 2013/05/13
- bug#11906: 24.1; completion-at-point failures, Andreas Röhler, 2013/05/11