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

Previous Next

Full log

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

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: Re: bug#25753: 25.2; Python mode shell interaction not working 100%
Date: Tue, 28 Feb 2017 11:34:12 +0100

On Sun, Feb 26 2017 at 09:14:45 pm, npostavs <at> users.sourceforge.net wrote:

> charles <at> aurox.ch (Charles A. Roelli) writes:
>
>> On Sat, Feb 25 2017 at 09:34:10 am, npostavs <at> users.sourceforge.net wrote:
>>
>>> 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.
>
> This thread[1] might be somewhat relevant:
>
>     The problem is that eshell tells subprocesses that they're running in
>     a terminal (e.g., when queried via hIsTerminalDevice), but always
>     echos user input itself regardless of the tty's ECHO attribute. This
>     confuses libedit, which assumes that if it's connected to a terminal
>     then it can turn off echoing in order to run its own rich line editor.
>
> [1]:
> http://glasgow-haskell-users.haskell.narkive.com/vyeVJUEB/problem-with-echo-prompting-in-ghci-visible-in-emacs

Thanks.  FWIW, I tried this approach:

> Given this info, there's a fairly easy emacs haskell-mode work-around. I
> made a shell script "ghci-no-tty" in my ~/bin that contains
> 
> # So ghci+readline won't echo input
> cat | /usr/local/bin/ghci $*
> 
> and used "M-x customize-group" with the "haskell" group to set the "Haskell
> Program Name" variable to "/home/conal/bin/ghci-no-tty" (must be full path).
> 
> Now there's no more input echoing, and commands like automatic signature
> insertion ("\C-c\C-t") work again.

using `python-shell-interpreter' and `cat | python $'.  Python exited
immediately with code 126, so I guess this solution does not work here.
But I can't claim to understand any issues having to do with TTYs/"dumb
terminals", so maybe I am missing something.

>>  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 guess renaming should have the least amount of side-effects.

Great.  This is what works for me:

cd /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload
mv readline.so readline.so.bak

Hopefully we can add into emacs-25 a comment about this situation,
advising Mac OS X users to install `gnureadline' with `easy_install
gnureadline', then renaming `readline.so' to something not ending in
`.so', if the native completion does not work immediately.

Previous Next

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