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





  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).