[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#68559: [PATCH] Improve Python shell completion
From: |
Mattias Engdegård |
Subject: |
bug#68559: [PATCH] Improve Python shell completion |
Date: |
Wed, 21 Feb 2024 19:20:08 +0100 |
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?
nowarn.diff
Description: Binary data
> 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!
- bug#68559: [PATCH] Improve Python shell completion, (continued)
- bug#68559: [PATCH] Improve Python shell completion, Liu Hui, 2024/02/15
- bug#68559: [PATCH] Improve Python shell completion, kobarity, 2024/02/16
- bug#68559: [PATCH] Improve Python shell completion, Mattias Engdegård, 2024/02/16
- bug#68559: [PATCH] Improve Python shell completion, kobarity, 2024/02/16
- bug#68559: [PATCH] Improve Python shell completion, Eli Zaretskii, 2024/02/16
- bug#68559: [PATCH] Improve Python shell completion, Mattias Engdegård, 2024/02/16
- bug#68559: [PATCH] Improve Python shell completion, kobarity, 2024/02/17
- bug#68559: [PATCH] Improve Python shell completion, Mattias Engdegård, 2024/02/20
- bug#68559: [PATCH] Improve Python shell completion, kobarity, 2024/02/21
- bug#68559: [PATCH] Improve Python shell completion,
Mattias Engdegård <=
- bug#68559: [PATCH] Improve Python shell completion, kobarity, 2024/02/22
- bug#68559: [PATCH] Improve Python shell completion, Mattias Engdegård, 2024/02/23
- bug#68559: [PATCH] Improve Python shell completion, kobarity, 2024/02/23
- bug#68559: [PATCH] Improve Python shell completion, Liu Hui, 2024/02/26
- bug#68559: [PATCH] Improve Python shell completion, Mattias Engdegård, 2024/02/26
- bug#68559: [PATCH] Improve Python shell completion, kobarity, 2024/02/26
- bug#68559: [PATCH] Improve Python shell completion, Basil L. Contovounesios, 2024/02/28
- bug#68559: [PATCH] Improve Python shell completion, Liu Hui, 2024/02/16
- bug#68559: [PATCH] Improve Python shell completion, Mattias Engdegård, 2024/02/17