GNU bug report logs - #68559
[PATCH] Improve Python shell completion

Previous Next

Full log

View this message in rfc822 format

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: kobarity <kobarity <at> gmail.com>
Cc: Liu Hui <liuhui1610 <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>, 68559 <at> debbugs.gnu.org
Subject: bug#68559: [PATCH] Improve Python shell completion
Date: Wed, 21 Feb 2024 19:20:08 +0100

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

21 feb. 2024 kl. 14.13 skrev kobarity <kobarity <at> gmail.com>:

> As far as I have tried, native completions cannot be enabled for
> libedit-based readline package, even on Linux.

Did you find out why? Python responds nicely to TAB if run from a terminal, so what is it that we do in Emacs that prevents it from doing so? A TTY setting, or an environment variable (the TERM=dumb)?

> So, there are two ways for Mac users to avoid the warning.  One is to
> use gnureadline instead of libedit, and the other is to give up native
> completions and set `python-shell-completion-native-enable' to nil.

Preferably neither. Emacs should adapt to the system environment, and in particular not warn about the default environment. A warning is an indication of a possible risk or other problem, and there is none here.

At most, python-mode could show a calm notice on the echo line but even that is a stretch. What do you think about this rough patch?

[nowarn.diff (application/octet-stream, attachment)]

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

> I think the protocol between python.el and inferior Python process is
> already platform independent.  Protocol violations are echo back.

No, I meant a protocol that allows Emacs to act as a first-class Python front-end, not simulate a terminal, send keystrokes, use heuristics to determine what in the output stream is a prompt, REPL value, error, completion etc.

For example, it's a bit silly to input multi-line code in the REPL as a sequence of individual single-line commands, when we actually are inside a text editor that can edit multi-line Python code without a problem.

(I'm not suggesting that you or anybody in particular should do this; just that it's feasible. It would clearly be quite some work!)

>> Thanks for your patches. I suggest we apply your set-tty-raw patch on master now since it cures the test failures without breaking anything else (on Mac; I'm assuming no regression elsewhere).
>> 
>> Would you like me to do that for you?
> 
> Yes, please.

Done!

Previous Next

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