[Top][All Lists]

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

[debbugs-tracker] bug#19755: closed (python.el: native completion: more

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#19755: closed (python.el: native completion: more problems (and solutions))
Date: Thu, 09 Apr 2015 03:57:02 +0000

Your message dated Thu, 09 Apr 2015 00:55:59 -0300
with message-id <address@hidden>
and subject line python.el: native completion: more problems (and solutions)
has caused the debbugs.gnu.org bug report #19755,
regarding python.el: native completion: more problems (and solutions)
to be marked as done.

(If you believe you have received this mail in error, please contact

19755: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19755
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: python.el: native completion: more problems (and solutions) Date: Tue, 3 Feb 2015 09:40:21 -0300
X-Debbugs-CC: address@hidden
Tags: patch

Hi Fabian,

besides the ones l have already reported and patched in [1] there are
some remaining problems with the native completion approach:

1) The waiting timeout is too low for import completions, as imports
take a bit more time than simple dirs. But making the timeout larger
is bad for cases when there really is no completion at all for the
current prefix. I want to avoid this trade off.

2) When all the completions share a common prefix, readline completes
inline up to this common prefix, so the delete-line-command sequence
length is wrong. For example, say the current prefix is "x" and that
its completions are "xxy", "xxz". Readline will complete "xx" inline,
but delete-line-command will only delete one "x".

3) A pager could be enabled to show long lists of completions.

My solutions for 1 and 2 simply extend the dummy completion hack I
introduced in [1]:

1') Ensure there is always one completion at least (a fortiori, I'm
ensuring there are at least two completions, to force listing instead
of inline completion). So we can set a larger timeout *just for the
first* accept-process-output without the risk of waiting too much when
there is really no completion available.

2') Ensure there is a completion with a different prefix, by providing
a dummy randomly prefixed completion.

For 3 I just disabled paged completions for readline, but I don't know
how to do that for libedit.

Attached is a patch with all the described changes, applied on top of
my patch for [1]. Anyway, it should be easy to selectively apply the
changes manually.

All in all I find the solution pretty simple and it leverages my
previous trick. The completer is a bit more complex now as it has to
keep track of a couple of states in order to generate the correct
sequence of completions (dummies included):

    def completer(text, state,
        completion = None
        if state == 0:
            last_state[0] = None
        if last_state[0] is None:
            completion = real_completer(text, state)
            if not completion:
                last_state[0] = state
        if (state == last_state[0] or
            state - 1 == last_state[0] == 0):
            import random
            completion = '%s%d__dummy_completion__' % (
                text, random.randint(1000, 10000))
        return completion


[1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19736

Attachment: native-compl.patch
Description: Text Data

--- End Message ---
--- Begin Message --- Subject: python.el: native completion: more problems (and solutions) Date: Thu, 09 Apr 2015 00:55:59 -0300 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
Hola Carlos,

I pushed a fix for this at revno 911ed2e in the master branch.

I'll be slowly catching up, sorry for the long delay.


--- End Message ---

reply via email to

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