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

Previous Next

Full log

View this message in rfc822 format

From: charles <at> aurox.ch (Charles A. Roelli)
To: npostavs <at> users.sourceforge.net
Cc: 25753 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#25753: 25.2; Python mode shell interaction not working 100%
Date: Sat, 25 Feb 2017 23:28:12 +0100

On Sat, Feb 25 2017 at 09:34:10 am, npostavs <at> users.sourceforge.net wrote:

> charles <at> aurox.ch (Charles A. Roelli) writes:
>
>> Could you please evaluate these forms with a running instance of
>> Python in Emacs?  My output follows each form.  It seems like the Mac
>> version of Python echoes the last command sent, and maybe python.el
>> does not expect this?
>
> Yes, I was going to ask if you also get this echoing for commands typed
> in at the prompt or is it just the support functions?  

Seems to be everywhere.

> Possibly setting `comint-process-echoes' could help, though I don't
> understand why there is echoing in the first place.

Thanks for the pointer to that variable.  I ran this:

   (add-hook 'inferior-python-mode-hook (lambda () (setq comint-process-echoes t)))

and the commands at the prompt stopped echoing, but the support
functions still echoed.  So it looks like the problem has to be fixed on
the readline/libedit side of Python.

> Here is what I get:
>
>     (python-shell-send-string-no-output "import os\nimport sys") ;=> ""
>     (python-shell-send-string-no-output "import os; import sys") ;=> ""
>     (python-ffap-module-path "os") ;=> "/usr/lib/python3.6/os.py"

Thanks.  I managed to fix my setup to give equivalent results (see below).

> By the way, it was reported[1] that using "homebrew" python avoids these
> issues, apparently that build uses GNU readline instead of libedit[2].
>
> [1]: https://github.com/jorgenschaefer/elpy/issues/887#issuecomment-282215656
> [2]: https://github.com/jorgenschaefer/elpy/issues/887#issuecomment-282332143

Thanks for setting me on this trail.  It turns out there's a package you
can install via `easy_install' (part of Python's `setuptools') called
`gnureadline' [1] (formerly called just `readline') which is supposed to
shadow python2.7/lib-dynload/'s `readline.so' with a relatively
up-to-date statically linked GNU replacement (for those of us with a
wacky `libedit'-ized version).  So it would seem that `sudo easy_install
gnureadline' is the right thing to run.  However that still does not fix
the issue because python2.7/lib-dynload/ comes before
python2.7/site-packages/ (where `gnureadline' is installed) in Python's
$PATH equivalent, `sys.path'.  The solution, then, is to reorder the
path somehow or get `readline.so' out of the way (maybe by renaming it
-- cleaner suggestions welcome).  I haven't tested that yet, but it
should work as expected.

At the moment I've been running M-x run-python from the
python2.7/site-packages/ folder where `readline.py' is stored, since
Python adds the path of the current directory to the front of
`sys.path'.  That means `readline.py' gets picked from there, which is
convenient, if not a little surprising at first.  With that done, the
forms I posted previously evaluate as expected, without the code
echoing.  Eldoc also works fine.  Maybe we can add a notice about this
somewhere in python.el in emacs-25.  I'm not sure yet about the best way
to handle the path ordering issue between `readline.so' and
`gnureadline'.

[1] https://pypi.python.org/pypi/gnureadline

Previous Next

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