From: kobarity <kobarity@gmail.com>
To: Liu Hui <liuhui1610@gmail.com>
Cc: "Mattias Engdegård" <mattias.engdegard@gmail.com>,
"Eli Zaretskii" <eliz@gnu.org>,
68559@debbugs.gnu.org
Subject: bug#68559: [PATCH] Improve Python shell completion
Date: Sat, 17 Feb 2024 22:33:56 +0900 [thread overview]
Message-ID: <eke7ttm75i63.wl-kobarity@gmail.com> (raw)
In-Reply-To: <CAOQTW-NhMHdUCJ+EqL44xQq-J+OT6L6ZqtiH+uVS3TFVHdXcwA@mail.gmail.com> <86jzn4v23f.fsf@gnu.org> <FF0B2A46-9E9D-418A-8524-A33C08338542@gmail.com>
Eli Zaretskii wrote:
> > 0001-Remove-echoed-back-string-in-python-shell-completion.patch
> > extracts only the last line to exclude echoed back strings.
> >
> > 0001-Set-tty-mode-to-raw-when-setting-up-Inferior-Python.patch sets
> > the Inferior Python tty to raw mode. python-ffap-module-path-1 will
> > no longer need to be skipped on Mac. If it is safe to set tty to raw
> > mode on all UNIX based systems, I prefer this method.
>
> Will this work on MS-Windows as well? If you are unsure, would you
> please tell me how to test whether this works on Windows, so I could
> collect the information for you?
It does not affect MS-Windows because it sets only when the tty
library can be imported. Although the tty library exists in
MS-Windows, importing the tty library will result in an error because
there is no underlying termios library.
Mattias Engdegård wrote:
>
> 16 feb. 2024 kl. 16.24 skrev kobarity <kobarity@gmail.com>:
>
> > I made prototype patches for each method. I don't use Mac so it would
> > be helpful if you could try these.
>
> Nice, thank you! I can confirm that they both appear to work, at least in the sense that the python-tests pass (except for the ones skipped intentionally), and the python shell behaves reasonable.
>
> Only the set-tty-mode patch eliminates echo in the interactive python shell; in that sense it's preferable.
Thank you for testing my patches.
> Both produce the very annoying warning
>
> Warning (python): Your ‘python-shell-interpreter’ doesn’t seem to support readline, yet ‘python-shell-completion-native-enable’ was t and "python3" is not part of the ‘python-shell-completion-native-disabled-interpreters’ list. Native completions have been disabled locally. Consider installing the python package "readline".
>
> which is not even correct since the standard Python does have a working readline module, even if it uses libedit.
You are right. Maybe the package name should be fixed to "gnureadline"
as described in etc/PROBLEMS.
On Mac, it might be better to set the default value of
`python-shell-completion-native-enable' to nil.
> > 0001-Set-tty-mode-to-raw-when-setting-up-Inferior-Python.patch sets
> > the Inferior Python tty to raw mode. python-ffap-module-path-1 will
> > no longer need to be skipped on Mac.
>
> Right, that test runs and passes.
>
> > If it is safe to set tty to raw
> > mode on all UNIX based systems, I prefer this method.
>
> Same here. I see no reason why it wouldn't be safe, either.
Thanks.
> > By the way, is it necessary to send
> > `python-shell-completion-setup-code' for every completion in
> > `python-shell-completion-get-completions'? To me it seems sufficient
> > to send it once at initialization.
>
> Indeed, it does seem a bit extravagant.
This would be one of the items for future improvement.
Liu Hui wrote:
>
> kobarity <kobarity@gmail.com> writes:
>
> > 0001-Set-tty-mode-to-raw-when-setting-up-Inferior-Python.patch sets
> > the Inferior Python tty to raw mode. python-ffap-module-path-1 will
> > no longer need to be skipped on Mac. If it is safe to set tty to raw
> > mode on all UNIX based systems, I prefer this method.
>
> How about the following change, which only affects libedit-based
> readline? It may enable native completion on mac, but I cannot test
> it.
>
> diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
> index b7e43f3fc68..f59bc19367b 100644
> --- a/lisp/progmodes/python.el
> +++ b/lisp/progmodes/python.el
> @@ -4286,6 +4286,9 @@ (defcustom python-shell-completion-setup-code
> except:
> pass
> else:
> + if readline.__doc__ and 'libedit' in readline.__doc__:
> + import tty
> + tty.setraw(0)
> # Try to reuse current completer.
> completer = readline.get_completer()
> if not completer:
> @@ -4471,8 +4474,8 @@ (defun python-shell-completion-native-setup ()
> instance.rlcomplete = new_completer
>
> if readline.__doc__ and 'libedit' in readline.__doc__:
> - raise Exception('''libedit based readline is known not to work,
> - see etc/PROBLEMS under \"In Inferior Python mode, input is echoed\".''')
> + import tty
> + tty.setraw(0)
> readline.parse_and_bind('bind ^I rl_complete')
> else:
> readline.parse_and_bind('tab: complete')
Disabling echo back may not be sufficient to enable native completions
on Mac. I have not tried raw mode, but have tried
readline.parse_and_bind('setty -echo') and
readline.parse_and_bind('edit on'). Native completions could be
enabled, but it was unstable.
I have no objection if Mac users check the above patch and if it is
OK.
next prev parent reply other threads:[~2024-02-17 13:33 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 [this message]
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
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=eke7ttm75i63.wl-kobarity@gmail.com \
--to=kobarity@gmail.com \
--cc=68559@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=liuhui1610@gmail.com \
--cc=mattias.engdegard@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).