GNU bug report logs -
#25753
Python with libedit (macOS default) echoes input, breaks native completion
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 25753 in the body.
You can then email your comments to 25753 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Thu, 16 Feb 2017 16:09:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
charles <at> aurox.ch (Charles A. Roelli):
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 16 Feb 2017 16:09:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
In emacs 25.2 (rc1) and 25.1, interaction with the Python shell does not
seem to be working fully. Python version is '2.7.12 (v2.7.12:d33e0cf91556,
Jun 26 2016, 12:10:39) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]', and
this is on Snow Leopard.
- emacs -Q
- open any Python file
- M-x run-python, and this pops up:
Warning (python): Your ‘python-shell-interpreter’ doesn’t seem to
support readline, yet ‘python-shell-completion-native’ was t and
"python" is not part of the
‘python-shell-completion-native-disabled-interpreters’ list. Native
completions have been disabled locally.
[and yet `import readline, rlcompleter' works fine for me]
- quit that warning, and the *Python* shell states "python.el: native
completion setup loaded".
- test out completion in the shell, it seems to be working okay
(`import sys RET sys . TAB' shows the attributes of `sys'). Not sure
if this is `native' completion though.
- switch to the Python file. Place point over a module, global
variable, function, or function definition, and this pops up in the
echo area (meant to be eldoc documentation, I think):
import codecs, os;
__pyfile = codecs.open('''/var/folders/WP/WPe0Q1iAGc0J7iI6J50jcU+++TI/-Tmp-/py1883fcQ''',encoding='''utf-8''');
__code = __pyfile.read().encode('''utf-8''');
__pyfile.close();
os.remove('''/var/folders/WP/WPe0Q1iAGc0J7iI6J50jcU+++TI/-Tmp-/py1883fcQ''');
exec(compile(__code,'''/path/to/python/buffer/here''','exec'));
[some line breaks included for readability]
The same sort of thing is returned by calling, say,
`(python-ffap-module-path "twisted")'. Any pointers on fixing this?
In GNU Emacs 25.2.1 (x86_64-apple-darwin10.8.0, NS appkit-1038.36 Version 10.6.8 (Build 10K549))
of 2017-02-07 built on gray
Windowing system distributor 'Apple', version 10.3.1038
Configured using:
'configure --with-modules'
Configured features:
JPEG RSVG NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Thu, 16 Feb 2017 17:54:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 25753 <at> debbugs.gnu.org (full text, mbox):
> From: charles <at> aurox.ch (Charles A. Roelli)
> Date: Thu, 16 Feb 2017 17:07:48 +0100
>
> In emacs 25.2 (rc1) and 25.1, interaction with the Python shell does not
> seem to be working fully. Python version is '2.7.12 (v2.7.12:d33e0cf91556,
> Jun 26 2016, 12:10:39) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]', and
> this is on Snow Leopard.
Please try the next RC (should be out in a few days), I think we fixed
that there.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Sat, 18 Feb 2017 17:44:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 25753 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: charles <at> aurox.ch (Charles A. Roelli)
>> Date: Thu, 16 Feb 2017 17:07:48 +0100
>>
>> In emacs 25.2 (rc1) and 25.1, interaction with the Python shell does not
>> seem to be working fully. Python version is '2.7.12 (v2.7.12:d33e0cf91556,
>> Jun 26 2016, 12:10:39) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]', and
>> this is on Snow Leopard.
>
> Please try the next RC (should be out in a few days), I think we fixed
> that there.
AFAIK, the only change since rc1 is to add "ipython" to
python-shell-completion-native-disabled-interpreters. And that should
not affect the problem reported here, which does not seem to involve
ipython.
It might be something macOS specific, because I don't see any problems
on Arch GNU/Linux with python 2.7.13.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Sun, 19 Feb 2017 15:16:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 25753 <at> debbugs.gnu.org (full text, mbox):
npostavs <at> users.sourceforge.net writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: charles <at> aurox.ch (Charles A. Roelli)
>>> Date: Thu, 16 Feb 2017 17:07:48 +0100
>>>
>>> In emacs 25.2 (rc1) and 25.1, interaction with the Python shell does not
>>> seem to be working fully. Python version is '2.7.12 (v2.7.12:d33e0cf91556,
>>> Jun 26 2016, 12:10:39) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]', and
>>> this is on Snow Leopard.
>>
>> Please try the next RC (should be out in a few days), I think we fixed
>> that there.
>
> AFAIK, the only change since rc1 is to add "ipython" to
> python-shell-completion-native-disabled-interpreters. And that should
> not affect the problem reported here, which does not seem to involve
> ipython.
>
> It might be something macOS specific, because I don't see any problems
> on Arch GNU/Linux with python 2.7.13.
I see the problem on GNU/Linux (Fedora):
Warning (python): Your ‘python-shell-interpreter’ doesn’t seem to
support readline, yet ‘python-shell-completion-native’ was t and
"python" is not part of the
‘python-shell-completion-native-disabled-interpreters’ list. Native
completions have been disabled locally.
Python 2.7.13 (default, Jan 13 2017, 10:15:16)
[GCC 6.3.1 20161221 (Red Hat 6.3.1-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> python.el: native completion setup loaded
>>> q<TAB>qu<TAB>
Click on a completion to select it.
In this buffer, type RET to select the completion near point.
Possible completions are:
quit
quopri
In GNU Emacs 25.1.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.20.9)
of 2016-10-13 built on buildvm-05.phx2.fedoraproject.org
Windowing system distributor 'Fedora Project', version 11.0.11803000
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Sun, 19 Feb 2017 15:27:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 25753 <at> debbugs.gnu.org (full text, mbox):
On Sun, Feb 19, 2017 at 10:14 AM, Live System User <nyc4bos <at> aol.com> wrote:
>>
>> It might be something macOS specific, because I don't see any problems
>> on Arch GNU/Linux with python 2.7.13.
>
> I see the problem on GNU/Linux (Fedora):
>
> Warning (python): Your ‘python-shell-interpreter’ doesn’t seem to
[...]
> In GNU Emacs 25.1.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.20.9)
> of 2016-10-13 built on buildvm-05.phx2.fedoraproject.org
> Windowing system distributor 'Fedora Project', version 11.0.11803000
Do you see this with 25.2-rc1 on GNU/Linux though?
There *was* a change since 25.1 (although supposedly that only
affected python 3). Do you have "set colored-stats on" in your
~/.inputrc? There was a report in #24401 of that causing trouble.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Sun, 19 Feb 2017 19:40:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 25753 <at> debbugs.gnu.org (full text, mbox):
Noam Postavsky <npostavs <at> users.sourceforge.net> writes:
> On Sun, Feb 19, 2017 at 10:14 AM, Live System User <nyc4bos <at> aol.com> wrote:
>>>
>>> It might be something macOS specific, because I don't see any problems
>>> on Arch GNU/Linux with python 2.7.13.
>>
>> I see the problem on GNU/Linux (Fedora):
>>
>> Warning (python): Your ‘python-shell-interpreter’ doesn’t seem to
> [...]
>> In GNU Emacs 25.1.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.20.9)
>> of 2016-10-13 built on buildvm-05.phx2.fedoraproject.org
>> Windowing system distributor 'Fedora Project', version 11.0.11803000
>
> Do you see this with 25.2-rc1 on GNU/Linux though?
Fedora doesn't have that version available currently.
>
> There *was* a change since 25.1 (although supposedly that only
> affected python 3). Do you have "set colored-stats on" in your
> ~/.inputrc? There was a report in #24401 of that causing trouble.
I don't have a ~/.input file.
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 haven't looked deeper as to why "pyrepl"'s readline is able to
not display the *Warning* buffer while Python's standard default
readline displays the *Warning* buffer until it is dismissed.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Sun, 19 Feb 2017 20:01:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 25753 <at> debbugs.gnu.org (full text, mbox):
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 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Sun, 19 Feb 2017 21:33:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 25753 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Mon, 20 Feb 2017 01:30:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 25753 <at> debbugs.gnu.org (full text, mbox):
Live System User <nyc4bos <at> aol.com> writes:
> 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.
Can you test the python code from python-shell-completion-native-setup
outside of Emacs, e.g., save it to a file called 'native-completion.py'
and then run 'python -i native-completion.py' and then type an
underscore and hit <tab>.
With 2.7.13, I get
$ python2 -i native-completion.py
python.el: native completion setup loaded
>>> ___package__
__PYTHON_EL_native_completion_setup
__name__
__doc__
__import__
__debug__
0__dummy_completion__ 1__dummy_completion__
>>> _
With python 3.6.0 I get:
$ python -i native-completion.py
python.el: native completion setup loaded
>>> ___name__
__doc__
__package__
__loader__
__spec__
__annotations__
__cached__
__PYTHON_EL_native_completion_setup
__build_class__
__import__
__debug__
0__dummy_completion__ 1__dummy_completion__
>>> _
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Mon, 20 Feb 2017 22:35:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 25753 <at> debbugs.gnu.org (full text, mbox):
npostavs <at> users.sourceforge.net writes:
> Live System User <nyc4bos <at> aol.com> writes:
>> 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.
>
> Can you test the python code from python-shell-completion-native-setup
> outside of Emacs, e.g., save it to a file called 'native-completion.py'
> and then run 'python -i native-completion.py' and then type an
> underscore and hit <tab>.
>
> With 2.7.13, I get
>
> $ python2 -i native-completion.py
> python.el: native completion setup loaded
> >>> ___package__
> __PYTHON_EL_native_completion_setup
> __name__
> __doc__
> __import__
> __debug__
>
> 0__dummy_completion__ 1__dummy_completion__
> >>> _
I get the same:
$ ▸ python2 -i native-completion.py
python.el: native completion setup loaded
>>> ___package__
__PYTHON_EL_native_completion_setup
__name__
__doc__
__import__
__debug__
0__dummy_completion__ 1__dummy_completion__
>>> _
In Emacs I still get the (visable) *Warning* buffer with contents:
Warning (python): Your ‘python-shell-interpreter’ doesn’t seem to support readline, yet ‘python-shell-completion-native’ was t and "python" is not part of the ‘python-shell-completion-native-disabled-interpreters’ list. Native completions have been disabled locally.
>
> With python 3.6.0 I get:
>
> $ python -i native-completion.py
> python.el: native completion setup loaded
> >>> ___name__
> __doc__
> __package__
> __loader__
> __spec__
> __annotations__
> __cached__
> __PYTHON_EL_native_completion_setup
> __build_class__
> __import__
> __debug__
>
> 0__dummy_completion__ 1__dummy_completion__
> >>> _
With Python 3.5.2 I get something a little different:
liveuser <at> localhost:~$ ▸ python3 -i native-completion.py
python.el: native completion setup loaded
>>> ___loader__
__spec__
__cached__
__name__
__package__
__PYTHON_EL_native_completion_setup
__doc__
__build_class__
__import__
__debug__
0__dummy_completion__ 1__dummy_completion__
>>> _
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Tue, 21 Feb 2017 01:46:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 25753 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Live System User <nyc4bos <at> aol.com> writes:
> npostavs <at> users.sourceforge.net writes:
>
>> Can you test the python code from python-shell-completion-native-setup
>> outside of Emacs, e.g., save it to a file called 'native-completion.py'
>> and then run 'python -i native-completion.py' and then type an
>> underscore and hit <tab>.
>>
>
> I get the same:
>
> $ ▸ python2 -i native-completion.py
> python.el: native completion setup loaded
>>>> ___package__
> __PYTHON_EL_native_completion_setup
> __name__
> __doc__
> __import__
> __debug__
>
> 0__dummy_completion__ 1__dummy_completion__
>>>> _
Can you try load the attached file in Emacs? Does it show similar
output in the "*py native complete test*" buffer?
emacs -Q -l py-native-completion.el
[py-native-completion.el (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Tue, 21 Feb 2017 03:33:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 25753 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
npostavs <at> users.sourceforge.net writes:
[...]
>
> Can you try load the attached file in Emacs? Does it show similar
> output in the "*py native complete test*" buffer?
>
> emacs -Q -l py-native-completion.el
Attached are my results.
[py-native-completion.test (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Tue, 21 Feb 2017 13:35:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 25753 <at> debbugs.gnu.org (full text, mbox):
Live System User <nyc4bos <at> aol.com> writes:
> npostavs <at> users.sourceforge.net writes:
>
> [...]
>>
>> Can you try load the attached file in Emacs? Does it show similar
>> output in the "*py native complete test*" buffer?
>>
>> emacs -Q -l py-native-completion.el
>
> Attached are my results.
Hmm, that looks like it should be working. Wait, when you said
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.
You meant the code from that exact comment? That's a broken solution,
try this instead:
(with-eval-after-load 'python
(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 "_"))))
If it's still not working, please post the contents of buffer " *Python
completions redirect*" (note the leading space).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Tue, 21 Feb 2017 23:19:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 25753 <at> debbugs.gnu.org (full text, mbox):
npostavs <at> users.sourceforge.net writes:
> Live System User <nyc4bos <at> aol.com> writes:
>
>> npostavs <at> users.sourceforge.net writes:
>>
>> [...]
>>>
>>> Can you try load the attached file in Emacs? Does it show similar
>>> output in the "*py native complete test*" buffer?
>>>
>>> emacs -Q -l py-native-completion.el
>>
>> Attached are my results.
>
> Hmm, that looks like it should be working. Wait, when you said
>
> 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.
>
> You meant the code from that exact comment? That's a broken solution,
> try this instead:
>
> (with-eval-after-load 'python
> (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 "_"))))
Your version of the solution works for me.
Thanks for your effort!.
>
> If it's still not working, please post the contents of buffer " *Python
> completions redirect*" (note the leading space).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Wed, 22 Feb 2017 01:40:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 25753 <at> debbugs.gnu.org (full text, mbox):
npostavs <at> users.sourceforge.net writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: charles <at> aurox.ch (Charles A. Roelli)
>>> Date: Thu, 16 Feb 2017 17:07:48 +0100
>>>
>>> In emacs 25.2 (rc1) and 25.1, interaction with the Python shell does not
>>> seem to be working fully. Python version is '2.7.12 (v2.7.12:d33e0cf91556,
>>> Jun 26 2016, 12:10:39) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]', and
>>> this is on Snow Leopard.
>>
>> Please try the next RC (should be out in a few days), I think we fixed
>> that there.
>
> AFAIK, the only change since rc1 is to add "ipython" to
> python-shell-completion-native-disabled-interpreters. And that should
> not affect the problem reported here, which does not seem to involve
> ipython.
As I've said, I don't think rc2 would change this, but since it's come
out now, please test it. Assuming rc2 still has the problem, please try
the tests I posted in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25753#29 and
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25753#35. Also post the
contents of buffer " *Python completions redirect*" after doing M-x
run-python.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Wed, 22 Feb 2017 19:44:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 25753 <at> debbugs.gnu.org (full text, mbox):
> As I've said, I don't think rc2 would change this, but since it's come
> out now, please test it.
Tested, and it has the same problem. Here is what *Python* normally
looks like at the start, run from M-x run-python in emacs -Q:
Python 2.7.12 (v2.7.12:d33e0cf91556, Jun 26 2016, 12:10:39)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import codecs, os;__pyfile = codecs.open('''/var/folders/WP/WPe0Q1iAGc0J7iI6J50jcU+++TI/-Tmp-/py16611qgD''', encoding='''utf-8''');__code = __pyfile.read().encode('''utf-8''');__pyfile.close();os.remove('''/var/folders/WP/WPe0Q1iAGc0J7iI6J50jcU+++TI/-Tmp-/py16611qgD''');exec(compile(__code, '''/var/folders/WP/WPe0Q1iAGc0J7iI6J50jcU+++TI/-Tmp-/py16611qgD''', 'exec'));
python.el: native completion setup loaded
It seems like the line starting with ">>> " should not be printed, if
<nyc4bos <at> aol.com>'s test output is deemed to be running more or less
correctly. Maybe that can point us in the right direction?
> Can you test the python code from python-shell-completion-native-setup
> outside of Emacs, e.g., save it to a file called 'native-completion.py'
> and then run 'python -i native-completion.py' and then type an
> underscore and hit <tab>.
I get the following:
>>> ___package__
__PYTHON_EL_native_completion_setup
__name__
__doc__
__import__
__debug__
Interestingly, none of the dummy completions pop up.
> Can you try load the attached file in Emacs? Does it show similar
> output in the "*py native complete test*" buffer?
>
> emacs -Q -l py-native-completion.el
I get no completions with this -- here is all that shows up:
Python 2.7.12 (v2.7.12:d33e0cf91556, Jun 26 2016, 12:10:39)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> python.el: native completion setup loaded
>>>
> Also post the contents of buffer " *Python completions redirect*"
> after doing M-x run-python.
- emacs -Q
- M-x run-python
- C-x b " *Python completions redirect*"
It's this: "_ ^H^H" (space in the middle is a tab character).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Thu, 23 Feb 2017 14:19:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 25753 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
charles <at> aurox.ch (Charles A. Roelli) writes:
>
> Tested, and it has the same problem. Here is what *Python* normally
> looks like at the start, run from M-x run-python in emacs -Q:
>
> Python 2.7.12 (v2.7.12:d33e0cf91556, Jun 26 2016, 12:10:39)
> [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import codecs, os;__pyfile =
>>>> codecs.open('''/var/folders/WP/WPe0Q1iAGc0J7iI6J50jcU+++TI/-Tmp-/py16611qgD''',
>>>> encoding='''utf-8''');__code =
>>>> __pyfile.read().encode('''utf-8''');__pyfile.close();os.remove('''/var/folders/WP/WPe0Q1iAGc0J7iI6J50jcU+++TI/-Tmp-/py16611qgD''');exec(compile(__code,
>>>> '''/var/folders/WP/WPe0Q1iAGc0J7iI6J50jcU+++TI/-Tmp-/py16611qgD''',
>>>> 'exec'));
> python.el: native completion setup loaded
>
> It seems like the line starting with ">>> " should not be printed, if
> <nyc4bos <at> aol.com>'s test output is deemed to be running more or less
> correctly. Maybe that can point us in the right direction?
Hmm, it's odd, though since you're still getting the "setup loaded"
message, the code *is* getting evaluated anyway, so it's likely that
this problem is not directly related. Let's see if we can track it down
anyway, try the loading the attached as
emacs -Q -l py-trace-bad-output.el
and see if anything shows up in *Messages*.
[py-trace-bad-output.el (application/emacs-lisp, attachment)]
[Message part 3 (text/plain, inline)]
>> Can you test the python code from python-shell-completion-native-setup
>> outside of Emacs, e.g., save it to a file called 'native-completion.py'
>> and then run 'python -i native-completion.py' and then type an
>> underscore and hit <tab>.
>
> I get the following:
>
>>>> ___package__
> __PYTHON_EL_native_completion_setup
> __name__
> __doc__
> __import__
> __debug__
>
> Interestingly, none of the dummy completions pop up.
This seems to be the core of the problem. I gather that macOS uses
libedit instead of readline by default, perhaps that is the source of
incompatibility. Can you figure out how to change the python code so
that the dummy completions do show up?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Fri, 24 Feb 2017 10:21:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 25753 <at> debbugs.gnu.org (full text, mbox):
On Thu, Feb 23 2017 at 09:20:01 am, npostavs <at> users.sourceforge.net wrote:
> charles <at> aurox.ch (Charles A. Roelli) writes:
>>
>> Tested, and it has the same problem. Here is what *Python* normally
>> looks like at the start, run from M-x run-python in emacs -Q:
>>
>> Python 2.7.12 (v2.7.12:d33e0cf91556, Jun 26 2016, 12:10:39)
>> [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
>>>>> import codecs, os;__pyfile =
>>>>> codecs.open('''/var/folders/WP/WPe0Q1iAGc0J7iI6J50jcU+++TI/-Tmp-/py16611qgD''',
>>>>> encoding='''utf-8''');__code =
>>>>> __pyfile.read().encode('''utf-8''');__pyfile.close();os.remove('''/var/folders/WP/WPe0Q1iAGc0J7iI6J50jcU+++TI/-Tmp-/py16611qgD''');exec(compile(__code,
>>>>> '''/var/folders/WP/WPe0Q1iAGc0J7iI6J50jcU+++TI/-Tmp-/py16611qgD''',
>>>>> 'exec'));
>> python.el: native completion setup loaded
>>
>> It seems like the line starting with ">>> " should not be printed, if
>> <nyc4bos <at> aol.com>'s test output is deemed to be running more or less
>> correctly. Maybe that can point us in the right direction?
>
> Hmm, it's odd, though since you're still getting the "setup loaded"
> message, the code *is* getting evaluated anyway, so it's likely that
> this problem is not directly related. Let's see if we can track it down
> anyway, try the loading the attached as
>
> emacs -Q -l py-trace-bad-output.el
>
> and see if anything shows up in *Messages*.
>
> (require 'python)
>
> (advice-add
> 'python-shell-make-comint :filter-return
> (lambda (proc-buffer-name)
> (with-current-buffer proc-buffer-name
> (add-hook 'after-change-functions
> (lambda (beg end len)
> (ignore-errors
> (save-excursion
> (save-match-data
> (when (string-prefix-p "import codecs" (buffer-substring beg end))
> (backtrace))))))
> nil t))
> proc-buffer-name))
>
> (run-python)
>
> (switch-to-buffer "*Python*")
> (display-buffer "*Messages*")
>
Here is what I got:
Loading ~/Downloads/py-trace-bad-output.el (source)...done
backtrace()
(progn (backtrace))
(if (string-prefix-p "import codecs" (buffer-substring beg end)) (progn (backtrace)))
(progn (if (string-prefix-p "import codecs" (buffer-substring beg end)) (progn (backtrace))))
(unwind-protect (progn (if (string-prefix-p "import codecs" (buffer-substring beg end)) (progn (backtrace)))) (set-match-data save-match-data-internal (quote evaporate)))
(let ((save-match-data-internal (match-data))) (unwind-protect (progn (if (string-prefix-p "import codecs" (buffer-substring beg end)) (progn (backtrace)))) (set-match-data save-match-data-internal (quote evaporate))))
(save-excursion (let ((save-match-data-internal (match-data))) (unwind-protect (progn (if (string-prefix-p "import codecs" (buffer-substring beg end)) (progn (backtrace)))) (set-match-data save-match-data-internal (quote evaporate)))))
(progn (save-excursion (let ((save-match-data-internal (match-data))) (unwind-protect (progn (if (string-prefix-p "import codecs" (buffer-substring beg end)) (progn (backtrace)))) (set-match-data save-match-data-internal (quote evaporate))))))
(condition-case nil (progn (save-excursion (let ((save-match-data-internal (match-data))) (unwind-protect (progn (if (string-prefix-p "import codecs" ...) (progn ...))) (set-match-data save-match-data-internal (quote evaporate)))))) (error nil))
(lambda (beg end len) (condition-case nil (progn (save-excursion (let ((save-match-data-internal (match-data))) (unwind-protect (progn (if ... ...)) (set-match-data save-match-data-internal (quote evaporate)))))) (error nil)))(191 556 0)
comint-output-filter(#<process Python> "import codecs, os;__pyfile = codecs.open('''/var/folders/WP/WPe0Q1iAGc0J7iI6J50jcU+++TI/-Tmp-/py683UGH''', encoding='''utf-8''');__code = __pyfile.read().encode('''utf-8''');__pyfile.close();os.remove('''/var/folders/WP/WPe0Q1iAGc0J7iI6J50jcU+++TI/-Tmp-/py683UGH''');exec(compile(__code, '''/var/folders/WP/WPe0Q1iAGc0J7iI6J50jcU+++TI/-Tmp-/py683UGH''', 'exec'));
")
accept-process-output(#<process Python> 1.0)
python-shell-accept-process-output(#<process Python> 1.0)
python-shell-completion-native-setup()
python-shell-completion-native-turn-on-maybe(t)
python-shell-completion-native-turn-on-maybe-with-msg()
run-hooks(python-shell-first-prompt-hook)
python-shell-comint-watch-for-first-prompt-output-filter(">>> ")
run-hook-with-args(python-shell-comint-watch-for-first-prompt-output-filter ">>> ")
comint-output-filter(#<process Python> ">>> ")
read-event(nil t 2)
sit-for(2)
execute-extended-command(nil "load-file" "load-file")
funcall-interactively(execute-extended-command nil "load-file" "load-file")
call-interactively(execute-extended-command nil nil)
command-execute(execute-extended-command)
Shell native completion is disabled, using fallback
>>> Can you test the python code from python-shell-completion-native-setup
>>> outside of Emacs, e.g., save it to a file called 'native-completion.py'
>>> and then run 'python -i native-completion.py' and then type an
>>> underscore and hit <tab>.
>>
>> I get the following:
>>
>>>>> ___package__
>> __PYTHON_EL_native_completion_setup
>> __name__
>> __doc__
>> __import__
>> __debug__
>>
>> Interestingly, none of the dummy completions pop up.
>
> This seems to be the core of the problem. I gather that macOS uses
> libedit instead of readline by default, perhaps that is the source of
> incompatibility. Can you figure out how to change the python code so
> that the dummy completions do show up?
Yes, I will look into it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Sat, 25 Feb 2017 14:13:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 25753 <at> debbugs.gnu.org (full text, mbox):
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? Notice in the third example, the correct result
appears, but is preceded by the code sent to the interpreter (which
should be omitted as garbage).
(python-shell-send-string-no-output "import os\nimport sys")
=> "import codecs, os;__pyfile = codecs.open('''/var/folders/WP/WPe0Q1iAGc0J7iI6J50jcU+++TI/-Tmp-/py167Tvh''', encoding='''utf-8''');__code = __pyfile.read().encode('''utf-8''');__pyfile.close();os.remove('''/var/folders/WP/WPe0Q1iAGc0J7iI6J50jcU+++TI/-Tmp-/py167Tvh''');exec(compile(__code, '''/var/folders/WP/WPe0Q1iAGc0J7iI6J50jcU+++TI/-Tmp-/py167Tvh''', 'exec'));"
(python-shell-send-string-no-output "import os; import sys")
=> "import os; import sys"
(python-ffap-module-path "os")
=> "import codecs, os;__pyfile = codecs.open('''/var/folders/WP/WPe0Q1iAGc0J7iI6J50jcU+++TI/-Tmp-/py167tDu''', encoding='''utf-8''');__code = __pyfile.read().encode('''utf-8''');__pyfile.close();os.remove('''/var/folders/WP/WPe0Q1iAGc0J7iI6J50jcU+++TI/-Tmp-/py167tDu''');exec(compile(__code, '''/var/folders/WP/WPe0Q1iAGc0J7iI6J50jcU+++TI/-Tmp-/py167tDu''', 'exec'));^M
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.py"
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Sat, 25 Feb 2017 14:34:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 25753 <at> debbugs.gnu.org (full text, mbox):
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? Possibly setting
`comint-process-echoes' could help, though I don't understand why there
is echoing in the first place.
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"
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Sat, 25 Feb 2017 22:29:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 25753 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Mon, 27 Feb 2017 02:14:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 25753 <at> debbugs.gnu.org (full text, mbox):
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
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Tue, 28 Feb 2017 10:35:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 25753 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Tue, 28 Feb 2017 14:06:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 25753 <at> debbugs.gnu.org (full text, mbox):
charles <at> aurox.ch (Charles A. Roelli) writes:
> 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.
The equivalent for python.el would be approximately
(defun my-python-shell-calculate-command (&rest _)
"sh -c \"cat | python -i\"")
(advice-add 'python-shell-calculate-command :override
#'my-python-shell-calculate-command)
But this breaks native completion and prompt detection, due to IO
buffering I think.
>>> 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.
Does this look okay?
--- i/etc/PROBLEMS
+++ w/etc/PROBLEMS
@@ -463,8 +463,25 @@ problem by adding this to your .cshrc file:
unset edit
stty -icrnl -onlcr -echo susp ^Z
endif
+*** In Inferior Python mode, input is echoed and native completion doesn't work.
+<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25753>
+
+This happens when python uses a libedit based readline module, which
+is the default on macOS. This can be worked around by installing a
+GNU readline based module instead, for example, using setuptools
+
+ sudo easy_install gnureadline
+
+And then rename the system's readline so that it won't be loaded:
+
+ cd /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload
+ mv readline.so readline.so.bak
+
+See <https://pypi.python.org/pypi/gnureadline> for more details on
+installation.
+
*** Emacs startup on GNU/Linux systems (and possibly other systems) is slow.
This can happen if the system is misconfigured and Emacs can't get the
full qualified domain name, FQDN. You should have your FQDN in the
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Tue, 28 Feb 2017 15:58:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 25753 <at> debbugs.gnu.org (full text, mbox):
> From: npostavs <at> users.sourceforge.net
> Cc: 25753 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> Date: Tue, 28 Feb 2017 09:07:02 -0500
>
> Does this look okay?
>
> --- i/etc/PROBLEMS
> +++ w/etc/PROBLEMS
Yes, thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Wed, 01 Mar 2017 23:00:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 25753 <at> debbugs.gnu.org (full text, mbox):
retitle 25753 Python with libedit (macOS default) echoes input, breaks native completion
quit
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: npostavs <at> users.sourceforge.net
>> Cc: 25753 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
>> Date: Tue, 28 Feb 2017 09:07:02 -0500
>>
>> Does this look okay?
>>
>> --- i/etc/PROBLEMS
>> +++ w/etc/PROBLEMS
>
> Yes, thanks.
Pushed to emacs-25 [1: 6e788ef0e2].
1: 2017-03-01 17:56:20 -0500 6e788ef0e262fafc014c21f4ad52cc5dc9f1715b
; etc/PROBLEMS: Explain about the python+libedit problem (Bug#25753).
Changed bug title to 'Python with libedit (macOS default) echoes input, breaks native completion' from '25.2; Python mode shell interaction not working 100%'
Request was from
npostavs <at> users.sourceforge.net
to
control <at> debbugs.gnu.org.
(Wed, 01 Mar 2017 23:00:03 GMT)
Full text and
rfc822 format available.
Merged 25753 26326.
Request was from
Noam Postavsky <npostavs <at> users.sourceforge.net>
to
control <at> debbugs.gnu.org.
(Fri, 31 Mar 2017 19:55:03 GMT)
Full text and
rfc822 format available.
Disconnected #32042 from all other report(s).
Request was from
Noam Postavsky <npostavs <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Wed, 11 Jul 2018 00:33:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Sun, 03 Oct 2021 16:04:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 25753 <at> debbugs.gnu.org (full text, mbox):
I’m having this issue with emacs 28 in macOS Big Sur, my python interpreter was installed using brew and has readline support:
```
Python 3.9.7 (default, Sep 3 2021, 12:37:55)
[Clang 12.0.5 (clang-1205.0.22.9)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline; print (readline.__doc__)
Importing this module enables command line editing using GNU readline.
```
But:
```
Warning (python): Your ‘python-shell-interpreter’ doesn’t seem to support readline, yet ‘python-shell-completion-native-enable’ was t and "python3" is not part of the ‘python-shell-completion-native-disabled-interpreters’ list. Native completions have been disabled locally. Disable showing Disable logging
```
Is this expected? The thread above seems to suggest that it should work, but maybe I’m misreading it.
Thanks
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Sun, 03 Oct 2021 16:32:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 25753 <at> debbugs.gnu.org (full text, mbox):
BTW, one nasty consequence of this is that it completely freezes emacs
when trying to execute an org-babel python block.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Sun, 03 Oct 2021 23:36:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 25753 <at> debbugs.gnu.org (full text, mbox):
Ok, after a lot of debugging I realized that my current readline
configuration was introducing some control characters that wreak havoc
with the native completion detection mechanism. Now, my .inputrc has:
> cat .inputrc
set completion-ignore-case on
set completion-display-width 80
set completion-prefix-display-length 5
set show-all-if-ambiguous on
set skip-completed-text on
set colored-stats on
set blink-matching-paren on
set menu-complete-display-prefix on
And I like it to be so. So there are a lot of cases to deal with here.
One could force a reset by setting INPUTRC=ieiowueqoiw or whatever,
but I've spent countless hours debugging all this native completion
stuff every couple of years, it's too fragile and too complex, do you
think it's worth the effort? ipython doesn't use readline anymore, the
trend is to move to jupyter which has a clean protocol to deal with
all this, why don't keep things simple and get rid of the readline
magic for good? Just an opinion.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Sun, 03 Oct 2021 23:57:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 25753 <at> debbugs.gnu.org (full text, mbox):
Some years ago I proposed starting a thread python-side that provided
the completions through some kind of IPC, so as to not interfere with
prompt numbering and also to avoid blocking behavior (for example, if
eldoc tries to show documentation while python is running, it will
block or at least it would at the time). I started an implementation
then, sent a prototype to Fabian but it didn't get traction. I
reiterate my proposition now, even though I believe that's what
jupyter does nowadays in a much better way than any tiny
implementation of mine hacked into defcustoms will ever do.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Mon, 04 Oct 2021 00:47:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 25753 <at> debbugs.gnu.org (full text, mbox):
Regarding my issue, short of resetting the entire inputrc config
somehow, one can workaround the problem by changing:
(comint-redirect-finished-regexp
"1__dummy_completion__[[:space:]]*\n")
to:
(comint-redirect-finished-regexp
"1__dummy_completion__.*\n")
This is in order to match outputs like:
0__dummy_completion__ [0m [K 1__dummy_completion__ [0m [K
Given the fragility of all this, I think it's better not to be too
picky regarding the matching condition, which is selective enough
without enforcing spaces at the end. So I propose that minimal change.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Mon, 04 Oct 2021 08:23:01 GMT)
Full text and
rfc822 format available.
Message #110 received at 25753 <at> debbugs.gnu.org (full text, mbox):
On Sun, 3 Oct 2021 at 20:55, Carlos Pita <carlosjosepita <at> gmail.com> wrote:
> Some years ago I proposed starting a thread python-side that provided
> the completions through some kind of IPC, so as to not interfere with
> prompt numbering and also to avoid blocking behavior (for example, if
> eldoc tries to show documentation while python is running, it will
> block or at least it would at the time). I started an implementation
> then, sent a prototype to Fabian but it didn't get traction. I
> reiterate my proposition now, even though I believe that's what
> jupyter does nowadays in a much better way than any tiny
> implementation of mine hacked into defcustoms will ever do.
There exists an Emacs interface to Jupyter:
https://github.com/nnicandro/emacs-jupyter
Unfortunately, this package is free of bugs and hasn't seen much
development lately, so I prefer to live with the issues of the good old
Python shell.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Mon, 04 Oct 2021 15:07:01 GMT)
Full text and
rfc822 format available.
Message #113 received at 25753 <at> debbugs.gnu.org (full text, mbox):
I filed a new issue for the configuration problem:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=51010
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Mon, 04 Oct 2021 15:33:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 25753 <at> debbugs.gnu.org (full text, mbox):
Hi Augusto,
> Unfortunately, this package is free of bugs and hasn't seen much
> development lately, so I prefer to live with the issues of the good old
> Python shell.
Just to be clear, I'm not saying python.el should move to jupyter or
anything like that. On the contrary, I believe it should provide a
solid focused basis for other modules (elpy, lsp, emacs-jupyter, etc)
and perhaps it's already somewhat at odds with that goal. Especially
regarding native completion I don't see much to be gained vs. directly
calling the readline completer (which is now considered the fallback
case) and OTOH there is something to be lost: at least in my
experience this has often been the non "just works" factor. Moreover,
the mechanism is far from perfect (it interferes with prompt
numbering, it's potentially blocking) and native completions solve
none of its issues. So I feel like getting rid of it. My point
regarding Jupyter, LSP and the emacs frameworks around them is that to
some extent they relieve python.el of having to be that smart.
Best regards,
Carlos
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Mon, 04 Oct 2021 15:49:01 GMT)
Full text and
rfc822 format available.
Message #119 received at 25753 <at> debbugs.gnu.org (full text, mbox):
On Mon, 4 Oct 2021 at 12:31, Carlos Pita <carlosjosepita <at> gmail.com> wrote:
> Hi Augusto,
>
>> Unfortunately, this package is free of bugs and hasn't seen much
>> development lately, so I prefer to live with the issues of the good old
>> Python shell.
I meant emacs-jupyter _isn't_ free of bugs, in case that wasn't clear
from context :-).
> Just to be clear, I'm not saying python.el should move to jupyter or
> anything like that. On the contrary, I believe it should provide a
> solid focused basis for other modules (elpy, lsp, emacs-jupyter, etc)
> and perhaps it's already somewhat at odds with that goal.
I personally agree.
> Especially regarding native completion I don't see much to be gained
> vs. directly calling the readline completer (which is now considered
> the fallback case) and OTOH there is something to be lost: at least in
> my experience this has often been the non "just works"
> factor. Moreover, the mechanism is far from perfect (it interferes
> with prompt numbering, it's potentially blocking) and native
> completions solve none of its issues. So I feel like getting rid of
> it. My point regarding Jupyter, LSP and the emacs frameworks around
> them is that to some extent they relieve python.el of having to be
> that smart.
That's not an unreasonable proposal. I'd be curious as to what the
maintainers think. For the record, here are the only 2 advantages of
the "native completion" mechanism that I'm aware of:
1. It does _not_ interfere with prompt numbering and last return value
variables `_`.
2. It works on continuation lines.
The following facts further diminish those two advantages:
A. Every other feature that sends commands to the inferior behind the
scenes will interfere with prompt numbering.
B. Editing continuation lines is awkward for several other reasons. For
instance, each continuation line becomes a separate history entry.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Fri, 11 Aug 2023 17:57:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 25753 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
* Synopsis
With 29.1 on OSX and GNU/Linux(Ubuntu), opening a python session in a
buffer for the
second time in a buffer causes Emacs to hang. (First mentioned in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25753#98).
The warning message from
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25753#5
appears on OSX, but not on Ubuntu. As mentioned in that email, despite
the
warning, completions *do* work.
The major problem to my workflow is the hanging. Versions 27 and 28 did
not
have this problem.
* Solutions attempted that do not solve the issue for me
1. `pip install gnureadline`
2. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25753#41
3. ~/.inputrc: I don't use that on OSX, on Ubuntu, my config is minimal.
* Recipe, system info and .initrc are in the attached org-mode file.
[Message part 2 (text/html, inline)]
[emacs_bug_25753.org (application/vnd.lotus-organizer, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25753; Package
emacs.
(Fri, 25 Aug 2023 05:33:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 25753 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
At least my version of the problem can be traced to a bug in Org's
ob-python.el. I bisected the commit history, found the offending commit
and reported it to the org mailing list.
Peter
On Fri, Aug 11, 2023 at 10:55 AM Peter Mao <peter.mao <at> gmail.com> wrote:
> * Synopsis
> With 29.1 on OSX and GNU/Linux(Ubuntu), opening a python session in a
> buffer for the
> second time in a buffer causes Emacs to hang. (First mentioned in
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25753#98).
>
> The warning message from
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25753#5
> appears on OSX, but not on Ubuntu. As mentioned in that email, despite
> the
> warning, completions *do* work.
>
> The major problem to my workflow is the hanging. Versions 27 and 28 did
> not
> have this problem.
>
> * Solutions attempted that do not solve the issue for me
> 1. `pip install gnureadline`
> 2. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25753#41
> 3. ~/.inputrc: I don't use that on OSX, on Ubuntu, my config is minimal.
>
> * Recipe, system info and .initrc are in the attached org-mode file.
>
[Message part 2 (text/html, inline)]
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Fri, 25 Aug 2023 06:32:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
charles <at> aurox.ch (Charles A. Roelli):
bug acknowledged by developer.
(Fri, 25 Aug 2023 06:32:01 GMT)
Full text and
rfc822 format available.
Message #130 received at 25753-done <at> debbugs.gnu.org (full text, mbox):
> From: Peter Mao <peter.mao <at> gmail.com>
> Date: Thu, 24 Aug 2023 22:32:20 -0700
>
> At least my version of the problem can be traced to a bug in Org's ob-python.el. I bisected the
> commit history, found the offending commit and reported it to the org mailing list.
Thanks, I'm therefore closing this bug. Feel free to reopen if
something needs to be done on the Emacs core side.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Fri, 25 Aug 2023 06:32:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Johnny Zhao <dz357488639 <at> gmail.com>:
bug acknowledged by developer.
(Fri, 25 Aug 2023 06:32:02 GMT)
Full text and
rfc822 format available.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Fri, 25 Aug 2023 06:32:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Amir Dib <dib.amir <at> gmail.com>:
bug acknowledged by developer.
(Fri, 25 Aug 2023 06:32:02 GMT)
Full text and
rfc822 format available.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Fri, 25 Aug 2023 06:32:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Monib Ahmed <MonibAhmed <at> gmail.com>:
bug acknowledged by developer.
(Fri, 25 Aug 2023 06:32:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 22 Sep 2023 11:24:09 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 232 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.