GNU bug report logs - #71440
Python Inferior Mode Can’t Recognize My Prompt

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 71440 in the body.
You can then email your comments to 71440 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "shynur ." <one.last.kiss <at> outlook.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: Python Inferior Mode Can’t Recognize My Prompt
Date: Sat, 8 Jun 2024 16:29:40 +0000

I set the ‘PYTHONSTARTUP’ environment variable to a file
whose content is

```python
import sys
sys.ps1, sys.ps2 = "\033[32m►\033[0m", "\033[32m▻\033[0m"
```

It works well if I start Python3 in my terminal (Windows
Terminal, windows11’s built-in app).

However, if I use it in Emacs:

1. open a Python file in Emacs
2. type ‘C-c C-p’ (run-python)
3. in the buffer visiting the Python file, type ‘C-c C-c’
   (python-shell-send-buffer)

Python will throw an error:

```
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name '__PYTHON_EL_eval' is not defined
```

Message #8 received at 71440 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "shynur ." <one.last.kiss <at> outlook.com>
Cc: 71440 <at> debbugs.gnu.org
Subject: Re: bug#71440: Python Inferior Mode Can’t
 Recognize My Prompt
Date: Sat, 08 Jun 2024 19:53:36 +0300

> From: "shynur ." <one.last.kiss <at> outlook.com>
> Date: Sat, 8 Jun 2024 16:29:40 +0000
> msip_labels: 
> 
> I set the ‘PYTHONSTARTUP’ environment variable to a file
> whose content is
> 
> ```python
> import sys
> sys.ps1, sys.ps2 = "\033[32m►\033[0m", "\033[32m▻\033[0m"
> ```
> 
> It works well if I start Python3 in my terminal (Windows
> Terminal, windows11’s built-in app).
> 
> However, if I use it in Emacs:
> 
> 1. open a Python file in Emacs
> 2. type ‘C-c C-p’ (run-python)
> 3. in the buffer visiting the Python file, type ‘C-c C-c’
>    (python-shell-send-buffer)
> 
> Python will throw an error:
> 
> ```
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> NameError: name '__PYTHON_EL_eval' is not defined

I'm guessing that this is because that #x25ba and #x25bb Unicode
characters don't survive your system codepage (which Emacs uses to
communicate with inferior Python).  What are the values of
w32-ansi-code-page and w32-multibyte-code-page on your system?

Message #11 received at 71440 <at> debbugs.gnu.org (full text, mbox):

From: "shynur ." <one.last.kiss <at> outlook.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "71440 <at> debbugs.gnu.org" <71440 <at> debbugs.gnu.org>
Subject: Re: bug#71440: Python Inferior Mode Can’t Recognize My Prompt
Date: Sat, 8 Jun 2024 17:06:18 +0000

w32-ansi-code-page: 65001
w32-multibyte-code-page: 0

BTW, I turned on 
“Beta: Use Unicode UTF-8 for worldwide language support”.

Message #14 received at 71440 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "shynur ." <one.last.kiss <at> outlook.com>
Cc: 71440 <at> debbugs.gnu.org
Subject: Re: 
 Re: bug#71440: Python Inferior Mode Can’t Recognize My
 Prompt
Date: Sat, 08 Jun 2024 20:29:55 +0300

> From: "shynur ." <one.last.kiss <at> outlook.com>
> CC: "71440 <at> debbugs.gnu.org" <71440 <at> debbugs.gnu.org>
> Date: Sat, 8 Jun 2024 17:06:18 +0000
> msip_labels:
> 
> w32-ansi-code-page: 65001
> w32-multibyte-code-page: 0
> 
> BTW, I turned on 
> “Beta: Use Unicode UTF-8 for worldwide language support”.

I recommend against that.  Emacs on MS-Windows doesn't support UTF-8
well because Windows doesn't (yet).  Using UTF-8 on Windows as the
default encoding is very much not recommended, because most programs
you run from Emacs will not support that.

Your value of w32-ansi-code-page might be the reason for the problem.
Try disabling the beta feature and see if the problem goes away.

Message #17 received at 71440 <at> debbugs.gnu.org (full text, mbox):

From: "shynur ." <one.last.kiss <at> outlook.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "71440 <at> debbugs.gnu.org" <71440 <at> debbugs.gnu.org>
Subject: Re:  Re: bug#71440: Python Inferior Mode Can’t Recognize My Prompt
Date: Sat, 8 Jun 2024 17:46:35 +0000

After I turned off UTF-8 and restart computer,
they change to:

    w32-ansi-code-page: 1252
    w32-multibyte-code-page: 0

But the problem still exists.

Message #20 received at 71440 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "shynur ." <one.last.kiss <at> outlook.com>
Cc: 71440 <at> debbugs.gnu.org
Subject: Re: 
 Re:  Re: bug#71440: Python Inferior Mode Can’t
 Recognize My Prompt
Date: Sat, 08 Jun 2024 21:41:33 +0300

> From: "shynur ." <one.last.kiss <at> outlook.com>
> CC: "71440 <at> debbugs.gnu.org" <71440 <at> debbugs.gnu.org>
> Date: Sat, 8 Jun 2024 17:46:35 +0000
> msip_labels:
> 
> After I turned off UTF-8 and restart computer,
> they change to:
> 
>     w32-ansi-code-page: 1252
>     w32-multibyte-code-page: 0
> 
> But the problem still exists.

Because your PYTHONSTARTUP file is encoded in UTF-8, right?

Anyway, codepage 1252 cannot encode these two characters, so I think
you cannot use this value of PS2 at all on Windows with Emacs.  Sorry.

But it's a good thing that you disabled UTF-8 by default in Emacs, it
could probably cause you other problems.

Message #23 received at 71440 <at> debbugs.gnu.org (full text, mbox):

From: "shynur ." <one.last.kiss <at> outlook.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "71440 <at> debbugs.gnu.org" <71440 <at> debbugs.gnu.org>
Subject: Re:  Re:  Re: bug#71440: Python Inferior Mode Can’t Recognize My Prompt
Date: Sat, 8 Jun 2024 19:50:14 +0000

> Because your PYTHONSTARTUP file is encoded in UTF-8, right?

Yes.

> Anyway, codepage 1252 cannot encode these two characters

Python inferior mode works well with

```python
import sys
sys.ps1, sys.ps2 = "►", "▻"
```

The problem came after I change PS to "\033[32m►\033[0m".
"\033[32m" and "\033[0m" color the prompt in terminal.

Message #26 received at 71440 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "shynur ." <one.last.kiss <at> outlook.com>
Cc: 71440 <at> debbugs.gnu.org
Subject: Re: 
 Re:  Re:  Re: bug#71440: Python Inferior Mode Can’t
 Recognize My Prompt
Date: Sun, 09 Jun 2024 07:31:14 +0300

> From: "shynur ." <one.last.kiss <at> outlook.com>
> CC: "71440 <at> debbugs.gnu.org" <71440 <at> debbugs.gnu.org>
> Date: Sat, 8 Jun 2024 19:50:14 +0000
> 
> > Anyway, codepage 1252 cannot encode these two characters
> 
> Python inferior mode works well with
> 
> ```python
> import sys
> sys.ps1, sys.ps2 = "►", "▻"
> ```

I think you are lucky if it does work.

> The problem came after I change PS to "\033[32m►\033[0m".
> "\033[32m" and "\033[0m" color the prompt in terminal.

You expect that to show colors in Emacs as well?  If not, I suggest to
define PS1 and PS2 specially for the inferior Python.

Message #29 received at 71440 <at> debbugs.gnu.org (full text, mbox):

From: "shynur ." <one.last.kiss <at> outlook.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "71440 <at> debbugs.gnu.org" <71440 <at> debbugs.gnu.org>
Subject: Re: bug#71440: Python Inferior Mode Can’t Recognize My Prompt
Date: Sun, 9 Jun 2024 10:11:29 +0000

> You expect that to show colors in Emacs as well?

I don’t care about the color of Python’s prompt in Emacs,
because Emacs has its own color scheme which looks nice!

As long as Python Inferior Mode displays those two
characters (‘►’ and ‘▻’) correctly I’ll happy.

Actually it DOES - there’s no problem when I use Python 
Inferior Mode directly.

The problem occurs when I call ‘python-shell-send-buffer’
from a Python buffer, as mentioned in my original post:
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71440#5>.

> I suggest to define PS1 and PS2 specially for the inferior Python.

I have to say that this is hard to implement cleanly.

I’ve tried:

    (setopt python-shell-interpreter-args "-i -c sys.ps1,sys.ps2='►▻'")

but it turned out that the ‘PYTHONSTARTUP’ file is loaded 
after the statement following ‘-c’ is executed.

______

I think this can be a feature request: provide an option 
to ignore any setting-color character sequence (eg `\033[32m`)
in XXYYZZ Inferior Mode, because there’re so many REPL
apps using a colored prompt and Emacs may not handle them
properly.

Message #32 received at 71440 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "shynur ." <one.last.kiss <at> outlook.com>
Cc: 71440 <at> debbugs.gnu.org
Subject: Re: 
 Re: bug#71440: Python Inferior Mode Can’t Recognize My
 Prompt
Date: Sun, 09 Jun 2024 13:25:43 +0300

> From: "shynur ." <one.last.kiss <at> outlook.com>
> CC: "71440 <at> debbugs.gnu.org" <71440 <at> debbugs.gnu.org>
> Date: Sun, 9 Jun 2024 10:11:29 +0000
> msip_labels:
> 
> The problem occurs when I call ‘python-shell-send-buffer’
> from a Python buffer, as mentioned in my original post:
> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71440#5>.

I know almost nothing about Python, but I wonder how PS1 and PS2 are
at all relevant when using python-shell-send-buffer?  That function
sends the buffer text to Python, so where do PS1 and PS2 come into
play, and why does Python say "__PYTHON_EL_eval is not defined" just
because you have PS1 and PS2 customized?

If someone helps me understand that, maybe I will have further ideas.

> > I suggest to define PS1 and PS2 specially for the inferior Python.
> 
> I have to say that this is hard to implement cleanly.
> 
> I’ve tried:
> 
>     (setopt python-shell-interpreter-args "-i -c sys.ps1,sys.ps2='►▻'")
> 
> but it turned out that the ‘PYTHONSTARTUP’ file is loaded 
> after the statement following ‘-c’ is executed.

How about defining PYTHONSTARTUP to point to a different file?

> I think this can be a feature request: provide an option 
> to ignore any setting-color character sequence (eg `\033[32m`)
> in XXYYZZ Inferior Mode, because there’re so many REPL
> apps using a colored prompt and Emacs may not handle them
> properly.

I'm not sure I even understand how the color settings are relevant to
python-shell-send-buffer.

Message #35 received at 71440 <at> debbugs.gnu.org (full text, mbox):

From: "shynur ." <one.last.kiss <at> outlook.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "71440 <at> debbugs.gnu.org" <71440 <at> debbugs.gnu.org>
Subject: Re: bug#71440: Python Inferior Mode Can’t Recognize My Prompt
Date: Sun, 9 Jun 2024 10:49:19 +0000

> I wonder how PS1 and PS2 are at all relevant when using 
> python-shell-send-buffer?  That function sends the buffer
> text to Python, so where do PS1 and PS2 come into play,
> and why does Python say "__PYTHON_EL_eval is not defined" 
> just because you have PS1 and PS2 customized?

I know it’s *weird* but it just happened.
I gave the recipes in the original post for anyone to 
reproduce it.

> If someone helps me understand that, maybe I will have 
> further ideas.

How about CC this post to the maintainer(s) of ‘python.el’?

> How about defining PYTHONSTARTUP to point to a different 
> file?

This makes it inconvenient to add or modify content to the 
‘PYTHONSTARTUP’ file because each change needs to be synced
to another file that exists for Emacs.

Message #38 received at 71440 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "shynur ." <one.last.kiss <at> outlook.com>, kobarity <kobarity <at> gmail.com>
Cc: 71440 <at> debbugs.gnu.org
Subject: Re: 
 Re: bug#71440: Python Inferior Mode Can’t Recognize My
 Prompt
Date: Sun, 09 Jun 2024 14:02:42 +0300

> From: "shynur ." <one.last.kiss <at> outlook.com>
> CC: "71440 <at> debbugs.gnu.org" <71440 <at> debbugs.gnu.org>
> Date: Sun, 9 Jun 2024 10:49:19 +0000
> msip_labels:
> 
> > I wonder how PS1 and PS2 are at all relevant when using 
> > python-shell-send-buffer?  That function sends the buffer
> > text to Python, so where do PS1 and PS2 come into play,
> > and why does Python say "__PYTHON_EL_eval is not defined" 
> > just because you have PS1 and PS2 customized?
> 
> I know it’s *weird* but it just happened.
> I gave the recipes in the original post for anyone to 
> reproduce it.
> 
> > If someone helps me understand that, maybe I will have 
> > further ideas.
> 
> How about CC this post to the maintainer(s) of ‘python.el’?

Done.

> > How about defining PYTHONSTARTUP to point to a different 
> > file?
> 
> This makes it inconvenient to add or modify content to the 
> ‘PYTHONSTARTUP’ file because each change needs to be synced
> to another file that exists for Emacs.

You are on Windows, so some measure of inconvenience is expected.

Message #41 received at 71440 <at> debbugs.gnu.org (full text, mbox):

From: kobarity <kobarity <at> gmail.com>
To: "shynur ." <one.last.kiss <at> outlook.com>,
	Eli Zaretskii <eliz <at> gnu.org>
Cc: 71440 <at> debbugs.gnu.org
Subject: Re: bug#71440: Python Inferior Mode Can’t
 Recognize My Prompt
Date: Mon, 10 Jun 2024 00:26:50 +0900

[Message part 1 (text/plain, inline)]

Eli Zaretskii wrote:
> 
> > From: "shynur ." <one.last.kiss <at> outlook.com>
> > CC: "71440 <at> debbugs.gnu.org" <71440 <at> debbugs.gnu.org>
> > Date: Sun, 9 Jun 2024 10:49:19 +0000
> > msip_labels:
> > 
> > > I wonder how PS1 and PS2 are at all relevant when using 
> > > python-shell-send-buffer?  That function sends the buffer
> > > text to Python, so where do PS1 and PS2 come into play,
> > > and why does Python say "__PYTHON_EL_eval is not defined" 
> > > just because you have PS1 and PS2 customized?
> > 
> > I know it’s *weird* but it just happened.
> > I gave the recipes in the original post for anyone to 
> > reproduce it.
> > 
> > > If someone helps me understand that, maybe I will have 
> > > further ideas.
> > 
> > How about CC this post to the maintainer(s) of ‘python.el’?
> 
> Done.
> 
> > > How about defining PYTHONSTARTUP to point to a different 
> > > file?
> > 
> > This makes it inconvenient to add or modify content to the 
> > ‘PYTHONSTARTUP’ file because each change needs to be synced
> > to another file that exists for Emacs.
> 
> You are on Windows, so some measure of inconvenience is expected.

Seems like a bug or limitation in `python-shell-prompt-detect'.  Can
you try the attached diff?  It should work with Python 2.6 or higher.

[71440.diff (application/octet-stream, attachment)]

Message #44 received at 71440 <at> debbugs.gnu.org (full text, mbox):

From: "shynur ." <one.last.kiss <at> outlook.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "71440 <at> debbugs.gnu.org" <71440 <at> debbugs.gnu.org>
Subject: Re: bug#71440: Python Inferior Mode Canʼt Recognize My Prompt
Date: Sun, 9 Jun 2024 15:40:53 +0000

> Can you try the attached diff?

Thank you very much!
It works perfectly this time, except there’s a

    Warning (python): Python shell prompts cannot be detected.
    
I’ve configured Emacs to ignore it.

Message #47 received at 71440 <at> debbugs.gnu.org (full text, mbox):

From: kobarity <kobarity <at> gmail.com>
To: "shynur ." <one.last.kiss <at> outlook.com>,
	Eli Zaretskii <eliz <at> gnu.org>
Cc: 71440 <at> debbugs.gnu.org
Subject: Re: bug#71440: Python Inferior Mode Can’t
 Recognize My Prompt
Date: Wed, 12 Jun 2024 01:24:39 +0900

[Message part 1 (text/plain, inline)]

"shynur ." wrote:
> It works perfectly this time, except there’s a
>     Warning (python): Python shell prompts cannot be detected.

Thanks for testing.  Could you please try the improved patch I've
attached, which I believe will eliminate this warning as well?

> Eli Zaretskii wrote:
> > > > I wonder how PS1 and PS2 are at all relevant when using 
> > > > python-shell-send-buffer?  That function sends the buffer
> > > > text to Python, so where do PS1 and PS2 come into play,
> > > > and why does Python say "__PYTHON_EL_eval is not defined" 
> > > > just because you have PS1 and PS2 customized?

PS1 and PS2 are set to `comint-prompt-regexp', and used to identify
execution completion.  The prompts must also be identified to
determine if the command can be sent.

Python REPL cannot accept the Python code as is.  For example, try
pasting the following code to the REPL:

if True:
    print("True")
print("Hi")

You should see the message "SyntaxError: invalid syntax".  This is
because the REPL requires an empty line to recognize the completion of
a block.  For such reasons, `python-shell-send-*' sends a string as
the argument to __PYTHON_EL_eval instead of sending the code as is.

__PYTHON_EL_eval is defined during the initialization of inferior
Python, but if the prompt is not recognized, its definition cannot be
done either.

The prompts are recognized by `python-shell-prompt-detect'.  A small
Python code sends PS1, etc. to Emacs as an array of JSON strings.
However, the JSON strings are hand-crafted for compatibility, as noted
in the comments below.

                    ;; JSON is built manually for compatibility

The json package was added in Python 2.6, so I assume it is to support
Python 2.5 and earlier.  This is fine for prompts consisting only of
ordinary characters, but will not result in a correct JSON string if
it contains escape sequences.

The attached improved patch uses the json package if available, so it
can handle escape sequences; without the json package, it works as
before.  It means that prompts containing escape sequences can be
recognized in Python 2.6 or later.  I have also added an ERT to check
this.

In the Inferior Python buffer, the escape sequences are removed using
`ansi-color-filter-apply'.  Therefore, I used the same function to
remove escape sequences at the end of `python-shell-prompt-detect' to
make the prompts match.

Another approach would be to remove the escape sequences on the Python
side.  It seems to be possible to do this using regular expressions,
but there does not seem to be a dedicated function for this.

[0001-Allow-escape-sequences-in-Python-prompts.patch (application/octet-stream, attachment)]

Message #50 received at 71440 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: kobarity <kobarity <at> gmail.com>
Cc: one.last.kiss <at> outlook.com, 71440 <at> debbugs.gnu.org
Subject: Re: bug#71440: Python Inferior Mode Can’t
 Recognize My Prompt
Date: Wed, 12 Jun 2024 11:12:16 +0300

> Date: Wed, 12 Jun 2024 01:24:39 +0900
> From: kobarity <kobarity <at> gmail.com>
> Cc: 71440 <at> debbugs.gnu.org
> 
> 
> > Eli Zaretskii wrote:
> > > > > I wonder how PS1 and PS2 are at all relevant when using 
> > > > > python-shell-send-buffer?  That function sends the buffer
> > > > > text to Python, so where do PS1 and PS2 come into play,
> > > > > and why does Python say "__PYTHON_EL_eval is not defined" 
> > > > > just because you have PS1 and PS2 customized?
> 
> PS1 and PS2 are set to `comint-prompt-regexp', and used to identify
> execution completion.  The prompts must also be identified to
> determine if the command can be sent.
> 
> Python REPL cannot accept the Python code as is.  For example, try
> pasting the following code to the REPL:
> 
> if True:
>     print("True")
> print("Hi")
> 
> You should see the message "SyntaxError: invalid syntax".  This is
> because the REPL requires an empty line to recognize the completion of
> a block.  For such reasons, `python-shell-send-*' sends a string as
> the argument to __PYTHON_EL_eval instead of sending the code as is.
> 
> __PYTHON_EL_eval is defined during the initialization of inferior
> Python, but if the prompt is not recognized, its definition cannot be
> done either.
> 
> The prompts are recognized by `python-shell-prompt-detect'.  A small
> Python code sends PS1, etc. to Emacs as an array of JSON strings.
> However, the JSON strings are hand-crafted for compatibility, as noted
> in the comments below.
> 
>                     ;; JSON is built manually for compatibility
> 
> The json package was added in Python 2.6, so I assume it is to support
> Python 2.5 and earlier.  This is fine for prompts consisting only of
> ordinary characters, but will not result in a correct JSON string if
> it contains escape sequences.
> 
> The attached improved patch uses the json package if available, so it
> can handle escape sequences; without the json package, it works as
> before.  It means that prompts containing escape sequences can be
> recognized in Python 2.6 or later.  I have also added an ERT to check
> this.

Thanks, but what do you mean by "json package" here?  Emacs nowadays
has JSON capabilities built in, so no optional features should be
required.  I did I misunderstand what you say above?

Message #53 received at 71440 <at> debbugs.gnu.org (full text, mbox):

From: kobarity <kobarity <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: one.last.kiss <at> outlook.com, 71440 <at> debbugs.gnu.org
Subject: Re: bug#71440: Python Inferior Mode Can’t
 Recognize My Prompt
Date: Wed, 12 Jun 2024 22:09:45 +0900

Eli Zaretskii wrote:
> 
> > Date: Wed, 12 Jun 2024 01:24:39 +0900
> > From: kobarity <kobarity <at> gmail.com>
> > Cc: 71440 <at> debbugs.gnu.org
> > 
> > 
> > > Eli Zaretskii wrote:
> > > > > > I wonder how PS1 and PS2 are at all relevant when using 
> > > > > > python-shell-send-buffer?  That function sends the buffer
> > > > > > text to Python, so where do PS1 and PS2 come into play,
> > > > > > and why does Python say "__PYTHON_EL_eval is not defined" 
> > > > > > just because you have PS1 and PS2 customized?
> > 
> > PS1 and PS2 are set to `comint-prompt-regexp', and used to identify
> > execution completion.  The prompts must also be identified to
> > determine if the command can be sent.
> > 
> > Python REPL cannot accept the Python code as is.  For example, try
> > pasting the following code to the REPL:
> > 
> > if True:
> >     print("True")
> > print("Hi")
> > 
> > You should see the message "SyntaxError: invalid syntax".  This is
> > because the REPL requires an empty line to recognize the completion of
> > a block.  For such reasons, `python-shell-send-*' sends a string as
> > the argument to __PYTHON_EL_eval instead of sending the code as is.
> > 
> > __PYTHON_EL_eval is defined during the initialization of inferior
> > Python, but if the prompt is not recognized, its definition cannot be
> > done either.
> > 
> > The prompts are recognized by `python-shell-prompt-detect'.  A small
> > Python code sends PS1, etc. to Emacs as an array of JSON strings.
> > However, the JSON strings are hand-crafted for compatibility, as noted
> > in the comments below.
> > 
> >                     ;; JSON is built manually for compatibility
> > 
> > The json package was added in Python 2.6, so I assume it is to support
> > Python 2.5 and earlier.  This is fine for prompts consisting only of
> > ordinary characters, but will not result in a correct JSON string if
> > it contains escape sequences.
> > 
> > The attached improved patch uses the json package if available, so it
> > can handle escape sequences; without the json package, it works as
> > before.  It means that prompts containing escape sequences can be
> > recognized in Python 2.6 or later.  I have also added an ERT to check
> > this.
> 
> Thanks, but what do you mean by "json package" here?  Emacs nowadays
> has JSON capabilities built in, so no optional features should be
> required.  I did I misunderstand what you say above?

I meant the json package of the Python standard library.  A small
Python code is embedded in python.el.  I changed this Python code to
use the json package of the Python standard library if available.

It may be easier to see the actual code:

      (let* ((code (concat
                    "import sys\n"
                    "ps = [getattr(sys, 'ps%s' % i, '') for i in range(1,4)]\n"
                    "try:\n"
                    "    import json\n"
                    "    ps_json = '\\n' + json.dumps(ps)\n"
                    "except ImportError:\n"
                    ;; JSON is built manually for compatibility
                    "    ps_json = '\\n[\"%s\", \"%s\", \"%s\"]\\n' % tuple(ps)\n"
                    "\n"
                    "print (ps_json)\n"
                    "sys.exit(0)\n"))

Message #56 received at 71440 <at> debbugs.gnu.org (full text, mbox):

From: "shynur ." <one.last.kiss <at> outlook.com>
To: kobarity <kobarity <at> gmail.com>
Cc: "71440 <at> debbugs.gnu.org" <71440 <at> debbugs.gnu.org>
Subject: Re: bug#71440: Python Inferior Mode Can’t Recognize My Prompt
Date: Wed, 12 Jun 2024 16:57:23 +0000

kobarity:
> Could you please try the improved patch I've attached,
> which I believe will eliminate this warning as well?

Thanks.  No error or warning now.

Message #59 received at 71440 <at> debbugs.gnu.org (full text, mbox):

From: kobarity <kobarity <at> gmail.com>
To: "shynur ." <one.last.kiss <at> outlook.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: "71440 <at> debbugs.gnu.org" <71440 <at> debbugs.gnu.org>
Subject: Re: bug#71440: Python Inferior Mode Can’t
 Recognize My Prompt
Date: Thu, 13 Jun 2024 23:24:15 +0900

shynur . wrote:
> 
> kobarity:
> > Could you please try the improved patch I've attached,
> > which I believe will eliminate this warning as well?
> 
> Thanks.  No error or warning now.

Thanks for confirming.  Unless I get feedback from others, this is the
final version from me.

Message #64 received at 71440-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: kobarity <kobarity <at> gmail.com>
Cc: one.last.kiss <at> outlook.com, 71440-done <at> debbugs.gnu.org
Subject: Re: bug#71440: Python Inferior Mode Can’t
 Recognize My Prompt
Date: Sat, 15 Jun 2024 13:45:20 +0300

> Date: Thu, 13 Jun 2024 23:24:15 +0900
> From: kobarity <kobarity <at> gmail.com>
> Cc: "71440 <at> debbugs.gnu.org" <71440 <at> debbugs.gnu.org>
> 
> shynur . wrote:
> > 
> > kobarity:
> > > Could you please try the improved patch I've attached,
> > > which I believe will eliminate this warning as well?
> > 
> > Thanks.  No error or warning now.
> 
> Thanks for confirming.  Unless I get feedback from others, this is the
> final version from me.

Now installed on master, and closing the bug.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.