bug#68559: [PATCH] Improve Python shell completion

[Mattias Engdegård]

22 feb. 2024 kl. 17.15 skrev kobarity <kobarity@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.