GNU bug report logs - #28580
[w32] python.el: native completion setup failed

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 28580 in the body.
You can then email your comments to 28580 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Андрей Парамонов
 <cmr.pent <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: python.el: native completion setup failed
Date: Sun, 24 Sep 2017 18:56:32 +0300

[Message part 1 (text/plain, inline)]

Hello!

I'm on Windows, using Python3 from Anaconda distrib. I've set option
 '(python-shell-interpreter "py")

When doing
M-x run-python
I get
Warning (python): Your ‘python-shell-interpreter’ doesn’t seem to support
readline, yet ‘python-shell-completion-native-enable’ was t and "py" is not
part of the ‘python-shell-completion-native-disabled-interpreters’ list.
Native completions have been disabled locally.

Python 3.6.1 |Anaconda 4.4.0 (64-bit)| (default, May 11 2017, 13:25:24)
[MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> python.el: native completion setup failed
>>>

It is expected that Python completion works out-of-the-box, without
warnings.

Ready to provide any additional info,
Andrey Paramonov

In GNU Emacs 25.3.1 (x86_64-w64-mingw32)
 of 2017-09-17 built on LAPHROAIG
Windowing system distributor 'Microsoft Corp.', version 6.3.9600
Configured using:
 'configure --without-dbus --without-compress-install 'CFLAGS=-O2
 -static -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: RUS
  locale-coding-system: cp1252

Major mode: Special

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...
You can run the command    run-python    with C-c C-p
Shell native completion is disabled, using fallback

Load-path shadows:
None found.

Features:
(shadow sort mail-extr thingatpt emacsbug message dired rfc822 mml
mml-sec epg mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mail-utils
warnings compile tramp-cache python tramp-sh tramp tramp-compat
auth-source cl-seq eieio eieio-core cl-macs gnus-util mm-util help-fns
mail-prsvr password-cache tramp-loaddefs trampver ucs-normalize shell
pcomplete format-spec advice json map comint ring ansi-color finder-inf
info tex-site package epg-config seq byte-opt gv bytecomp byte-compile
cl-extra help-mode easymenu cconv cl-loaddefs pcase cl-lib time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table w32-win w32-vars
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
w32notify w32 multi-tty make-network-process emacs)

Memory information:
((conses 16 238322 10475)
 (symbols 56 24227 0)
 (miscs 48 129 150)
 (strings 32 31786 7274)
 (string-bytes 1 989742)
 (vectors 16 40361)
 (vector-slots 8 734537 6096)
 (floats 8 256 140)
 (intervals 56 426 0)
 (buffers 976 24))

[Message part 2 (text/html, inline)]

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Андрей Парамонов
 <cmr.pent <at> gmail.com>
Cc: 28580 <at> debbugs.gnu.org
Subject: Re: bug#28580: python.el: native completion setup failed
Date: Sun, 24 Sep 2017 12:14:23 -0400

Андрей Парамонов <cmr.pent <at> gmail.com> writes:

> Hello!
>
> I'm on Windows, using Python3 from Anaconda distrib. I've set option
>  '(python-shell-interpreter "py")
>
> When doing
> M-x run-python
> I get
> Warning (python): Your ‘python-shell-interpreter’ doesn’t seem to
> support readline, yet ‘python-shell-completion-native-enable’ was t
> and "py" is not part of the
> ‘python-shell-completion-native-disabled-interpreters’ list.  Native
> completions have been disabled locally. 
>
> Python 3.6.1 |Anaconda 4.4.0 (64-bit)| (default, May 11 2017,
> 13:25:24) [MSC v.1900 64 bit (AMD64)] on win32
> Type "help", "copyright", "credits" or "license" for more
> information.
>>>> python.el: native completion setup failed
>>>>
>
> It is expected that Python completion works out-of-the-box, without
> warnings.

Seems to be impossible, unfortunately.  Does this commentary from
python.el help?

;; If your Python installation lacks readline (like CPython for
;; Windows), installing pyreadline (URL
;; `http://ipython.org/pyreadline.html') should suffice.  To
;; troubleshoot why you are not getting any completions, you can try the
;; following in your Python shell:

;; >>> import readline, rlcompleter

;; If you see an error, then you need to either install pyreadline or
;; setup custom code that avoids that dependency.

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

From: Андрей Парамонов
 <cmr.pent <at> gmail.com>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 28580 <at> debbugs.gnu.org
Subject: Re: bug#28580: python.el: native completion setup failed
Date: Sun, 24 Sep 2017 19:56:39 +0300

[Message part 1 (text/plain, inline)]

Hi Noam,

and thank you for a quick reply!

2017-09-24 19:14 GMT+03:00 Noam Postavsky <npostavs <at> users.sourceforge.net>:

> > It is expected that Python completion works out-of-the-box, without
> > warnings.
>
> Seems to be impossible, unfortunately.  Does this commentary from
> python.el help?
>
> ;; If your Python installation lacks readline (like CPython for
> ;; Windows), installing pyreadline (URL
> ;; `http://ipython.org/pyreadline.html') should suffice.  To
> ;; troubleshoot why you are not getting any completions, you can try the
> ;; following in your Python shell:


> ;; >>> import readline, rlcompleter
>
> ;; If you see an error, then you need to either install pyreadline or
> ;; setup custom code that avoids that dependency.
>

It didn't help, unfortunately: I was indeed missing pyreadline, but
installing it from conda repo made no difference :-(
Neither did using "-i -u" as interactive Python arg.

I vaguely remember this working with older Pythons -- what could probably
change?

Best wishes,
Andrey Paramonov

[Message part 2 (text/html, inline)]

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Андрей Парамонов
 <cmr.pent <at> gmail.com>
Cc: 28580 <at> debbugs.gnu.org
Subject: Re: bug#28580: python.el: native completion setup failed
Date: Sun, 24 Sep 2017 13:51:19 -0400

Андрей Парамонов <cmr.pent <at> gmail.com> writes:

> It didn't help, unfortunately: I was indeed missing pyreadline, but
> installing it from conda repo made no difference :-(
> Neither did using "-i -u" as interactive Python arg.
>
> I vaguely remember this working with older Pythons -- what could
> probably change?

Hmm, can you try running the python code from
python-shell-completion-native-setup manually from a prompt and see what
comes out? (or where it goes wrong)

def __PYTHON_EL_native_completion_setup():
    try:
        import readline

        try:
            import __builtin__
        except ImportError:
            # Python 3
            import builtins as __builtin__

        builtins = dir(__builtin__)
        is_ipython = ('__IPYTHON__' in builtins or
                      '__IPYTHON__active' in builtins)

        class __PYTHON_EL_Completer:
            '''Completer wrapper that prints candidates to stdout.

            It wraps an existing completer function and changes its behavior so
            that the user input is unchanged and real candidates are printed to
            stdout.

            Returned candidates are '0__dummy_completion__' and
            '1__dummy_completion__' in that order ('0__dummy_completion__' is
            returned repeatedly until all possible candidates are consumed).

            The real candidates are printed to stdout so that they can be
            easily retrieved through comint output redirect trickery.
            '''

            PYTHON_EL_WRAPPED = True

            def __init__(self, completer):
                self.completer = completer
                self.last_completion = None
                self.print_mode = True

            def __call__(self, text, state):
                if state == 0:
                    # Set the first dummy completion.
                    self.last_completion = None
                    completion = '0__dummy_completion__'
                else:
                    completion = self.completer(text, state - 1)

                if not completion:
                    if self.last_completion != '1__dummy_completion__':
                        # When no more completions are available, returning a
                        # dummy with non-sharing prefix allow ensuring output
                        # while preventing changes to current input.
                        # Coincidentally it's also the end of output.
                        completion = '1__dummy_completion__'
                elif completion.endswith('('):
                    # Remove parens on callables as it breaks completion on
                    # arguments (e.g. str(Ari<tab>)).
                    completion = completion[:-1]
                self.last_completion = completion

                if completion in (
                        '0__dummy_completion__', '1__dummy_completion__'):
                    return completion
                elif completion:
                    # For every non-dummy completion, return a repeated dummy
                    # one and print the real candidate so it can be retrieved
                    # by comint output filters.
                    if self.print_mode:
                        print (completion)
                        return '0__dummy_completion__'
                    else:
                        return completion
                else:
                    return completion

        completer = readline.get_completer()

        if not completer:
            # Used as last resort to avoid breaking customizations.
            import rlcompleter
            completer = readline.get_completer()

        if completer and not getattr(completer, 'PYTHON_EL_WRAPPED', False):
            # Wrap the existing completer function only once.
            new_completer = __PYTHON_EL_Completer(completer)
            if not is_ipython:
                readline.set_completer(new_completer)
            else:
                # Try both initializations to cope with all IPython versions.
                # This works fine for IPython 3.x but not for earlier:
                readline.set_completer(new_completer)
                # IPython<3 hacks readline such that `readline.set_completer`
                # won't work.  This workaround injects the new completer
                # function into the existing instance directly:
                instance = getattr(completer, 'im_self', completer.__self__)
                instance.rlcomplete = new_completer

        if readline.__doc__ and 'libedit' in readline.__doc__:
            readline.parse_and_bind('bind ^I rl_complete')
        else:
            readline.parse_and_bind('tab: complete')
            # Require just one tab to send output.
            readline.parse_and_bind('set show-all-if-ambiguous on')

        print ('python.el: native completion setup loaded')
    except:
        print ('python.el: native completion setup failed')

__PYTHON_EL_native_completion_setup()

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

From: Андрей Парамонов
 <cmr.pent <at> gmail.com>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 28580 <at> debbugs.gnu.org
Subject: Re: bug#28580: python.el: native completion setup failed
Date: Sun, 24 Sep 2017 21:02:53 +0300

[Message part 1 (text/plain, inline)]

Hi Noam!

2017-09-24 20:51 GMT+03:00 Noam Postavsky <npostavs <at> users.sourceforge.net>:

> > It didn't help, unfortunately: I was indeed missing pyreadline, but
> > installing it from conda repo made no difference :-(
> > Neither did using "-i -u" as interactive Python arg.
> >
> > I vaguely remember this working with older Pythons -- what could
> > probably change?
>
> Hmm, can you try running the python code from
> python-shell-completion-native-setup manually from a prompt and see what
> comes out? (or where it goes wrong)
>

It is too tiresome to input it one-by-one line!
When I invoke
>py -i t.py
where t.py contains the code you listed, all is silently Ok.
Should I take time and enter it line-by-line, interactively -- or the
problem is likely elsewhere?

Best wishes,
Andrey Paramonov

[Message part 2 (text/html, inline)]

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Андрей Парамонов
 <cmr.pent <at> gmail.com>
Cc: 28580 <at> debbugs.gnu.org
Subject: Re: bug#28580: python.el: native completion setup failed
Date: Sun, 24 Sep 2017 14:09:46 -0400

Андрей Парамонов <cmr.pent <at> gmail.com> writes:

> When I invoke
>>py -i t.py
> where t.py contains the code you listed, all is silently Ok.

Hmm, "silently"?  You mean you don't get a 'python.el: native completion
setup loaded' message?  If you enter a partial function name afterwards,
e.g. "ra" and then hit TAB, do you get the '0__dummy_completion__' etc
output?

> Should I take time and enter it line-by-line, interactively -- or the
> problem is likely elsewhere?

No, don't enter line-by-line, Emacs doesn't do that either (it writes to
a temp file, then submits the temp file). 

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

From: Андрей Парамонов
 <cmr.pent <at> gmail.com>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 28580 <at> debbugs.gnu.org
Subject: Re: bug#28580: python.el: native completion setup failed
Date: Sun, 24 Sep 2017 21:16:53 +0300

[Message part 1 (text/plain, inline)]

2017-09-24 21:09 GMT+03:00 Noam Postavsky <npostavs <at> users.sourceforge.net>:

> Hmm, "silently"?  You mean you don't get a 'python.el: native completion
> setup loaded' message?  If you enter a partial function name afterwards,
> e.g. "ra" and then hit TAB, do you get the '0__dummy_completion__' etc
> output?
>

Ah, sorry for not being clear. I was meaning "no error". What I get is:
python.el: native completion setup loaded
>>> ra[Tab]raise
range

0__dummy_completion__ 1__dummy_completion__
>>> ra

I think it's as expected?

Best wishes,
Andrey Paramonov

[Message part 2 (text/html, inline)]

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Андрей Парамонов
 <cmr.pent <at> gmail.com>
Cc: 28580 <at> debbugs.gnu.org
Subject: Re: bug#28580: python.el: native completion setup failed
Date: Sun, 24 Sep 2017 15:39:13 -0400

Андрей Парамонов <cmr.pent <at> gmail.com> writes:

> Ah, sorry for not being clear. I was meaning "no error". What I get
> is:
> python.el: native completion setup loaded
>>>> ra[Tab]raise
> range
>
> 0__dummy_completion__ 1__dummy_completion__
>>>> ra
>
> I think it's as expected?

Right, that all looks fine, so the question is what goes wrong from the
Emacs side.  What do you get from evaluating this in Emacs:

    (call-process
     "py" nil '(t t) nil
     "-i" "t.py")

Does it make any difference if you use python-shell-with-environment?

    (python-shell-with-environment
      (call-process
       "py" nil '(t t) nil
       "-i" "t.py"))

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

From: Андрей Парамонов
 <cmr.pent <at> gmail.com>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 28580 <at> debbugs.gnu.org
Subject: Re: bug#28580: python.el: native completion setup failed
Date: Sun, 24 Sep 2017 22:57:41 +0300

[Message part 1 (text/plain, inline)]

2017-09-24 22:39 GMT+03:00 Noam Postavsky <npostavs <at> users.sourceforge.net>:

> Right, that all looks fine, so the question is what goes wrong from the
> Emacs side.  What do you get from evaluating this in Emacs:
>
>     (call-process
>      "py" nil '(t t) nil
>      "-i" "t.py")
>
> Does it make any difference if you use python-shell-with-environment?
>
>     (python-shell-with-environment
>       (call-process
>        "py" nil '(t t) nil
>        "-i" "t.py"))
>

Hmm, in both cases I get correct report (eval-region from *scratch* buffer):
(python-shell-with-environment
      (call-process
       "py" nil '(t t) nil
       "-i" "t.py"))python.el: native completion setup loaded
>>>

But run-python still has completion not working :-(

Best wishes,
Andrey Paramonov

[Message part 2 (text/html, inline)]

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Андрей Парамонов
 <cmr.pent <at> gmail.com>
Cc: 28580 <at> debbugs.gnu.org
Subject: Re: bug#28580: python.el: native completion setup failed
Date: Sun, 24 Sep 2017 16:06:15 -0400

Андрей Парамонов <cmr.pent <at> gmail.com> writes:

> Hmm, in both cases I get correct report (eval-region from *scratch*
> buffer):
> (python-shell-with-environment
>       (call-process
>        "py" nil '(t t) nil
>        "-i" "t.py"))python.el: native completion setup loaded
>>>> 
>
> But run-python still has completion not working :-(

Darn.  What if you M-x run-python and then use C-c C-c in "t.py" to send
it to the shell?

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

From: Андрей Парамонов
 <cmr.pent <at> gmail.com>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 28580 <at> debbugs.gnu.org
Subject: Re: bug#28580: python.el: native completion setup failed
Date: Sun, 24 Sep 2017 23:19:23 +0300

[Message part 1 (text/plain, inline)]

2017-09-24 23:06 GMT+03:00 Noam Postavsky <npostavs <at> users.sourceforge.net>:

> Darn.  What if you M-x run-python and then use C-c C-c in "t.py" to send
> it to the shell?
>

Bad news: the message
Warning (python): Your ‘python-shell-interpreter’ doesn’t seem to support
readline, yet ‘python-shell-completion-native-enable’ was t and "py" is not
part of the ‘python-shell-completion-native-disabled-interpreters’ list.
Native completions have been disabled locally.
still appears when I M-x run-python

Good news: python shell buffer now displays
>>> python.el: native completion setup loaded
after I eval the contents of t.py. Actually, it displays the message upon
loading, and completion does work. I must have believed the warning rather
than checked, after install of pyreadline.

Why the message appears? It tells that completion is disabled which is not
true!

Best wishes,
Andrey Paramonov

[Message part 2 (text/html, inline)]

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Андрей Парамонов
 <cmr.pent <at> gmail.com>
Cc: 28580 <at> debbugs.gnu.org
Subject: Re: bug#28580: python.el: native completion setup failed
Date: Sun, 24 Sep 2017 16:30:26 -0400

Андрей Парамонов <cmr.pent <at> gmail.com> writes:

> Bad news: the message
> Warning (python): Your ‘python-shell-interpreter’ doesn’t seem to
> support readline, yet ‘python-shell-completion-native-enable’ was t
> and "py" is not part of the
> ‘python-shell-completion-native-disabled-interpreters’ list.  Native
> completions have been disabled locally. 
> still appears when I M-x run-python
>
> Good news: python shell buffer now displays
>>>> python.el: native completion setup loaded
> after I eval the contents of t.py. Actually, it displays the message
> upon loading, and completion does work. I must have believed the
> warning rather than checked, after install of pyreadline.

Can you clarify, if you just run M-x run-python without doing anything
with "t.py" you see the "python.el: native completion setup loaded" or
the "python.el: native completion setup failed" message?

> Why the message appears? It tells that completion is disabled which
> is not true!

The "native" completion might still be disabled, and you're actually
using the "fallback" method.

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

From: Андрей Парамонов
 <cmr.pent <at> gmail.com>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 28580 <at> debbugs.gnu.org
Subject: Re: bug#28580: python.el: native completion setup failed
Date: Sun, 24 Sep 2017 23:34:07 +0300

[Message part 1 (text/plain, inline)]

2017-09-24 23:30 GMT+03:00 Noam Postavsky <npostavs <at> users.sourceforge.net>:

> Can you clarify, if you just run M-x run-python without doing anything
> with "t.py" you see the "python.el: native completion setup loaded" or
> the "python.el: native completion setup failed" message?
>

I see now
>>> python.el: native completion setup loaded


> The "native" completion might still be disabled, and you're actually
> using the "fallback" method.
>

That should be suboptimal -- otherwise why the warning?
What could make the "native" completion fail? How to check if it's really
the case?

Best wishes,
Andrey Paramonov

[Message part 2 (text/html, inline)]

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Андрей Парамонов
 <cmr.pent <at> gmail.com>
Cc: 28580 <at> debbugs.gnu.org
Subject: Re: bug#28580: python.el: native completion setup failed
Date: Sun, 24 Sep 2017 17:00:28 -0400

Андрей Парамонов <cmr.pent <at> gmail.com> writes:

> That should be suboptimal -- otherwise why the warning?
> What could make the "native" completion fail?

Does M-: (python-shell-completion-native-try) RET in the *Python* buffer
return nil?  Perhaps try putting some `message' calls into
python-shell-completion-native-get-completions? (Using the debugger is a
bit tricky due to the timing of process communication.)  Especially
check the contents of the current inside the `when' block at the end:

              ;; Grab output until our dummy completion used as
              ;; output end marker is found.
              (when (python-shell-accept-process-output
                     process python-shell-completion-native-output-timeout
                     comint-redirect-finished-regexp)
                (re-search-backward "0__dummy_completion__" nil t)
                (cl-remove-duplicates
                 (split-string
                  (buffer-substring-no-properties
                   (line-beginning-position) (point-min))
                  "[ \f\t\n\r\v()]+" t)
                 :test #'string=))

> How to check if it's really the case?

Try the recipe in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28051#8
and see if you suffer from that bug.

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

From: Андрей Парамонов
 <cmr.pent <at> gmail.com>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 28580 <at> debbugs.gnu.org
Subject: Re: bug#28580: python.el: native completion setup failed
Date: Mon, 25 Sep 2017 00:08:50 +0300

[Message part 1 (text/plain, inline)]

2017-09-25 0:00 GMT+03:00 Noam Postavsky <npostavs <at> users.sourceforge.net>:

> Does M-: (python-shell-completion-native-try) RET in the *Python* buffer
> return nil?


Yes it does!


> Perhaps try putting some `message' calls into
> python-shell-completion-native-get-completions? (Using the debugger is a
> bit tricky due to the timing of process communication.)  Especially
> check the contents of the current inside the `when' block at the end:
>
>               ;; Grab output until our dummy completion used as
>               ;; output end marker is found.
>               (when (python-shell-accept-process-output
>                      process python-shell-completion-native-output-timeout
>                      comint-redirect-finished-regexp)
>                 (re-search-backward "0__dummy_completion__" nil t)
>                 (cl-remove-duplicates
>                  (split-string
>                   (buffer-substring-no-properties
>                    (line-beginning-position) (point-min))
>                   "[ \f\t\n\r\v()]+" t)
>                  :test #'string=))
>

Unfortunately my distrib doesn't seem to have the source el-files :-(


> Try the recipe in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28051#8
> and see if you suffer from that bug.
>

Hm, the bug and the one mentioned inside describe bad behavior of Python2,
but in my case it's the opposite :-/

Best wishes,
Andrey Paramonov

[Message part 2 (text/html, inline)]

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Андрей Парамонов
 <cmr.pent <at> gmail.com>
Cc: 28580 <at> debbugs.gnu.org
Subject: Re: bug#28580: python.el: native completion setup failed
Date: Sun, 24 Sep 2017 17:31:48 -0400

Андрей Парамонов <cmr.pent <at> gmail.com> writes:

> Unfortunately my distrib doesn't seem to have the source el-files :-(

You can find it here: http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/progmodes/python.el?h=emacs-25.3

Make sure to evaluate the changed source *after* you've loaded the
builtin python.el.

>
>     Try the recipe in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=
>     28051#8
>     and see if you suffer from that bug.
>
>
> Hm, the bug and the one mentioned inside describe bad behavior of
> Python2, but in my case it's the opposite :-/

Well really it describes the bad behaviour of the fallback completion.
It just happens that Emacs 25 uses the fallback completion method with
Python2 on Windows.

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

From: Андрей Парамонов
 <cmr.pent <at> gmail.com>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 28580 <at> debbugs.gnu.org
Subject: Re: bug#28580: python.el: native completion setup failed
Date: Mon, 25 Sep 2017 00:37:38 +0300

[Message part 1 (text/plain, inline)]

2017-09-25 0:31 GMT+03:00 Noam Postavsky <npostavs <at> users.sourceforge.net>:

> Андрей Парамонов <cmr.pent <at> gmail.com> writes:
>
> > Unfortunately my distrib doesn't seem to have the source el-files :-(
>
> You can find it here: http://git.savannah.gnu.org/
> cgit/emacs.git/tree/lisp/progmodes/python.el?h=emacs-25.3
>
> Make sure to evaluate the changed source *after* you've loaded the
> builtin python.el.
>

I'll try to find time to debug it.


> >     Try the recipe in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=
> >     28051#8
> >     and see if you suffer from that bug.
> >
> > Hm, the bug and the one mentioned inside describe bad behavior of
> > Python2, but in my case it's the opposite :-/
>
> Well really it describes the bad behaviour of the fallback completion.
> It just happens that Emacs 25 uses the fallback completion method with
> Python2 on Windows.
>

I do not use Python2 on Windows. Rather, I use Python3 on Windows. And it
seems my completion is also "fallback" (which for me reads "suboptimal").
I'd prefer best ;-)

Best wishes,
Andrey Paramonov

[Message part 2 (text/html, inline)]

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Андрей Парамонов
 <cmr.pent <at> gmail.com>
Cc: 28580 <at> debbugs.gnu.org
Subject: Re: bug#28580: python.el: native completion setup failed
Date: Tue, 03 Oct 2017 00:01:02 -0400

I've pushed a change [1: b33808ce77] so that errors will be more helpful
(at least for the case in the original report), e.g., when missing
readline, you would now see something along the lines of:

>>> python.el: native completion setup failed, <type 'exceptions.ImportError'>: No module named readline

[1: b33808ce77]: 2017-10-02 23:15:43 -0400
  Give more helpful messages for python completion setup failures
  http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=b33808ce77ef15c1f233790a2c93d9db4cc588ab>

Андрей Парамонов <cmr.pent <at> gmail.com> writes:

> 2017-09-25 0:31 GMT+03:00 Noam Postavsky <
> npostavs <at> users.sourceforge.net>:
>
>     You can find it here: http://git.savannah.gnu.org/cgit/emacs.git/
>     tree/lisp/progmodes/python.el?h=emacs-25.3
>    
>     Make sure to evaluate the changed source *after* you've loaded
>     the
>     builtin python.el.
>
> I'll try to find time to debug it.

Actually, I think this troubleshooting code I posted earlier would be
helpful in your case as well:
https://debbugs.gnu.org/cgi/bugreport.cgi?filename=py-native-completion.el;att=1;msg=35;bug=25753

Replace "python2" with the name of your python executable, and run via

    emacs -Q -l py-native-completion.el

post the output found in the "*py native complete test*" buffer.

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Андрей Парамонов
 <cmr.pent <at> gmail.com>
Cc: 28580 <at> debbugs.gnu.org
Subject: Re: bug#28580: python.el: native completion setup failed
Date: Thu, 12 Oct 2017 15:40:56 -0400

retitle 28580 [w32] python.el: native completion setup failed
quit

On Tue, Oct 3, 2017 at 12:01 AM, Noam Postavsky
<npostavs <at> users.sourceforge.net> wrote:

> Actually, I think this troubleshooting code I posted earlier would be
> helpful in your case as well:
> https://debbugs.gnu.org/cgi/bugreport.cgi?filename=py-native-completion.el;att=1;msg=35;bug=25753
>
> Replace "python2" with the name of your python executable, and run via
>
>     emacs -Q -l py-native-completion.el
>
> post the output found in the "*py native complete test*" buffer.

I've now installed pyreadline on my Windows box. Unfortunately, as far
as I can tell there is no way to make native completion work on
Windows, readline simply won't work unless python is run from a
console. So we should just disable it under windows to stop the
annoying warning.

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Андрей Парамонов
 <cmr.pent <at> gmail.com>
Cc: 28580 <at> debbugs.gnu.org
Subject: Re: bug#28580: python.el: native completion setup failed
Date: Thu, 12 Oct 2017 23:28:42 -0400

[Message part 1 (text/plain, inline)]

tags 28580 + patch
quit

Noam Postavsky <npostavs <at> users.sourceforge.net> writes:

> I've now installed pyreadline on my Windows box. Unfortunately, as far
> as I can tell there is no way to make native completion work on
> Windows, readline simply won't work unless python is run from a
> console. So we should just disable it under windows to stop the
> annoying warning.

I.e.:

[0001-Disable-python-native-completion-on-w32-Bug-28580.patch (text/x-diff, inline)]

From 1cb9846462844dfbbc34a02bdbdc66de9ce85c20 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs <at> gmail.com>
Date: Thu, 12 Oct 2017 23:25:13 -0400
Subject: [PATCH] Disable python native completion on w32 (Bug#28580)

* lisp/progmodes/python.el
(python-shell-completion-native-disabled-interpreters): For windows-nt
systems, put an empty string to match interpreters.
---
 lisp/progmodes/python.el | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
index f79d9a47d3..895117b9ee 100644
--- a/lisp/progmodes/python.el
+++ b/lisp/progmodes/python.el
@@ -3304,8 +3304,9 @@ python-shell-completion-string-code
 (defcustom python-shell-completion-native-disabled-interpreters
   ;; PyPy's readline cannot handle some escape sequences yet.  Native
   ;; completion was found to be non-functional for IPython (see
-  ;; Bug#25067).
-  (list "pypy" "ipython")
+  ;; Bug#25067).  Native completion doesn't work on w32 (Bug#28580).
+  (if (eq system-type 'windows-nt) '("")
+    '("pypy" "ipython"))
   "List of disabled interpreters.
 When a match is found, native completion is disabled."
   :version "25.1"
-- 
2.11.0

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Андрей Парамонов
 <cmr.pent <at> gmail.com>
Cc: 28580 <at> debbugs.gnu.org
Subject: Re: bug#28580: python.el: native completion setup failed
Date: Sun, 15 Oct 2017 14:23:36 -0400

close 28580 
quit

> Subject: [PATCH] Disable python native completion on w32 (Bug#28580)
>
> * lisp/progmodes/python.el
> (python-shell-completion-native-disabled-interpreters): For windows-nt
> systems, put an empty string to match interpreters.

Pushed to emacs-26.

[1: 5980de3727]: 2017-10-15 13:58:45 -0400
  Disable python native completion on w32 (Bug#28580)
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=5980de3727a0e80b5d70849bd2dd7054318c25d8

Previous Next

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