bug#25753: 25.2; Python mode shell interaction not working 100%

[Augusto Stoffel <arstoffel@gmail.com>]

On Mon,  4 Oct 2021 at 12:31, Carlos Pita <carlosjosepita@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.