GNU bug report logs - #25753
Python with libedit (macOS default) echoes input, breaks native completion

Previous Next

Full log

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

From: Live System User <nyc4bos <at> aol.com>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 25753 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 "Charles A. Roelli" <charles <at> aurox.ch>
Subject: Re: bug#25753: 25.2; Python mode shell interaction not working 100%
Date: Sun, 19 Feb 2017 16:32:17 -0500

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

> On Sun, Feb 19, 2017 at 2:39 PM, Live System User <nyc4bos <at> aol.com> wrote:
>>>
>>> Do you see this with 25.2-rc1 on GNU/Linux though?
>>
>>   Fedora doesn't have that version available currently.
>
> Can you try it after M-x load-library python RET and then evaluate
> this new definition of python-shell-completion-native-try:
>
> (defun python-shell-completion-native-try ()
>   "Return non-nil if can trigger native completion."
>   (let ((python-shell-completion-native-enable t)
>         (python-shell-completion-native-output-timeout
>          python-shell-completion-native-try-output-timeout))
>     (python-shell-completion-native-get-completions
>      (get-buffer-process (current-buffer))
>      nil "_")))

    I was already using that (wrapped in a "with-eval-after-load
    'python") from:

    https://github.com/jorgenschaefer/elpy/issues/887#issuecomment-275175119

    to no avail.

>
>>
>>   I did, however, look into the Python modules having to do with
>>   "readline"(completion).
>>
>>   I discovered that if I used the "readline" from "pyrepl.py"instead
>>   of the standard default one, then even though that warning still
>>   occured in a *Warning* buffer in Emacs, I never saw it -- I just
>>   saw   the *Python* buffer and my source buffer, as expected.
>
> I'm not sure what "pyrepl" is or to "use" it, but just looking at web
> search results, it seems to be connected to pypy, which is in the list
> of python-shell-completion-native-disabled-interpreters, could that be
> related?

  Not really but it makes allowances on whether or not pypy.py is
  currently loaded.

  Here is an important piece of pyrepl that appears to be revelent
  to how it deals with input and output from terminals (TTYs) and
  non-terminals:


    if '__pypy__' in sys.builtin_module_names:    # PyPy

        def _old_raw_input(prompt=''):
            # sys.__raw_input__() is only called when stdin and stdout are
            # as expected and are ttys.  If it is the case, then get_reader()
            # should not really fail in _wrapper.raw_input().  If it still
            # does, then we will just cancel the redirection and call again
            # the built-in raw_input().
            try:
                del sys.__raw_input__
            except AttributeError:
                pass
            return raw_input(prompt)
        sys.__raw_input__ = _wrapper.raw_input

    else:
        # this is not really what readline.c does.  Better than nothing I guess
        import __builtin__
        _old_raw_input = __builtin__.raw_input
        __builtin__.raw_input = _wrapper.raw_input

_old_raw_input = None


  I think that this related in the fact that the Emacs interaction is
  not with a real TTY (it doesn't have defined or tigetstr-retrievable
  terminal capabilities (curses) like how to do operations like "clear",
  "cup" or "horizontal" positioning).

  Thanks.

Previous Next

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