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: Wed, 21 Feb 2024 19:20:08 +0100 [thread overview]
Message-ID: <16E39FDF-5F8E-4C1B-8BCD-A0147B97F2B8@gmail.com> (raw)
In-Reply-To: <eke74je2x8mu.wl-kobarity@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 958 bytes --]
21 feb. 2024 kl. 14.13 skrev kobarity <kobarity@gmail.com>:
> As far as I have tried, native completions cannot be enabled for
> libedit-based readline package, even on Linux.
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)?
> So, there are two ways for Mac users to avoid the warning. One is to
> use gnureadline instead of libedit, and the other is to give up native
> completions and set `python-shell-completion-native-enable' to nil.
Preferably neither. Emacs should adapt to the system environment, and in particular not warn about the default environment. A warning is an indication of a possible risk or other problem, and there is none here.
At most, python-mode could show a calm notice on the echo line but even that is a stretch. What do you think about this rough patch?
[-- Attachment #2: nowarn.diff --]
[-- Type: application/octet-stream, Size: 1402 bytes --]
diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
index 5501926e69d..bedc61408ef 100644
--- a/lisp/progmodes/python.el
+++ b/lisp/progmodes/python.el
@@ -4536,18 +4536,11 @@ python-shell-completion-native-turn-on-maybe
((python-shell-completion-native-setup)
(when msg
(message "Shell native completion is enabled.")))
- (t (lwarn
- '(python python-shell-completion-native-turn-on-maybe)
- :warning
- (concat
- "Your `python-shell-interpreter' doesn't seem to "
- "support readline, yet `python-shell-completion-native-enable' "
- (format "was t and %S is not part of the "
- (file-name-nondirectory python-shell-interpreter))
- "`python-shell-completion-native-disabled-interpreters' "
- "list. Native completions have been disabled locally. "
- "Consider installing the python package \"readline\". "))
- (python-shell-completion-native-turn-off msg))))))
+ (t
+ (when msg
+ (message (concat "Python does not use GNU readline;"
+ " no completion in multi-line commands.")))
+ (python-shell-completion-native-turn-off nil))))))
(defun python-shell-completion-native-turn-on-maybe-with-msg ()
"Like `python-shell-completion-native-turn-on-maybe' but force messages."
[-- Attachment #3: Type: text/plain, Size: 1007 bytes --]
> I think the protocol between python.el and inferior Python process is
> already platform independent. Protocol violations are echo back.
No, I meant a protocol that allows Emacs to act as a first-class Python front-end, not simulate a terminal, send keystrokes, use heuristics to determine what in the output stream is a prompt, REPL value, error, completion etc.
For example, it's a bit silly to input multi-line code in the REPL as a sequence of individual single-line commands, when we actually are inside a text editor that can edit multi-line Python code without a problem.
(I'm not suggesting that you or anybody in particular should do this; just that it's feasible. It would clearly be quite some work!)
>> Thanks for your patches. I suggest we apply your set-tty-raw patch on master now since it cures the test failures without breaking anything else (on Mac; I'm assuming no regression elsewhere).
>>
>> Would you like me to do that for you?
>
> Yes, please.
Done!
next prev parent reply other threads:[~2024-02-21 18:20 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 [this message]
2024-02-22 16:15 ` kobarity
2024-02-23 11:00 ` Mattias Engdegård
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=16E39FDF-5F8E-4C1B-8BCD-A0147B97F2B8@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).