From: "Mattias Engdegård" <mattias.engdegard@gmail.com>
To: kobarity <kobarity@gmail.com>
Cc: Liu Hui <liuhui1610@gmail.com>, Eli Zaretskii <eliz@gnu.org>,
68559@debbugs.gnu.org
Subject: bug#68559: [PATCH] Improve Python shell completion
Date: Fri, 23 Feb 2024 12:00:27 +0100 [thread overview]
Message-ID: <7150E568-B07D-4D92-8073-979387553394@gmail.com> (raw)
In-Reply-To: <eke7edd4v5j5.wl-kobarity@gmail.com>
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.
next prev parent reply other threads:[~2024-02-23 11:00 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-18 4:48 bug#68559: [PATCH] Improve Python shell completion Liu Hui
2024-01-18 6:39 ` Eli Zaretskii
2024-01-21 9:34 ` kobarity
2024-01-23 11:31 ` Liu Hui
2024-01-23 14:15 ` kobarity
2024-01-24 10:07 ` Liu Hui
2024-01-25 15:38 ` kobarity
2024-01-26 10:12 ` Liu Hui
2024-01-28 13:22 ` kobarity
2024-01-29 13:15 ` kobarity
2024-02-01 9:52 ` Eli Zaretskii
2024-02-01 14:39 ` kobarity
2024-02-01 15:02 ` Liu Hui
2024-02-04 12:09 ` Liu Hui
2024-02-04 14:35 ` kobarity
2024-02-05 15:03 ` Liu Hui
2024-02-06 1:25 ` Liu Hui
2024-02-06 15:12 ` kobarity
2024-02-07 13:22 ` Liu Hui
2024-02-07 15:19 ` kobarity
2024-02-08 12:13 ` Eli Zaretskii
2024-02-08 13:33 ` Liu Hui
2024-02-08 13:46 ` Eli Zaretskii
2024-02-08 14:16 ` Liu Hui
2024-02-08 16:43 ` Eli Zaretskii
2024-02-15 14:43 ` Mattias Engdegård
2024-02-15 16:37 ` Eli Zaretskii
2024-02-15 16:48 ` Eli Zaretskii
2024-02-15 17:21 ` Mattias Engdegård
2024-02-19 13:18 ` Basil L. Contovounesios
2024-02-20 4:46 ` Liu Hui
2024-02-20 13:15 ` Basil L. Contovounesios
2024-02-21 10:00 ` Liu Hui
2024-02-21 14:55 ` Basil L. Contovounesios
2024-02-22 10:31 ` Liu Hui
2024-02-22 13:56 ` Basil L. Contovounesios
2024-02-23 13:07 ` Liu Hui
2024-02-28 14:47 ` Basil L. Contovounesios
2024-02-16 4:06 ` Liu Hui
2024-02-16 7:41 ` Eli Zaretskii
2024-02-16 12:51 ` Eli Zaretskii
2024-02-16 3:24 ` Liu Hui
2024-02-16 9:34 ` kobarity
2024-02-16 11:45 ` Mattias Engdegård
2024-02-16 15:24 ` kobarity
2024-02-16 15:52 ` Eli Zaretskii
2024-02-16 20:10 ` Mattias Engdegård
2024-02-17 13:33 ` kobarity
2024-02-20 10:16 ` Mattias Engdegård
2024-02-21 13:13 ` kobarity
2024-02-21 18:20 ` Mattias Engdegård
2024-02-22 16:15 ` kobarity
2024-02-23 11:00 ` Mattias Engdegård [this message]
2024-02-23 14:39 ` kobarity
2024-02-26 11:06 ` Liu Hui
2024-02-26 12:16 ` Mattias Engdegård
2024-02-26 15:08 ` kobarity
2024-02-28 14:49 ` Basil L. Contovounesios
2024-03-06 10:14 ` Liu Hui
2024-03-08 15:44 ` Basil L. Contovounesios
2024-03-11 11:35 ` Liu Hui
2024-03-11 16:02 ` Basil L. Contovounesios
2024-03-13 10:21 ` Liu Hui
2024-03-14 14:24 ` Basil L. Contovounesios
2024-03-16 6:49 ` Liu Hui
2024-03-16 8:27 ` Eli Zaretskii
2024-02-17 4:36 ` Liu Hui
2024-02-17 13:20 ` Mattias Engdegård
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7150E568-B07D-4D92-8073-979387553394@gmail.com \
--to=mattias.engdegard@gmail.com \
--cc=68559@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=kobarity@gmail.com \
--cc=liuhui1610@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.