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: Fri, 23 Feb 2024 12:00:27 +0100

22 feb. 2024 kl. 17.15 skrev kobarity <kobarity <at> gmail.com>:

>> 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)?
> 
> No, not exactly, but I don't think it is related to terminal settings.

Well it must be something. I'll see if I can make sense of it.

> I think this difference in behavior is the reason why Native
> completions does not work with libedit.

Thanks for explaining.

> Personally, I think this patch would be fine.

Thank you, now pushed to master.

> I think we can also improve Non-native completions.  Current
> implementation sends the definition of __PYTHON_EL_get_completions()
> every time.  However, sending it once during initialization should be
> sufficient.  Worse, if the number of characters sent exceeds
> `comint-max-line-length', it will be sent via file.  This is happening
> in your environment.  Here is the log you presented.
> 
> Test python-completion-at-point-1 backtrace:
>  json-parse-string("__PYTHON_EL_eval_file(\"/var/folders/qy/zstv16390
> 
> Thanks to the echo back, we can see __PYTHON_EL_eval_file() was used.

Right. (The need for a file is just an artefact of Comint limitations, isn't it?)

> I am not opposed to this approach, but as you wrote, it is very
> different from the current inferior Python implementation.
> Jupyter-emacs's approach may be similar to some extent.  It uses zmq
> as the communication channel.

Thank you, yes, in a sense it's a (small) step towards a more notebook-like interaction model, but Comint already has some of that. This problem is not unique to Python: other REPLs have to solve the problem of multi-line input as well, and it would serve the user if they all worked in the same way (as far as the language differences allow).

In Python's case, it would liberate us from the constraints of the standard terminal REPL.

Previous Next

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