GNU bug report logs - #25753
Python with libedit (macOS default) echoes input, breaks native completion

Previous Next

Package: emacs;

Reported by: charles <at> aurox.ch (Charles A. Roelli)

Date: Thu, 16 Feb 2017 16:09:02 UTC

Severity: normal

Merged with 21431, 22796, 26326

Found in versions 24.5, 25.1, 25.2, 26.1

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #119 received at 25753 <at> debbugs.gnu.org (full text, mbox):

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Carlos Pita <carlosjosepita <at> gmail.com>
Cc: 25753 <at> debbugs.gnu.org
Subject: Re: bug#25753: 25.2; Python mode shell interaction not working 100%
Date: Mon, 04 Oct 2021 17:47:50 +0200
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.




This bug report was last modified 1 year and 270 days ago.

Previous Next


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