unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.






  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

  List information: https://www.gnu.org/software/emacs/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).