GNU bug report logs -
#79036
[PATCH] Fix pdb tracking for remote filenames
Previous Next
To reply to this bug, email your comments to 79036 AT debbugs.gnu.org.
There is no need to reopen the bug first.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Thu, 17 Jul 2025 04:59:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Liu Hui <liuhui1610 <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 17 Jul 2025 04:59:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
The recipe:
1. emacs -Q
2. Create a remote python file and start the remote python shell, e.g.
M-x find-file /ssh:server:/tmp/test.py
M-x run-python
3. Insert the following code in test.py and press C-c C-c to send it
to the python shell:
def f():
breakpoint()
return 1
4. Execute f() in the python shell to trigger the pdb
Result: Emacs tries to open /ssh:server:/ssh:server:/tmp/test.py
instead of /ssh:server:/tmp/test.py.
The reason is the filename set by python-shell-send-string may be
remote. The attached patch fixes the issue.
--
Liu Hui
[0001-Fix-pdb-tracking-for-remote-filenames.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Thu, 17 Jul 2025 06:43:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 79036 <at> debbugs.gnu.org (full text, mbox):
> From: Liu Hui <liuhui1610 <at> gmail.com>
> Date: Thu, 17 Jul 2025 12:57:45 +0800
>
> 1. emacs -Q
> 2. Create a remote python file and start the remote python shell, e.g.
> M-x find-file /ssh:server:/tmp/test.py
> M-x run-python
> 3. Insert the following code in test.py and press C-c C-c to send it
> to the python shell:
>
> def f():
> breakpoint()
> return 1
>
> 4. Execute f() in the python shell to trigger the pdb
>
> Result: Emacs tries to open /ssh:server:/ssh:server:/tmp/test.py
> instead of /ssh:server:/tmp/test.py.
>
> The reason is the filename set by python-shell-send-string may be
> remote. The attached patch fixes the issue.
>
> From b9770cea20186d0205319efb54327099849e3a21 Mon Sep 17 00:00:00 2001
> From: Liu Hui <liuhui1610 <at> gmail.com>
> Date: Thu, 17 Jul 2025 12:43:34 +0800
> Subject: [PATCH] Fix pdb tracking for remote filenames
>
> * lisp/progmodes/python.el (python-pdbtrack-set-tracked-buffer):
> Check remote file names.
> ---
> lisp/progmodes/python.el | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
> index f4f0518dbfd..59977fcb49f 100644
> --- a/lisp/progmodes/python.el
> +++ b/lisp/progmodes/python.el
> @@ -5079,8 +5079,10 @@ python-pdbtrack-set-tracked-buffer
> "Set the buffer for FILE-NAME as the tracked buffer.
> Internally it uses the `python-pdbtrack-tracked-buffer' variable.
> Returns the tracked buffer."
> - (let* ((file-name-prospect (concat (file-remote-p default-directory)
> - file-name))
> + (let* ((file-name-prospect (if (file-remote-p file-name)
> + file-name
> + (concat (file-remote-p default-directory)
> + file-name)))
> (file-buffer (get-file-buffer file-name-prospect)))
> (unless file-buffer
> (cond
Shouldn't this code use 'expand-file-name' instead? Using 'concat' to
construct file names is a bug waiting to happen, IME.
Michael, WDYT?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Thu, 17 Jul 2025 06:48:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 79036 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
>> diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
>> index f4f0518dbfd..59977fcb49f 100644
>> --- a/lisp/progmodes/python.el
>> +++ b/lisp/progmodes/python.el
>> @@ -5079,8 +5079,10 @@ python-pdbtrack-set-tracked-buffer
>> "Set the buffer for FILE-NAME as the tracked buffer.
>> Internally it uses the `python-pdbtrack-tracked-buffer' variable.
>> Returns the tracked buffer."
>> - (let* ((file-name-prospect (concat (file-remote-p default-directory)
>> - file-name))
>> + (let* ((file-name-prospect (if (file-remote-p file-name)
>> + file-name
>> + (concat (file-remote-p default-directory)
>> + file-name)))
>> (file-buffer (get-file-buffer file-name-prospect)))
>> (unless file-buffer
>> (cond
>
> Shouldn't this code use 'expand-file-name' instead? Using 'concat' to
> construct file names is a bug waiting to happen, IME.
`expand-file-name' wouldn't work if file-name is an absolute file name.
`file-remote-p' is designed to cooperate with `concat'. It mentions it
in its docstring.
> Michael, WDYT?
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Thu, 17 Jul 2025 07:49:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 79036 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Liu Hui <liuhui1610 <at> gmail.com>, 79036 <at> debbugs.gnu.org
> Date: Thu, 17 Jul 2025 08:47:08 +0200
>
> >> diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
> >> index f4f0518dbfd..59977fcb49f 100644
> >> --- a/lisp/progmodes/python.el
> >> +++ b/lisp/progmodes/python.el
> >> @@ -5079,8 +5079,10 @@ python-pdbtrack-set-tracked-buffer
> >> "Set the buffer for FILE-NAME as the tracked buffer.
> >> Internally it uses the `python-pdbtrack-tracked-buffer' variable.
> >> Returns the tracked buffer."
> >> - (let* ((file-name-prospect (concat (file-remote-p default-directory)
> >> - file-name))
> >> + (let* ((file-name-prospect (if (file-remote-p file-name)
> >> + file-name
> >> + (concat (file-remote-p default-directory)
> >> + file-name)))
> >> (file-buffer (get-file-buffer file-name-prospect)))
> >> (unless file-buffer
> >> (cond
> >
> > Shouldn't this code use 'expand-file-name' instead? Using 'concat' to
> > construct file names is a bug waiting to happen, IME.
>
> `expand-file-name' wouldn't work if file-name is an absolute file name.
I guess I'm missing something: doesn't this code want to produce an
absolute file name? If not, what does it try to do?
> `file-remote-p' is designed to cooperate with `concat'. It mentions it
> in its docstring.
So you agree with the patch? It looks strange to me that we should
use file-remote-p in the branch where it is known that FILE-NAME is
not a remote file name.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Thu, 17 Jul 2025 08:19:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 79036 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
>> >> diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
>> >> index f4f0518dbfd..59977fcb49f 100644
>> >> --- a/lisp/progmodes/python.el
>> >> +++ b/lisp/progmodes/python.el
>> >> @@ -5079,8 +5079,10 @@ python-pdbtrack-set-tracked-buffer
>> >> "Set the buffer for FILE-NAME as the tracked buffer.
>> >> Internally it uses the `python-pdbtrack-tracked-buffer' variable.
>> >> Returns the tracked buffer."
>> >> - (let* ((file-name-prospect (concat (file-remote-p default-directory)
>> >> - file-name))
>> >> + (let* ((file-name-prospect (if (file-remote-p file-name)
>> >> + file-name
>> >> + (concat (file-remote-p default-directory)
>> >> + file-name)))
>> >> (file-buffer (get-file-buffer file-name-prospect)))
>> >> (unless file-buffer
>> >> (cond
>> >
>> > Shouldn't this code use 'expand-file-name' instead? Using 'concat' to
>> > construct file names is a bug waiting to happen, IME.
>>
>> `expand-file-name' wouldn't work if file-name is an absolute file name.
>
> I guess I'm missing something: doesn't this code want to produce an
> absolute file name? If not, what does it try to do?
>
>> `file-remote-p' is designed to cooperate with `concat'. It mentions it
>> in its docstring.
>
> So you agree with the patch? It looks strange to me that we should
> use file-remote-p in the branch where it is known that FILE-NAME is
> not a remote file name.
I didn't check the code, so I don't know whether file-name is guaranteed
to be a relative file name. The docstring doesn't tell about this promise.
I just checked the file-remote-p construct, used with concat.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Thu, 17 Jul 2025 08:47:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 79036 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: liuhui1610 <at> gmail.com, 79036 <at> debbugs.gnu.org
> Date: Thu, 17 Jul 2025 10:18:41 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> Hi Eli,
>
> >> >> diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
> >> >> index f4f0518dbfd..59977fcb49f 100644
> >> >> --- a/lisp/progmodes/python.el
> >> >> +++ b/lisp/progmodes/python.el
> >> >> @@ -5079,8 +5079,10 @@ python-pdbtrack-set-tracked-buffer
> >> >> "Set the buffer for FILE-NAME as the tracked buffer.
> >> >> Internally it uses the `python-pdbtrack-tracked-buffer' variable.
> >> >> Returns the tracked buffer."
> >> >> - (let* ((file-name-prospect (concat (file-remote-p default-directory)
> >> >> - file-name))
> >> >> + (let* ((file-name-prospect (if (file-remote-p file-name)
> >> >> + file-name
> >> >> + (concat (file-remote-p default-directory)
> >> >> + file-name)))
> >> >> (file-buffer (get-file-buffer file-name-prospect)))
> >> >> (unless file-buffer
> >> >> (cond
> >> >
> >> > Shouldn't this code use 'expand-file-name' instead? Using 'concat' to
> >> > construct file names is a bug waiting to happen, IME.
> >>
> >> `expand-file-name' wouldn't work if file-name is an absolute file name.
> >
> > I guess I'm missing something: doesn't this code want to produce an
> > absolute file name? If not, what does it try to do?
> >
> >> `file-remote-p' is designed to cooperate with `concat'. It mentions it
> >> in its docstring.
> >
> > So you agree with the patch? It looks strange to me that we should
> > use file-remote-p in the branch where it is known that FILE-NAME is
> > not a remote file name.
>
> I didn't check the code, so I don't know whether file-name is guaranteed
> to be a relative file name. The docstring doesn't tell about this promise.
>
> I just checked the file-remote-p construct, used with concat.
Thanks.
So now, Liu Hui, please explain the problem in more detail.
I stared at the code for some time, and I don't understand why it goes
to such great lengths here:
(let* ((file-name-prospect (concat (file-remote-p default-directory)
file-name))
(file-buffer (get-file-buffer file-name-prospect)))
(unless file-buffer
(cond
((file-exists-p file-name-prospect)
(setq file-buffer (find-file-noselect file-name-prospect)))
((and (not (equal file-name file-name-prospect))
(file-exists-p file-name))
;; Fallback to a locally available copy of the file.
(setq file-buffer (find-file-noselect file-name-prospect))))
Why not just call find-file-noselect with FILE-NAME as its argument?
The function find-file-noselect will itself check if there's already a
buffer visiting that file, so it's unnecessary to do that "by hand"
here. And I don't see the reason for that 'concat' dance, either,
since find-file-noselect again does everything that needs to be done
internally. So what am I missing here?
kobarity, any comments or suggestions?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Thu, 17 Jul 2025 10:22:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 79036 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jul 17, 2025 at 4:46 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> So now, Liu Hui, please explain the problem in more detail.
>
> I stared at the code for some time, and I don't understand why it goes
> to such great lengths here:
>
> (let* ((file-name-prospect (concat (file-remote-p default-directory)
> file-name))
> (file-buffer (get-file-buffer file-name-prospect)))
> (unless file-buffer
> (cond
> ((file-exists-p file-name-prospect)
> (setq file-buffer (find-file-noselect file-name-prospect)))
> ((and (not (equal file-name file-name-prospect))
> (file-exists-p file-name))
> ;; Fallback to a locally available copy of the file.
> (setq file-buffer (find-file-noselect file-name-prospect))))
>
> Why not just call find-file-noselect with FILE-NAME as its argument?
> The function find-file-noselect will itself check if there's already a
> buffer visiting that file, so it's unnecessary to do that "by hand"
> here. And I don't see the reason for that 'concat' dance, either,
> since find-file-noselect again does everything that needs to be done
> internally. So what am I missing here?
Because file-name may be not the actual file. file-name is actually
extracted from the pdb output in the python shell, e.g.
>>> f()
> /ssh:server:/tmp/test.py(3)f()
(Pdb)
Generally, pdb shows local file names. But if we send the code using
C-c C-c from python buffers (i.e. step 3), python-send-string passes
(buffer-file-name), which may be a remote file name, to python
process. Therefore, pdb may also shows remote file names.
Then, if file-name is remote, we don't prepend any prefix (the updated
behavior in the patch) and calling find-file-noselect is enough.
If we execute "from test import f; f()" in the remote python shell,
instead of C-c C-c, the pdb output is:
>>> from test import f; f()
> /tmp/test.py(3)f()
-> return 1
(Pdb)
Then file-name "/tmp/test.py" is local, but the actually file is
remote. Therefore, the code tries to prepend the remote prefix of
python shell to file-name by concat.
There are also other cases, e.g. sending code in a local file to a
remote python process, or sending code in a remote file to a local
python process. Therefore, the code becomes complex.
In fact, I just find a bug when sending code in a local file to a
remote python process:
1. emacs -Q and start a remote python shell
2. Create a local python file, e.g. /tmp/foo.py
3. Insert the following code in foo.py and press C-c C-c to send it
to the remote python shell:
def g():
breakpoint()
return 2
4. Execute g() in the python shell to trigger the pdb
Result: Emacs tries to open /ssh:server:/tmp/foo.py instead of
/tmp/foo.py.
I will try to update the patch to fix both problems.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Thu, 17 Jul 2025 11:12:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 79036 <at> debbugs.gnu.org (full text, mbox):
Liu Hui <liuhui1610 <at> gmail.com> writes:
Hi,
> Because file-name may be not the actual file. file-name is actually
> extracted from the pdb output in the python shell, e.g.
>
> >>> f()
> > /ssh:server:/tmp/test.py(3)f()
> (Pdb)
>
> Generally, pdb shows local file names. But if we send the code using
> C-c C-c from python buffers (i.e. step 3), python-send-string passes
> (buffer-file-name), which may be a remote file name, to python
> process. Therefore, pdb may also shows remote file names.
This is an error. python-send-string shall send (file-local-name (buffer-file-name)) .
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Thu, 17 Jul 2025 12:10:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 79036 <at> debbugs.gnu.org (full text, mbox):
> From: Liu Hui <liuhui1610 <at> gmail.com>
> Date: Thu, 17 Jul 2025 18:20:59 +0800
> Cc: Michael Albinus <michael.albinus <at> gmx.de>, kobarity <kobarity <at> gmail.com>, 79036 <at> debbugs.gnu.org
>
> On Thu, Jul 17, 2025 at 4:46 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > So now, Liu Hui, please explain the problem in more detail.
> >
> > I stared at the code for some time, and I don't understand why it goes
> > to such great lengths here:
> >
> > (let* ((file-name-prospect (concat (file-remote-p default-directory)
> > file-name))
> > (file-buffer (get-file-buffer file-name-prospect)))
> > (unless file-buffer
> > (cond
> > ((file-exists-p file-name-prospect)
> > (setq file-buffer (find-file-noselect file-name-prospect)))
> > ((and (not (equal file-name file-name-prospect))
> > (file-exists-p file-name))
> > ;; Fallback to a locally available copy of the file.
> > (setq file-buffer (find-file-noselect file-name-prospect))))
> >
> > Why not just call find-file-noselect with FILE-NAME as its argument?
> > The function find-file-noselect will itself check if there's already a
> > buffer visiting that file, so it's unnecessary to do that "by hand"
> > here. And I don't see the reason for that 'concat' dance, either,
> > since find-file-noselect again does everything that needs to be done
> > internally. So what am I missing here?
>
> Because file-name may be not the actual file. file-name is actually
> extracted from the pdb output in the python shell, e.g.
>
> >>> f()
> > /ssh:server:/tmp/test.py(3)f()
> (Pdb)
>
> Generally, pdb shows local file names. But if we send the code using
> C-c C-c from python buffers (i.e. step 3), python-send-string passes
> (buffer-file-name), which may be a remote file name, to python
> process. Therefore, pdb may also shows remote file names.
>
> Then, if file-name is remote, we don't prepend any prefix (the updated
> behavior in the patch) and calling find-file-noselect is enough.
My question was why cannot we simply call find-file-noselect
regardless of whether file-name is local or remote? And why do we
need all those checks with explicit calls to get-file-buffer etc.?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Thu, 17 Jul 2025 13:31:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 79036 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jul 17, 2025 at 8:09 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Liu Hui <liuhui1610 <at> gmail.com>
> > Date: Thu, 17 Jul 2025 18:20:59 +0800
> > Cc: Michael Albinus <michael.albinus <at> gmx.de>, kobarity <kobarity <at> gmail.com>, 79036 <at> debbugs.gnu.org
> >
> > On Thu, Jul 17, 2025 at 4:46 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > > So now, Liu Hui, please explain the problem in more detail.
> > >
> > > I stared at the code for some time, and I don't understand why it goes
> > > to such great lengths here:
> > >
> > > (let* ((file-name-prospect (concat (file-remote-p default-directory)
> > > file-name))
> > > (file-buffer (get-file-buffer file-name-prospect)))
> > > (unless file-buffer
> > > (cond
> > > ((file-exists-p file-name-prospect)
> > > (setq file-buffer (find-file-noselect file-name-prospect)))
> > > ((and (not (equal file-name file-name-prospect))
> > > (file-exists-p file-name))
> > > ;; Fallback to a locally available copy of the file.
> > > (setq file-buffer (find-file-noselect file-name-prospect))))
> > >
> > > Why not just call find-file-noselect with FILE-NAME as its argument?
> > > The function find-file-noselect will itself check if there's already a
> > > buffer visiting that file, so it's unnecessary to do that "by hand"
> > > here. And I don't see the reason for that 'concat' dance, either,
> > > since find-file-noselect again does everything that needs to be done
> > > internally. So what am I missing here?
> >
> > Because file-name may be not the actual file. file-name is actually
> > extracted from the pdb output in the python shell, e.g.
> >
> > >>> f()
> > > /ssh:server:/tmp/test.py(3)f()
> > (Pdb)
> >
> > Generally, pdb shows local file names. But if we send the code using
> > C-c C-c from python buffers (i.e. step 3), python-send-string passes
> > (buffer-file-name), which may be a remote file name, to python
> > process. Therefore, pdb may also shows remote file names.
> >
> > Then, if file-name is remote, we don't prepend any prefix (the updated
> > behavior in the patch) and calling find-file-noselect is enough.
>
> My question was why cannot we simply call find-file-noselect
> regardless of whether file-name is local or remote? And why do we
> need all those checks with explicit calls to get-file-buffer etc.?
I have provided an example:
>>> from test import f; f()
> /tmp/test.py(3)f()
-> return 1
(Pdb)
Given above pdb output in the remote python shell, the file-name
"/tmp/test.py" is local and find-file-noselect will simply open the
local file. But the file is on the remote system.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Thu, 17 Jul 2025 13:35:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 79036 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jul 17, 2025 at 7:10 PM Michael Albinus <michael.albinus <at> gmx.de> wrote:
>
> Liu Hui <liuhui1610 <at> gmail.com> writes:
>
> Hi,
>
> > Because file-name may be not the actual file. file-name is actually
> > extracted from the pdb output in the python shell, e.g.
> >
> > >>> f()
> > > /ssh:server:/tmp/test.py(3)f()
> > (Pdb)
> >
> > Generally, pdb shows local file names. But if we send the code using
> > C-c C-c from python buffers (i.e. step 3), python-send-string passes
> > (buffer-file-name), which may be a remote file name, to python
> > process. Therefore, pdb may also shows remote file names.
>
> This is an error. python-send-string shall send (file-local-name (buffer-file-name)) .
Why is it an error? In python-shell-send-string, (buffer-file-name) is
finally passed to python's compile function in __PYTHON_EL_eval or
__PYTHON_EL_eval_file, and is just used for run-time error messages
according to the docstring.
The filename argument should give the file from which the code was
read; pass some recognizable value if it wasn’t read from a file
('<string>' is commonly used).
I think it is suitable to use a remote filename or even buffer name as
long as it helps Emacs find the source.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Thu, 17 Jul 2025 13:46:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 79036 <at> debbugs.gnu.org (full text, mbox):
Liu Hui <liuhui1610 <at> gmail.com> writes:
Hi,
>> > Because file-name may be not the actual file. file-name is actually
>> > extracted from the pdb output in the python shell, e.g.
>> >
>> > >>> f()
>> > > /ssh:server:/tmp/test.py(3)f()
>> > (Pdb)
>> >
>> > Generally, pdb shows local file names. But if we send the code using
>> > C-c C-c from python buffers (i.e. step 3), python-send-string passes
>> > (buffer-file-name), which may be a remote file name, to python
>> > process. Therefore, pdb may also shows remote file names.
>>
>> This is an error. python-send-string shall send (file-local-name (buffer-file-name)) .
>
> Why is it an error? In python-shell-send-string, (buffer-file-name) is
> finally passed to python's compile function in __PYTHON_EL_eval or
> __PYTHON_EL_eval_file, and is just used for run-time error messages
> according to the docstring.
>
> The filename argument should give the file from which the code was
> read; pass some recognizable value if it wasn’t read from a file
> ('<string>' is commonly used).
>
> I think it is suitable to use a remote filename or even buffer name as
> long as it helps Emacs find the source.
This bug report is about an inconsistenccy in pdb. Sometimes it shows
absolute file names which should be interpreted as remote file
names. Sometimes, the file names are already prefixed with the remote
identification.
If python-shell-send-string does not use remote file names, your patch
isn't needed. The existing code
--8<---------------cut here---------------start------------->8---
(let* ((file-name-prospect (concat (file-remote-p default-directory)
file-name))
--8<---------------cut here---------------end--------------->8---
would be OK.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Thu, 17 Jul 2025 14:24:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 79036 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jul 17, 2025 at 9:45 PM Michael Albinus <michael.albinus <at> gmx.de> wrote:
>
> Liu Hui <liuhui1610 <at> gmail.com> writes:
>
> Hi,
>
> >> > Because file-name may be not the actual file. file-name is actually
> >> > extracted from the pdb output in the python shell, e.g.
> >> >
> >> > >>> f()
> >> > > /ssh:server:/tmp/test.py(3)f()
> >> > (Pdb)
> >> >
> >> > Generally, pdb shows local file names. But if we send the code using
> >> > C-c C-c from python buffers (i.e. step 3), python-send-string passes
> >> > (buffer-file-name), which may be a remote file name, to python
> >> > process. Therefore, pdb may also shows remote file names.
> >>
> >> This is an error. python-send-string shall send (file-local-name (buffer-file-name)) .
> >
> > Why is it an error? In python-shell-send-string, (buffer-file-name) is
> > finally passed to python's compile function in __PYTHON_EL_eval or
> > __PYTHON_EL_eval_file, and is just used for run-time error messages
> > according to the docstring.
> >
> > The filename argument should give the file from which the code was
> > read; pass some recognizable value if it wasn’t read from a file
> > ('<string>' is commonly used).
> >
> > I think it is suitable to use a remote filename or even buffer name as
> > long as it helps Emacs find the source.
>
> This bug report is about an inconsistenccy in pdb. Sometimes it shows
> absolute file names which should be interpreted as remote file
> names. Sometimes, the file names are already prefixed with the remote
> identification.
>
> If python-shell-send-string does not use remote file names, your patch
> isn't needed. The existing code
>
> --8<---------------cut here---------------start------------->8---
> (let* ((file-name-prospect (concat (file-remote-p default-directory)
> file-name))
> --8<---------------cut here---------------end--------------->8---
>
> would be OK.
Yes, forcing python-shell-send-string to use local filenames would
also solve the original problem, but may cause other problems. For
example, when sending some codes in a remote file to the local python
process, without the remote indentation, pdbtrack cannot find the
remote file.
So I think using remote file names in python-shell-send-string is a
feature rather than a bug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Thu, 17 Jul 2025 14:32:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 79036 <at> debbugs.gnu.org (full text, mbox):
> From: Liu Hui <liuhui1610 <at> gmail.com>
> Date: Thu, 17 Jul 2025 21:30:01 +0800
> Cc: michael.albinus <at> gmx.de, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
>
> On Thu, Jul 17, 2025 at 8:09 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > My question was why cannot we simply call find-file-noselect
> > regardless of whether file-name is local or remote? And why do we
> > need all those checks with explicit calls to get-file-buffer etc.?
>
> I have provided an example:
>
> >>> from test import f; f()
> > /tmp/test.py(3)f()
> -> return 1
> (Pdb)
>
> Given above pdb output in the remote python shell, the file-name
> "/tmp/test.py" is local and find-file-noselect will simply open the
> local file. But the file is on the remote system.
Thanks, I see now.
So we need a function called, say, remote-file-name, which, when given
a file name, even an absolute one, will consider it to be on the
remote host indicated by default-directory, and will be equivalent to
expand-file-name if default-directory is a local one, is that right?
Michael, don't we already have such a function?
If we did have such a function, wouldn't it be enough to just call
(find-file-noselect (remote-file-name file-name))
? That is, we won't need to call get-file-buffer, nor file-exists-p,
right? Or am I still missing something?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Thu, 17 Jul 2025 14:47:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 79036 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
> So we need a function called, say, remote-file-name, which, when given
> a file name, even an absolute one, will consider it to be on the
> remote host indicated by default-directory, and will be equivalent to
> expand-file-name if default-directory is a local one, is that right?
>
> Michael, don't we already have such a function?
No, we haven't IIRC. Something like this? (untested)
--8<---------------cut here---------------start------------->8---
(defun file-remote-name (file)
"Return the remote file name of FILE.
If FILE is already remote, return it as it is.
If `default-directory' is local, return FILE as it is.
Otherwise, prepend the remote file name component of `default-directory'
to FILE."
(if (file-remote-p file)
file
(concat (file-remote-p default-directory) file)))
--8<---------------cut here---------------end--------------->8---
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Thu, 17 Jul 2025 15:01:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 79036 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Liu Hui <liuhui1610 <at> gmail.com>, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
> Date: Thu, 17 Jul 2025 16:46:13 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > So we need a function called, say, remote-file-name, which, when given
> > a file name, even an absolute one, will consider it to be on the
> > remote host indicated by default-directory, and will be equivalent to
> > expand-file-name if default-directory is a local one, is that right?
> >
> > Michael, don't we already have such a function?
>
> No, we haven't IIRC. Something like this? (untested)
>
> --8<---------------cut here---------------start------------->8---
> (defun file-remote-name (file)
> "Return the remote file name of FILE.
> If FILE is already remote, return it as it is.
> If `default-directory' is local, return FILE as it is.
> Otherwise, prepend the remote file name component of `default-directory'
> to FILE."
> (if (file-remote-p file)
> file
> (concat (file-remote-p default-directory) file)))
> --8<---------------cut here---------------end--------------->8---
I'm missing expand-file-name somewhere (FILE could be not an absolute
file name) in the case that FILE is a local file. Otherwise, yes,
thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Thu, 17 Jul 2025 15:10:03 GMT)
Full text and
rfc822 format available.
Message #53 received at 79036 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> > So we need a function called, say, remote-file-name, which, when given
>> > a file name, even an absolute one, will consider it to be on the
>> > remote host indicated by default-directory, and will be equivalent to
>> > expand-file-name if default-directory is a local one, is that right?
>> >
>> > Michael, don't we already have such a function?
>>
>> No, we haven't IIRC. Something like this? (untested)
>>
>> --8<---------------cut here---------------start------------->8---
>> (defun file-remote-name (file)
>> "Return the remote file name of FILE.
>> If FILE is already remote, return it as it is.
>> If `default-directory' is local, return FILE as it is.
>> Otherwise, prepend the remote file name component of `default-directory'
>> to FILE."
>> (if (file-remote-p file)
>> file
>> (concat (file-remote-p default-directory) file)))
>> --8<---------------cut here---------------end--------------->8---
>
> I'm missing expand-file-name somewhere (FILE could be not an absolute
> file name) in the case that FILE is a local file. Otherwise, yes,
> thanks.
I have left it out by intention. expand-file-name has a price on remote
systems, it should be called explicitly by the callee of
file-remote-name. So maybe we do something like this:
--8<---------------cut here---------------start------------->8---
(defun file-remote-name (file)
"Return the remote file name of FILE.
If FILE is a relative file name, return FILE as it is.
If FILE is already remote, return FILE as it is.
If `default-directory' is local, return FILE as it is.
Otherwise, prepend the remote file name component of `default-directory'
to FILE."
(if (or (not (file-absolute-p file)) (file-remote-p file))
file
(concat (file-remote-p default-directory) file)))
--8<---------------cut here---------------end--------------->8---
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Thu, 17 Jul 2025 15:47:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 79036 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: liuhui1610 <at> gmail.com, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
> Date: Thu, 17 Jul 2025 17:09:13 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > I'm missing expand-file-name somewhere (FILE could be not an absolute
> > file name) in the case that FILE is a local file. Otherwise, yes,
> > thanks.
>
> I have left it out by intention. expand-file-name has a price on remote
> systems
I meant to call expand-file-name only in the local case. AFAIU, if
file-remote-p returns non-nil, its argument is already an absolute
file name. But the alternative:
(concat (file-remote-p default-directory) file)
will not necessarily produce an absolute file name.
> (defun file-remote-name (file)
> "Return the remote file name of FILE.
> If FILE is a relative file name, return FILE as it is.
> If FILE is already remote, return FILE as it is.
> If `default-directory' is local, return FILE as it is.
> Otherwise, prepend the remote file name component of `default-directory'
> to FILE."
I would like this to be the equivalent of expand-file-name, so we
could use it instead of expand-file-name when an absolute file name
actually names a remote file. If we return a relative file name, Lisp
programs will need to call expand-file-name on them, which is not what
we want, IMO.
And I'm not sure I understand what you are trying to say here:
> expand-file-name has a price on remote systems, it should be called
> explicitly by the callee of file-remote-name
(I guess you meant "caller", not "callee".) If you want to avoid the
price of calling expand-file-name when FILE is already expanded, we
can call expand-file-name only on relative file names and only if
default-directory is local. Would that solve the problem?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Thu, 17 Jul 2025 15:54:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 79036 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
> I meant to call expand-file-name only in the local case. AFAIU, if
> file-remote-p returns non-nil, its argument is already an absolute
> file name. But the alternative:
>
> (concat (file-remote-p default-directory) file)
>
> will not necessarily produce an absolute file name.
Sure. That's why I don't use it in case FILE is relative.
>> (defun file-remote-name (file)
>> "Return the remote file name of FILE.
>> If FILE is a relative file name, return FILE as it is.
>> If FILE is already remote, return FILE as it is.
>> If `default-directory' is local, return FILE as it is.
>> Otherwise, prepend the remote file name component of `default-directory'
>> to FILE."
>
> I would like this to be the equivalent of expand-file-name, so we
> could use it instead of expand-file-name when an absolute file name
> actually names a remote file. If we return a relative file name, Lisp
> programs will need to call expand-file-name on them, which is not what
> we want, IMO.
Again, the function shall be as cheap as file-local-name or
file-remote-p. No round-trip to the remote, in no case.
(I remember when I've added file-local-name. I was blamed for
performance problems.)
> And I'm not sure I understand what you are trying to say here:
>
>> expand-file-name has a price on remote systems, it should be called
>> explicitly by the callee of file-remote-name
>
> (I guess you meant "caller", not "callee".)
Of course.
> If you want to avoid the
> price of calling expand-file-name when FILE is already expanded, we
> can call expand-file-name only on relative file names and only if
> default-directory is local. Would that solve the problem?
It isn't simply needed. Whatever the new function returns, it is good
for being used with expand-file-name. Just a granular function.
It is up to the callee (sic :-) to apply expand-file-name if needed.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Thu, 17 Jul 2025 15:57:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 79036 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: liuhui1610 <at> gmail.com, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
> Date: Thu, 17 Jul 2025 17:52:59 +0200
>
> > And I'm not sure I understand what you are trying to say here:
> >
> >> expand-file-name has a price on remote systems, it should be called
> >> explicitly by the callee of file-remote-name
> >
> > (I guess you meant "caller", not "callee".)
>
> Of course.
>
> > If you want to avoid the
> > price of calling expand-file-name when FILE is already expanded, we
> > can call expand-file-name only on relative file names and only if
> > default-directory is local. Would that solve the problem?
>
> It isn't simply needed.
How so?
> Whatever the new function returns, it is good for being used with
> expand-file-name. Just a granular function.
>
> It is up to the callee (sic :-) to apply expand-file-name if needed.
If they will always call expand-file-name on the result, we might as
well call it internally and make the usage simpler.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Thu, 17 Jul 2025 16:35:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 79036 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Whatever the new function returns, it is good for being used with
>> expand-file-name. Just a granular function.
>>
>> It is up to the callee (sic :-) to apply expand-file-name if needed.
>
> If they will always call expand-file-name on the result, we might as
> well call it internally and make the usage simpler.
"If". We don't know the future usage pattern. And this bug report has
shown us an example, which doesn't seem to callexpand-file-name (I
mhaven't scanned the whole code, 'tho).
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Fri, 18 Jul 2025 04:48:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 79036 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Jul 17, 2025 at 10:31 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> So we need a function called, say, remote-file-name, which, when given
> a file name, even an absolute one, will consider it to be on the
> remote host indicated by default-directory, and will be equivalent to
> expand-file-name if default-directory is a local one, is that right?
>
> Michael, don't we already have such a function?
>
> If we did have such a function, wouldn't it be enough to just call
>
> (find-file-noselect (remote-file-name file-name))
>
> ? That is, we won't need to call get-file-buffer, nor file-exists-p,
> right? Or am I still missing something?
They are still needed because python-pdbtrack-set-tracked-buffer is
not just used to visit file-name.
If the file-buffer already exists, which uses get-file-buffer for
checking, we don't kill it when pdb finishes. Otherwise, the
file-buffer will be created by find-file-noselect and added to
python-pdbtrack-buffers-to-kill.
file-exists-p: For a local file name in a remote python shell, we
cannot simply distinguish whether it is a file on the remote system or
a local file (i.e. sending code from local host), although the former
is more likely. So we need file-exists-p for verification.
Moreover, if file doesn't exist (e.g. the original file may be
deleted), it makes no sense to create an empty buffer/file, because we
don't want to edit it, but to debug the code in it.
The attached patch fixes the original bug and another one of pdbtrack
(described earlier). It also adds a check in case
python-pdbtrack-set-tracked-buffer cannot find file.
[0001-Fix-pdb-tracking-bug-79036.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Fri, 18 Jul 2025 12:09:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 79036 <at> debbugs.gnu.org (full text, mbox):
> From: Liu Hui <liuhui1610 <at> gmail.com>
> Date: Fri, 18 Jul 2025 12:47:07 +0800
> Cc: michael.albinus <at> gmx.de, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
>
> > If we did have such a function, wouldn't it be enough to just call
> >
> > (find-file-noselect (remote-file-name file-name))
> >
> > ? That is, we won't need to call get-file-buffer, nor file-exists-p,
> > right? Or am I still missing something?
>
> They are still needed because python-pdbtrack-set-tracked-buffer is
> not just used to visit file-name.
>
> If the file-buffer already exists, which uses get-file-buffer for
> checking, we don't kill it when pdb finishes. Otherwise, the
> file-buffer will be created by find-file-noselect and added to
> python-pdbtrack-buffers-to-kill.
This could be handled by other means. For example, use
buffer-list-update-hook. Or you could use get-file-buffer first and
_then_ call find-file-noselect unconditionally; it would still be
cleaner, IMO.
> file-exists-p: For a local file name in a remote python shell, we
> cannot simply distinguish whether it is a file on the remote system or
> a local file (i.e. sending code from local host), although the former
> is more likely. So we need file-exists-p for verification.
Sorry, I don't understand the problem and its solution. What do you
mean by "local file name in a remote python shell"?
> Moreover, if file doesn't exist (e.g. the original file may be
> deleted), it makes no sense to create an empty buffer/file, because we
> don't want to edit it, but to debug the code in it.
This can be handled by other means. But again, I don't understand why
is this important, so please elaborate.
> The attached patch fixes the original bug and another one of pdbtrack
> (described earlier). It also adds a check in case
> python-pdbtrack-set-tracked-buffer cannot find file.
Thanks, but let's first finish the discussion about all those
precautions instead of just calling find-file-noselect.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Fri, 18 Jul 2025 14:08:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 79036 <at> debbugs.gnu.org (full text, mbox):
On Fri, Jul 18, 2025 at 8:08 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Liu Hui <liuhui1610 <at> gmail.com>
> > Date: Fri, 18 Jul 2025 12:47:07 +0800
> > Cc: michael.albinus <at> gmx.de, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
> >
> > > If we did have such a function, wouldn't it be enough to just call
> > >
> > > (find-file-noselect (remote-file-name file-name))
> > >
> > > ? That is, we won't need to call get-file-buffer, nor file-exists-p,
> > > right? Or am I still missing something?
> >
> > They are still needed because python-pdbtrack-set-tracked-buffer is
> > not just used to visit file-name.
> >
> > If the file-buffer already exists, which uses get-file-buffer for
> > checking, we don't kill it when pdb finishes. Otherwise, the
> > file-buffer will be created by find-file-noselect and added to
> > python-pdbtrack-buffers-to-kill.
>
> This could be handled by other means. For example, use
> buffer-list-update-hook. Or you could use get-file-buffer first and
> _then_ call find-file-noselect unconditionally; it would still be
> cleaner, IMO.
>
> > file-exists-p: For a local file name in a remote python shell, we
> > cannot simply distinguish whether it is a file on the remote system or
> > a local file (i.e. sending code from local host), although the former
> > is more likely. So we need file-exists-p for verification.
>
> Sorry, I don't understand the problem and its solution. What do you
> mean by "local file name in a remote python shell"?
For example, below is the pdb output in a remote python shell, and the
file-name "/tmp/test.py" is local. Because of the "from ... import
...", we can know the file is on the remote system.
>>> from test import f; f()
> /tmp/test.py(3)f()
-> return 1
(Pdb)
However, with the following pdb output in a remote python shell
>>> f()
> /tmp/test.py(3)f()
-> return 1
(Pdb)
The local filename "/tmp/test.py" may be on the remote system like the
above case, or may be on the local host if we press C-c C-c to send
its code to the remote process.
Which file should python shell track? The simplest solution is to
check which file exists.
> > Moreover, if file doesn't exist (e.g. the original file may be
> > deleted), it makes no sense to create an empty buffer/file, because we
> > don't want to edit it, but to debug the code in it.
>
> This can be handled by other means. But again, I don't understand why
> is this important, so please elaborate.
I was explaining why file-exists-p is needed. It is another possible
case.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Fri, 18 Jul 2025 14:14:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 79036 <at> debbugs.gnu.org (full text, mbox):
Liu Hui <liuhui1610 <at> gmail.com> writes:
> For example, below is the pdb output in a remote python shell, and the
> file-name "/tmp/test.py" is local. Because of the "from ... import
> ...", we can know the file is on the remote system.
>
> >>> from test import f; f()
> > /tmp/test.py(3)f()
> -> return 1
> (Pdb)
>
> However, with the following pdb output in a remote python shell
>
> >>> f()
> > /tmp/test.py(3)f()
> -> return 1
> (Pdb)
>
> The local filename "/tmp/test.py" may be on the remote system like the
> above case, or may be on the local host if we press C-c C-c to send
> its code to the remote process.
>
> Which file should python shell track? The simplest solution is to
> check which file exists.
No. The mature check is whether default-directory is remote. Everything
else is voodoo. Can work, but no guarantee.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Fri, 18 Jul 2025 14:54:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 79036 <at> debbugs.gnu.org (full text, mbox):
> From: Liu Hui <liuhui1610 <at> gmail.com>
> Date: Fri, 18 Jul 2025 22:06:56 +0800
> Cc: michael.albinus <at> gmx.de, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
>
> On Fri, Jul 18, 2025 at 8:08 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > > file-exists-p: For a local file name in a remote python shell, we
> > > cannot simply distinguish whether it is a file on the remote system or
> > > a local file (i.e. sending code from local host), although the former
> > > is more likely. So we need file-exists-p for verification.
> >
> > Sorry, I don't understand the problem and its solution. What do you
> > mean by "local file name in a remote python shell"?
>
> For example, below is the pdb output in a remote python shell, and the
> file-name "/tmp/test.py" is local. Because of the "from ... import
> ...", we can know the file is on the remote system.
>
> >>> from test import f; f()
> > /tmp/test.py(3)f()
> -> return 1
> (Pdb)
>
> However, with the following pdb output in a remote python shell
>
> >>> f()
> > /tmp/test.py(3)f()
> -> return 1
> (Pdb)
>
> The local filename "/tmp/test.py" may be on the remote system like the
> above case, or may be on the local host if we press C-c C-c to send
> its code to the remote process.
>
> Which file should python shell track? The simplest solution is to
> check which file exists.
Doesn't the value of default-directory tells us whether it's a local
or a remote file? If not, why not?
> > > Moreover, if file doesn't exist (e.g. the original file may be
> > > deleted), it makes no sense to create an empty buffer/file, because we
> > > don't want to edit it, but to debug the code in it.
> >
> > This can be handled by other means. But again, I don't understand why
> > is this important, so please elaborate.
>
> I was explaining why file-exists-p is needed. It is another possible
> case.
If a file doesn't exist, debugging it will not work. The fact that we
leave behind an empty buffer is not important.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Fri, 18 Jul 2025 14:55:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 79036 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
> Date: Fri, 18 Jul 2025 16:13:00 +0200
>
> Liu Hui <liuhui1610 <at> gmail.com> writes:
>
> > For example, below is the pdb output in a remote python shell, and the
> > file-name "/tmp/test.py" is local. Because of the "from ... import
> > ...", we can know the file is on the remote system.
> >
> > >>> from test import f; f()
> > > /tmp/test.py(3)f()
> > -> return 1
> > (Pdb)
> >
> > However, with the following pdb output in a remote python shell
> >
> > >>> f()
> > > /tmp/test.py(3)f()
> > -> return 1
> > (Pdb)
> >
> > The local filename "/tmp/test.py" may be on the remote system like the
> > above case, or may be on the local host if we press C-c C-c to send
> > its code to the remote process.
> >
> > Which file should python shell track? The simplest solution is to
> > check which file exists.
>
> No. The mature check is whether default-directory is remote. Everything
> else is voodoo. Can work, but no guarantee.
Right.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Fri, 18 Jul 2025 15:21:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 79036 <at> debbugs.gnu.org (full text, mbox):
On Fri, Jul 18, 2025 at 10:53 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Michael Albinus <michael.albinus <at> gmx.de>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
> > Date: Fri, 18 Jul 2025 16:13:00 +0200
> >
> > Liu Hui <liuhui1610 <at> gmail.com> writes:
> >
> > > For example, below is the pdb output in a remote python shell, and the
> > > file-name "/tmp/test.py" is local. Because of the "from ... import
> > > ...", we can know the file is on the remote system.
> > >
> > > >>> from test import f; f()
> > > > /tmp/test.py(3)f()
> > > -> return 1
> > > (Pdb)
> > >
> > > However, with the following pdb output in a remote python shell
> > >
> > > >>> f()
> > > > /tmp/test.py(3)f()
> > > -> return 1
> > > (Pdb)
> > >
> > > The local filename "/tmp/test.py" may be on the remote system like the
> > > above case, or may be on the local host if we press C-c C-c to send
> > > its code to the remote process.
> > >
> > > Which file should python shell track? The simplest solution is to
> > > check which file exists.
> >
> > No. The mature check is whether default-directory is remote. Everything
> > else is voodoo. Can work, but no guarantee.
>
> Right.
I agree Emacs should first find the file on the remote system when the
python shell is remote. But if the file doesn't exist, I think it is
reasonable to try finding local file (supposed behavior currently in
python-pdbtrack-set-tracked-buffer but there is a bug) instead of
opening an empty remote file (actual behavior) or doing nothing. I
would like to add an option if you think Emacs should just find the
remote file.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Fri, 18 Jul 2025 15:32:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 79036 <at> debbugs.gnu.org (full text, mbox):
> From: Liu Hui <liuhui1610 <at> gmail.com>
> Date: Fri, 18 Jul 2025 23:19:49 +0800
> Cc: Michael Albinus <michael.albinus <at> gmx.de>, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
>
> On Fri, Jul 18, 2025 at 10:53 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > > From: Michael Albinus <michael.albinus <at> gmx.de>
> > > Cc: Eli Zaretskii <eliz <at> gnu.org>, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
> > > Date: Fri, 18 Jul 2025 16:13:00 +0200
> > >
> > > Liu Hui <liuhui1610 <at> gmail.com> writes:
> > >
> > > > For example, below is the pdb output in a remote python shell, and the
> > > > file-name "/tmp/test.py" is local. Because of the "from ... import
> > > > ...", we can know the file is on the remote system.
> > > >
> > > > >>> from test import f; f()
> > > > > /tmp/test.py(3)f()
> > > > -> return 1
> > > > (Pdb)
> > > >
> > > > However, with the following pdb output in a remote python shell
> > > >
> > > > >>> f()
> > > > > /tmp/test.py(3)f()
> > > > -> return 1
> > > > (Pdb)
> > > >
> > > > The local filename "/tmp/test.py" may be on the remote system like the
> > > > above case, or may be on the local host if we press C-c C-c to send
> > > > its code to the remote process.
> > > >
> > > > Which file should python shell track? The simplest solution is to
> > > > check which file exists.
> > >
> > > No. The mature check is whether default-directory is remote. Everything
> > > else is voodoo. Can work, but no guarantee.
> >
> > Right.
>
> I agree Emacs should first find the file on the remote system when the
> python shell is remote. But if the file doesn't exist, I think it is
> reasonable to try finding local file (supposed behavior currently in
> python-pdbtrack-set-tracked-buffer but there is a bug) instead of
> opening an empty remote file (actual behavior) or doing nothing. I
> would like to add an option if you think Emacs should just find the
> remote file.
If we decide that the file is local, the value of default-directory
should reflect that. Then all our infrastructure for handling files
will seamlessly work correctly.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Fri, 18 Jul 2025 15:33:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 79036 <at> debbugs.gnu.org (full text, mbox):
On Fri, Jul 18, 2025 at 10:52 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Liu Hui <liuhui1610 <at> gmail.com>
> > Date: Fri, 18 Jul 2025 22:06:56 +0800
> > Cc: michael.albinus <at> gmx.de, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
> >
> > On Fri, Jul 18, 2025 at 8:08 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > >
> > > > file-exists-p: For a local file name in a remote python shell, we
> > > > cannot simply distinguish whether it is a file on the remote system or
> > > > a local file (i.e. sending code from local host), although the former
> > > > is more likely. So we need file-exists-p for verification.
> > >
> > > Sorry, I don't understand the problem and its solution. What do you
> > > mean by "local file name in a remote python shell"?
> >
> > For example, below is the pdb output in a remote python shell, and the
> > file-name "/tmp/test.py" is local. Because of the "from ... import
> > ...", we can know the file is on the remote system.
> >
> > >>> from test import f; f()
> > > /tmp/test.py(3)f()
> > -> return 1
> > (Pdb)
> >
> > However, with the following pdb output in a remote python shell
> >
> > >>> f()
> > > /tmp/test.py(3)f()
> > -> return 1
> > (Pdb)
> >
> > The local filename "/tmp/test.py" may be on the remote system like the
> > above case, or may be on the local host if we press C-c C-c to send
> > its code to the remote process.
> >
> > Which file should python shell track? The simplest solution is to
> > check which file exists.
>
> Doesn't the value of default-directory tells us whether it's a local
> or a remote file? If not, why not?
In the example:
>>> f()
> /tmp/test.py(3)f()
-> return 1
(Pdb)
The current buffer is the Python shell buffer, default-directory is
remote only means
python process is remote. "/tmp/test.py" may be on the local host because users
may send code in local file "/tmp/test.py" to the remote process.
> > > > Moreover, if file doesn't exist (e.g. the original file may be
> > > > deleted), it makes no sense to create an empty buffer/file, because we
> > > > don't want to edit it, but to debug the code in it.
> > >
> > > This can be handled by other means. But again, I don't understand why
> > > is this important, so please elaborate.
> >
> > I was explaining why file-exists-p is needed. It is another possible
> > case.
>
> If a file doesn't exist, debugging it will not work. The fact that we
> leave behind an empty buffer is not important.
Since an empty buffer is useless, why not just not show it in the
first place? I find it disturbing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Fri, 18 Jul 2025 18:26:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 79036 <at> debbugs.gnu.org (full text, mbox):
> From: Liu Hui <liuhui1610 <at> gmail.com>
> Date: Fri, 18 Jul 2025 23:31:50 +0800
> Cc: michael.albinus <at> gmx.de, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
>
> On Fri, Jul 18, 2025 at 10:52 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > > From: Liu Hui <liuhui1610 <at> gmail.com>
> > > Date: Fri, 18 Jul 2025 22:06:56 +0800
> > > Cc: michael.albinus <at> gmx.de, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
> > >
> > > On Fri, Jul 18, 2025 at 8:08 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > >
> > > > > file-exists-p: For a local file name in a remote python shell, we
> > > > > cannot simply distinguish whether it is a file on the remote system or
> > > > > a local file (i.e. sending code from local host), although the former
> > > > > is more likely. So we need file-exists-p for verification.
> > > >
> > > > Sorry, I don't understand the problem and its solution. What do you
> > > > mean by "local file name in a remote python shell"?
> > >
> > > For example, below is the pdb output in a remote python shell, and the
> > > file-name "/tmp/test.py" is local. Because of the "from ... import
> > > ...", we can know the file is on the remote system.
> > >
> > > >>> from test import f; f()
> > > > /tmp/test.py(3)f()
> > > -> return 1
> > > (Pdb)
> > >
> > > However, with the following pdb output in a remote python shell
> > >
> > > >>> f()
> > > > /tmp/test.py(3)f()
> > > -> return 1
> > > (Pdb)
> > >
> > > The local filename "/tmp/test.py" may be on the remote system like the
> > > above case, or may be on the local host if we press C-c C-c to send
> > > its code to the remote process.
> > >
> > > Which file should python shell track? The simplest solution is to
> > > check which file exists.
> >
> > Doesn't the value of default-directory tells us whether it's a local
> > or a remote file? If not, why not?
>
> In the example:
>
> >>> f()
> > /tmp/test.py(3)f()
> -> return 1
> (Pdb)
>
> The current buffer is the Python shell buffer, default-directory is
> remote only means
> python process is remote. "/tmp/test.py" may be on the local host because users
> may send code in local file "/tmp/test.py" to the remote process.
This cannot work reliably, and I don't think we should support it.
Please ignore this case in the following discussions.
> > > > > Moreover, if file doesn't exist (e.g. the original file may be
> > > > > deleted), it makes no sense to create an empty buffer/file, because we
> > > > > don't want to edit it, but to debug the code in it.
> > > >
> > > > This can be handled by other means. But again, I don't understand why
> > > > is this important, so please elaborate.
> > >
> > > I was explaining why file-exists-p is needed. It is another possible
> > > case.
> >
> > If a file doesn't exist, debugging it will not work. The fact that we
> > leave behind an empty buffer is not important.
>
> Since an empty buffer is useless, why not just not show it in the
> first place? I find it disturbing.
Because it complicates the code for no good reason.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Sat, 19 Jul 2025 00:44:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 79036 <at> debbugs.gnu.org (full text, mbox):
On Fri, Jul 18, 2025 at 11:31 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Liu Hui <liuhui1610 <at> gmail.com>
> > Date: Fri, 18 Jul 2025 23:19:49 +0800
> > Cc: Michael Albinus <michael.albinus <at> gmx.de>, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
> >
> > On Fri, Jul 18, 2025 at 10:53 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > >
> > > > From: Michael Albinus <michael.albinus <at> gmx.de>
> > > > Cc: Eli Zaretskii <eliz <at> gnu.org>, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
> > > > Date: Fri, 18 Jul 2025 16:13:00 +0200
> > > >
> > > > Liu Hui <liuhui1610 <at> gmail.com> writes:
> > > >
> > > > > For example, below is the pdb output in a remote python shell, and the
> > > > > file-name "/tmp/test.py" is local. Because of the "from ... import
> > > > > ...", we can know the file is on the remote system.
> > > > >
> > > > > >>> from test import f; f()
> > > > > > /tmp/test.py(3)f()
> > > > > -> return 1
> > > > > (Pdb)
> > > > >
> > > > > However, with the following pdb output in a remote python shell
> > > > >
> > > > > >>> f()
> > > > > > /tmp/test.py(3)f()
> > > > > -> return 1
> > > > > (Pdb)
> > > > >
> > > > > The local filename "/tmp/test.py" may be on the remote system like the
> > > > > above case, or may be on the local host if we press C-c C-c to send
> > > > > its code to the remote process.
> > > > >
> > > > > Which file should python shell track? The simplest solution is to
> > > > > check which file exists.
> > > >
> > > > No. The mature check is whether default-directory is remote. Everything
> > > > else is voodoo. Can work, but no guarantee.
> > >
> > > Right.
> >
> > I agree Emacs should first find the file on the remote system when the
> > python shell is remote. But if the file doesn't exist, I think it is
> > reasonable to try finding local file (supposed behavior currently in
> > python-pdbtrack-set-tracked-buffer but there is a bug) instead of
> > opening an empty remote file (actual behavior) or doing nothing. I
> > would like to add an option if you think Emacs should just find the
> > remote file.
>
> If we decide that the file is local, the value of default-directory
> should reflect that. Then all our infrastructure for handling files
> will seamlessly work correctly.
The discussion remind me of that in bug#78925.
When ffap find a local file name in buffers with remote default
directory, both you and Michael agree Emacs first finds the file in
local host by default.
In this thread, when pdbtrack find a local file name in the remote
buffer, both you and Michael agree Emacs should find the file name
according to the default-directory.
Should Emacs set the default value of ffap-prefer-remote-file to t for
consistency?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Sat, 19 Jul 2025 06:27:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 79036 <at> debbugs.gnu.org (full text, mbox):
> From: Liu Hui <liuhui1610 <at> gmail.com>
> Date: Sat, 19 Jul 2025 08:43:28 +0800
> Cc: michael.albinus <at> gmx.de, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
>
> On Fri, Jul 18, 2025 at 11:31 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > > From: Liu Hui <liuhui1610 <at> gmail.com>
> > > Date: Fri, 18 Jul 2025 23:19:49 +0800
> > > Cc: Michael Albinus <michael.albinus <at> gmx.de>, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
> > >
> > > On Fri, Jul 18, 2025 at 10:53 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > >
> > > > > From: Michael Albinus <michael.albinus <at> gmx.de>
> > > > > Cc: Eli Zaretskii <eliz <at> gnu.org>, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
> > > > > Date: Fri, 18 Jul 2025 16:13:00 +0200
> > > > >
> > > > > Liu Hui <liuhui1610 <at> gmail.com> writes:
> > > > >
> > > > > > For example, below is the pdb output in a remote python shell, and the
> > > > > > file-name "/tmp/test.py" is local. Because of the "from ... import
> > > > > > ...", we can know the file is on the remote system.
> > > > > >
> > > > > > >>> from test import f; f()
> > > > > > > /tmp/test.py(3)f()
> > > > > > -> return 1
> > > > > > (Pdb)
> > > > > >
> > > > > > However, with the following pdb output in a remote python shell
> > > > > >
> > > > > > >>> f()
> > > > > > > /tmp/test.py(3)f()
> > > > > > -> return 1
> > > > > > (Pdb)
> > > > > >
> > > > > > The local filename "/tmp/test.py" may be on the remote system like the
> > > > > > above case, or may be on the local host if we press C-c C-c to send
> > > > > > its code to the remote process.
> > > > > >
> > > > > > Which file should python shell track? The simplest solution is to
> > > > > > check which file exists.
> > > > >
> > > > > No. The mature check is whether default-directory is remote. Everything
> > > > > else is voodoo. Can work, but no guarantee.
> > > >
> > > > Right.
> > >
> > > I agree Emacs should first find the file on the remote system when the
> > > python shell is remote. But if the file doesn't exist, I think it is
> > > reasonable to try finding local file (supposed behavior currently in
> > > python-pdbtrack-set-tracked-buffer but there is a bug) instead of
> > > opening an empty remote file (actual behavior) or doing nothing. I
> > > would like to add an option if you think Emacs should just find the
> > > remote file.
> >
> > If we decide that the file is local, the value of default-directory
> > should reflect that. Then all our infrastructure for handling files
> > will seamlessly work correctly.
>
> The discussion remind me of that in bug#78925.
>
> When ffap find a local file name in buffers with remote default
> directory, both you and Michael agree Emacs first finds the file in
> local host by default.
>
> In this thread, when pdbtrack find a local file name in the remote
> buffer, both you and Michael agree Emacs should find the file name
> according to the default-directory.
>
> Should Emacs set the default value of ffap-prefer-remote-file to t for
> consistency?
ffap-prefer-remote-file is a new option, and we are generally default
those to values that preserve past behavior.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Mon, 21 Jul 2025 16:02:03 GMT)
Full text and
rfc822 format available.
Message #104 received at 79036 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii wrote:
>
> > From: Liu Hui <liuhui1610 <at> gmail.com>
> > Date: Fri, 18 Jul 2025 23:31:50 +0800
> > Cc: michael.albinus <at> gmx.de, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
> >
> > On Fri, Jul 18, 2025 at 10:52 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > >
> > > > From: Liu Hui <liuhui1610 <at> gmail.com>
> > > > Date: Fri, 18 Jul 2025 22:06:56 +0800
> > > > Cc: michael.albinus <at> gmx.de, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
> > > >
> > > > On Fri, Jul 18, 2025 at 8:08 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > > >
> > > > > > file-exists-p: For a local file name in a remote python shell, we
> > > > > > cannot simply distinguish whether it is a file on the remote system or
> > > > > > a local file (i.e. sending code from local host), although the former
> > > > > > is more likely. So we need file-exists-p for verification.
> > > > >
> > > > > Sorry, I don't understand the problem and its solution. What do you
> > > > > mean by "local file name in a remote python shell"?
> > > >
> > > > For example, below is the pdb output in a remote python shell, and the
> > > > file-name "/tmp/test.py" is local. Because of the "from ... import
> > > > ...", we can know the file is on the remote system.
> > > >
> > > > >>> from test import f; f()
> > > > > /tmp/test.py(3)f()
> > > > -> return 1
> > > > (Pdb)
> > > >
> > > > However, with the following pdb output in a remote python shell
> > > >
> > > > >>> f()
> > > > > /tmp/test.py(3)f()
> > > > -> return 1
> > > > (Pdb)
> > > >
> > > > The local filename "/tmp/test.py" may be on the remote system like the
> > > > above case, or may be on the local host if we press C-c C-c to send
> > > > its code to the remote process.
> > > >
> > > > Which file should python shell track? The simplest solution is to
> > > > check which file exists.
> > >
> > > Doesn't the value of default-directory tells us whether it's a local
> > > or a remote file? If not, why not?
> >
> > In the example:
> >
> > >>> f()
> > > /tmp/test.py(3)f()
> > -> return 1
> > (Pdb)
> >
> > The current buffer is the Python shell buffer, default-directory is
> > remote only means
> > python process is remote. "/tmp/test.py" may be on the local host because users
> > may send code in local file "/tmp/test.py" to the remote process.
>
> This cannot work reliably, and I don't think we should support it.
> Please ignore this case in the following discussions.
I agree that this method does not work reliably. However, I think we
can take another approach.
First, let me explain the problem. The inferior Python process is
invoked on the remote host if the Python file buffer is remote. There
are two buffers, both remote.
1. Python file buffer.
2. Inferior Python buffer.
By default, the inferior Python buffer is shared among Python files.
So if we open another local Python file, it uses the above remote
inferior Python buffer. When we send the contents of the local file
using C-c C-c to the inferior Python buffer, the local file name such
as "/tmp/test.py" is passed. This results in the above problem.
I think the file name without any prefix such as "/tmp/test.py" should
be used when and only when the inferior Python process can handle it.
When sending the local "/tmp/test.py" to the remote Python process,
passing the file name "/tmp/test.py" is useless because there is no
guarantee that the same "/tmp/test.py" exists on the remote host.
Instead, I think it would be better to pass the file name with the
prefix indicating that the file is local. The inferior Python process
(PDB) itself still cannot handle that file name, but the PDB tracking
feature can take advantage of it.
If TRAMP supports a method such as "/local:" to access local files, we
can use it. As TRAMP does not seem to have such a thing, I use
"/ssh::" instead. The real "/ssh::" requires an SSH server to be
running on the local host, but I'm just using it as a pseudo prefix to
distinguish local files from remote files. i.e. SSH server is not
required on local host.
The case of multiple remote hosts should also be considered. In
summary, it seems to me that it would be a good idea to pass the file
names as shown in the following table.
| | Local Python | Python on remote1 |
|-------------------+---------------------+---------------------|
| Local tmp.py | tmp.py | /ssh::tmp.py |
| tmp.py on remote1 | /ssh:remote1:tmp.py | tmp.py |
| tmp.py on remote2 | /ssh:remote2:tmp.py | /ssh:remote2:tmp.py |
Local Python cases are already covered with current python.el.
Attached is a PoC-level patch to support Remote Python cases.
What do you think of this approach?
[79036.diff (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Mon, 21 Jul 2025 17:48:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 79036 <at> debbugs.gnu.org (full text, mbox):
kobarity <kobarity <at> gmail.com> writes:
Hi,
> If TRAMP supports a method such as "/local:" to access local files, we
> can use it. As TRAMP does not seem to have such a thing, I use
> "/ssh::" instead. The real "/ssh::" requires an SSH server to be
> running on the local host, but I'm just using it as a pseudo prefix to
> distinguish local files from remote files. i.e. SSH server is not
> required on local host.
FTR, Tramp knows a method "local". It is used for internal purposes; I
don't know whether it is worth to expose it to the outer world.
Eshell has a similar problem. It must know, whether a command runs on
the local host, or on the remote host as determined by
default-directory. It uses the "/local:" prefix to force commands for
the local host, even if they would run on the remote host
otherwise. Perhaps you can adapt this approach to your needs.
See (info "(eshell) Remote Access")
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Tue, 22 Jul 2025 10:15:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 79036 <at> debbugs.gnu.org (full text, mbox):
On Tue, Jul 22, 2025 at 12:01 AM kobarity <kobarity <at> gmail.com> wrote:
> The case of multiple remote hosts should also be considered. In
> summary, it seems to me that it would be a good idea to pass the file
> names as shown in the following table.
>
> | | Local Python | Python on remote1 |
> |-------------------+---------------------+---------------------|
> | Local tmp.py | tmp.py | /ssh::tmp.py |
> | tmp.py on remote1 | /ssh:remote1:tmp.py | tmp.py |
> | tmp.py on remote2 | /ssh:remote2:tmp.py | /ssh:remote2:tmp.py |
>
> Local Python cases are already covered with current python.el.
> Attached is a PoC-level patch to support Remote Python cases.
>
> What do you think of this approach?
Hi,
I think it is better since it explicitly identifies the source of
code. Then there is no confusion and file-exists-p is not needed in
python-pdbtrack-set-tracked-buffer.
> +(defun python-shell--file-name-to-send (process)
> + "Return the file name to send to inferior Python PROCESS."
> + (let ((file-name (buffer-file-name))
> + (process-prefix
> + (file-remote-p
> + (with-current-buffer (process-buffer process) default-directory))))
> + (if file-name
> + (if process-prefix
> + (let ((remote-p (file-remote-p file-name))
> + (local-name (file-local-name file-name)))
> + (if remote-p
> + (if (string= remote-p process-prefix)
> + local-name
> + file-name)
> + (concat python-shell-local-prefix local-name)))
> + file-name)
> + "<string>")))
For non-file buffers, could it return buffer name instead of <string>?
e.g. #<buffer NAME> or #<NAME> where NAME may need to be quoted. Then
python-pdbtrack-set-tracked-buffer can find it by (get-buffer-create
"NAME").
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Tue, 22 Jul 2025 11:42:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 79036 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Jul 2025 01:01:26 +0900
> From: kobarity <kobarity <at> gmail.com>
> Cc: 79036 <at> debbugs.gnu.org
>
> First, let me explain the problem. The inferior Python process is
> invoked on the remote host if the Python file buffer is remote. There
> are two buffers, both remote.
>
> 1. Python file buffer.
> 2. Inferior Python buffer.
>
> By default, the inferior Python buffer is shared among Python files.
> So if we open another local Python file, it uses the above remote
> inferior Python buffer. When we send the contents of the local file
> using C-c C-c to the inferior Python buffer, the local file name such
> as "/tmp/test.py" is passed. This results in the above problem.
I thought the problem was the opposite one: a file name such as
"/tmp/test.py" in an inferior Python buffer refers to the file on the
same host as the default-directory of the inferior Python buffer.
Thus, if default-directory of the inferior Python buffer is on a
remote host, the file "/tmp/test.py" there refers to a remote file,
although its form is as that of a local file.
You are describing an almost opposite problem.
> If TRAMP supports a method such as "/local:" to access local files, we
> can use it.
We could use it, but I still don't see how this would solve the
problem(s) discussed here. Please elaborate.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Wed, 23 Jul 2025 15:09:01 GMT)
Full text and
rfc822 format available.
Message #116 received at 79036 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
Michael Albinus wrote:
> FTR, Tramp knows a method "local". It is used for internal purposes; I
> don't know whether it is worth to expose it to the outer world.
>
> Eshell has a similar problem. It must know, whether a command runs on
> the local host, or on the remote host as determined by
> default-directory. It uses the "/local:" prefix to force commands for
> the local host, even if they would run on the remote host
> otherwise. Perhaps you can adapt this approach to your needs.
>
> See (info "(eshell) Remote Access")
Thanks! I updated my patch using "/local:".
Liu Hui wrote:
> For non-file buffers, could it return buffer name instead of <string>?
> e.g. #<buffer NAME> or #<NAME> where NAME may need to be quoted. Then
> python-pdbtrack-set-tracked-buffer can find it by (get-buffer-create
> "NAME").
That might be a good idea. Why is `get-buffer-create' is necessary
rather than `get-buffer'?
Eli Zaretskii wrote:
>
> > Date: Tue, 22 Jul 2025 01:01:26 +0900
> > From: kobarity <kobarity <at> gmail.com>
> > Cc: 79036 <at> debbugs.gnu.org
> >
> > First, let me explain the problem. The inferior Python process is
> > invoked on the remote host if the Python file buffer is remote. There
> > are two buffers, both remote.
> >
> > 1. Python file buffer.
> > 2. Inferior Python buffer.
> >
> > By default, the inferior Python buffer is shared among Python files.
> > So if we open another local Python file, it uses the above remote
> > inferior Python buffer. When we send the contents of the local file
> > using C-c C-c to the inferior Python buffer, the local file name such
> > as "/tmp/test.py" is passed. This results in the above problem.
>
> I thought the problem was the opposite one: a file name such as
> "/tmp/test.py" in an inferior Python buffer refers to the file on the
> same host as the default-directory of the inferior Python buffer.
> Thus, if default-directory of the inferior Python buffer is on a
> remote host, the file "/tmp/test.py" there refers to a remote file,
> although its form is as that of a local file.
You are correct, but I do not believe that this behavior itself is the
problem. For example, this happens when executing "from test import
f" in the remote Python buffer.
The problem is that the same file name "/tmp/test.py" is used when
sending a local file using `python-shell-send-buffer' (C-c C-c). I
will explain it later.
> You are describing an almost opposite problem.
>
> > If TRAMP supports a method such as "/local:" to access local files, we
> > can use it.
>
> We could use it, but I still don't see how this would solve the
> problem(s) discussed here. Please elaborate.
`python-shell-send-buffer' (C-c C-c) does not actually send files. It
only sends the contents of the buffer and the associated file name to
the Inferior Python process. For example, when sending "/tmp/test.py"
to the remote Python process, "test.py" file is not created on the
remote host at all. The Python process evaluates the sent contents
and build Python objects such as functions. The file name is only
used in this evaluation and embedded in the Python objects. We can
see it as follows.
>>> f.__code__.co_filename
'/tmp/test.py'
PDB uses this information to show the file name and the line number
where it breaks. If the file is accessible, PDB also shows the
contents of the line of the file.
PDB tracking feature of python.el parses the output of PDB and tries
to show the corresponding file.
Thus, TRAMP filenames such as "/ssh:remote1:/tmp/test.py" or
"/local:/tmp/test.py" is useless for PDB but helpful for PDB tracking.
This file name is used only for this purpose, and has nothing to do
with Emacs's buffer/file management.
The current behavior and my proposal for sending the file name to
remote Python (on remote1) are summarized in the following table.
| | Current | My proposal |
|-------------------------+---------------------------+---------------------------|
| Local /tmp/test.py | /tmp/test.py | /local:/tmp/test.py |
| /tmp/test.py on remote1 | /ssh:remote1:/tmp/test.py | /tmp/test.py |
| /tmp/test.py on remote2 | /ssh:remote2:/tmp/test.py | /ssh:remote2:/tmp/test.py |
There are two problems with the current behavior.
1. Using "/tmp/test.py" when sending local file is wrong, because that
path may not exist on the remote, or the contents may be completely
different. It is possible that PDB shows the wrong line if
"/tmp/test.py" exists on the remote but the contents is different.
2. Using "/ssh:remote1:/tmp/test.py" when sending remote file contents
to the same remote host is OK for PDB tracking, but makes it
impossible for PDB to show the contents of the line while the file
exists on the remote host and PDB can access it.
[79036.diff (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Wed, 23 Jul 2025 16:03:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 79036 <at> debbugs.gnu.org (full text, mbox):
kobarity <kobarity <at> gmail.com> writes:
> Hi,
Hi,
> Thus, TRAMP filenames such as "/ssh:remote1:/tmp/test.py" or
> "/local:/tmp/test.py" is useless for PDB but helpful for PDB tracking.
JFTR: "/local:/tmp/test.py" is NOT a Tramp file name. It uses just the
prefix "/local:" for internal purposes.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Thu, 24 Jul 2025 00:47:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 79036 <at> debbugs.gnu.org (full text, mbox):
On Wed, Jul 23, 2025 at 11:08 PM kobarity <kobarity <at> gmail.com> wrote:
> > For non-file buffers, could it return buffer name instead of <string>?
> > e.g. #<buffer NAME> or #<NAME> where NAME may need to be quoted. Then
> > python-pdbtrack-set-tracked-buffer can find it by (get-buffer-create
> > "NAME").
>
> That might be a good idea. Why is `get-buffer-create' is necessary
> rather than `get-buffer'?
Thanks for pointing it out. get-buffer should be used here.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Sat, 02 Aug 2025 14:02:03 GMT)
Full text and
rfc822 format available.
Message #125 received at 79036 <at> debbugs.gnu.org (full text, mbox):
> From: Liu Hui <liuhui1610 <at> gmail.com>
> Date: Thu, 24 Jul 2025 08:45:54 +0800
> Cc: Eli Zaretskii <eliz <at> gnu.org>, michael.albinus <at> gmx.de, 79036 <at> debbugs.gnu.org
>
> On Wed, Jul 23, 2025 at 11:08 PM kobarity <kobarity <at> gmail.com> wrote:
>
> > > For non-file buffers, could it return buffer name instead of <string>?
> > > e.g. #<buffer NAME> or #<NAME> where NAME may need to be quoted. Then
> > > python-pdbtrack-set-tracked-buffer can find it by (get-buffer-create
> > > "NAME").
> >
> > That might be a good idea. Why is `get-buffer-create' is necessary
> > rather than `get-buffer'?
>
> Thanks for pointing it out. get-buffer should be used here.
So can we please have an updated patch for this?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Sun, 03 Aug 2025 11:48:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 79036 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Michael Albinus wrote:
> kobarity <kobarity <at> gmail.com> writes:
> > Thus, TRAMP filenames such as "/ssh:remote1:/tmp/test.py" or
> > "/local:/tmp/test.py" is useless for PDB but helpful for PDB tracking.
>
> JFTR: "/local:/tmp/test.py" is NOT a Tramp file name. It uses just the
> prefix "/local:" for internal purposes.
Understood. I revised the patch to perform checking and removing
the prefix "/local:" first.
Eli Zaretskii wrote:
>
> > From: Liu Hui <liuhui1610 <at> gmail.com>
> > Date: Thu, 24 Jul 2025 08:45:54 +0800
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, michael.albinus <at> gmx.de, 79036 <at> debbugs.gnu.org
> >
> > On Wed, Jul 23, 2025 at 11:08 PM kobarity <kobarity <at> gmail.com> wrote:
> >
> > > > For non-file buffers, could it return buffer name instead of <string>?
> > > > e.g. #<buffer NAME> or #<NAME> where NAME may need to be quoted. Then
> > > > python-pdbtrack-set-tracked-buffer can find it by (get-buffer-create
> > > > "NAME").
> > >
> > > That might be a good idea. Why is `get-buffer-create' is necessary
> > > rather than `get-buffer'?
> >
> > Thanks for pointing it out. get-buffer should be used here.
>
> So can we please have an updated patch for this?
Since it is an improvement to add a new feature and not a fix for
#79036, I think it would be better to separate the patches.
Attached is my proposed patch to fix #79036.
[0001-Fix-Python-PDB-tracking-for-remote-inferior-Python.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Mon, 04 Aug 2025 11:53:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 79036 <at> debbugs.gnu.org (full text, mbox):
On Sun, Aug 3, 2025 at 7:47 PM kobarity <kobarity <at> gmail.com> wrote:
> Eli Zaretskii wrote:
> >
> > > From: Liu Hui <liuhui1610 <at> gmail.com>
> > > Date: Thu, 24 Jul 2025 08:45:54 +0800
> > > Cc: Eli Zaretskii <eliz <at> gnu.org>, michael.albinus <at> gmx.de, 79036 <at> debbugs.gnu.org
> > >
> > > On Wed, Jul 23, 2025 at 11:08 PM kobarity <kobarity <at> gmail.com> wrote:
> > >
> > > > > For non-file buffers, could it return buffer name instead of <string>?
> > > > > e.g. #<buffer NAME> or #<NAME> where NAME may need to be quoted. Then
> > > > > python-pdbtrack-set-tracked-buffer can find it by (get-buffer-create
> > > > > "NAME").
> > > >
> > > > That might be a good idea. Why is `get-buffer-create' is necessary
> > > > rather than `get-buffer'?
> > >
> > > Thanks for pointing it out. get-buffer should be used here.
> >
> > So can we please have an updated patch for this?
>
> Since it is an improvement to add a new feature and not a fix for
> #79036, I think it would be better to separate the patches.
>
> Attached is my proposed patch to fix #79036.
Hi,
I find python-shell-send-file has the same issue as
python-shell-send-string, and
needs to use correct file-name too.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Mon, 04 Aug 2025 14:57:01 GMT)
Full text and
rfc822 format available.
Message #134 received at 79036 <at> debbugs.gnu.org (full text, mbox):
Liu Hui wrote:
>
> On Sun, Aug 3, 2025 at 7:47 PM kobarity <kobarity <at> gmail.com> wrote:
>
> > Eli Zaretskii wrote:
> > >
> > > > From: Liu Hui <liuhui1610 <at> gmail.com>
> > > > Date: Thu, 24 Jul 2025 08:45:54 +0800
> > > > Cc: Eli Zaretskii <eliz <at> gnu.org>, michael.albinus <at> gmx.de, 79036 <at> debbugs.gnu.org
> > > >
> > > > On Wed, Jul 23, 2025 at 11:08 PM kobarity <kobarity <at> gmail.com> wrote:
> > > >
> > > > > > For non-file buffers, could it return buffer name instead of <string>?
> > > > > > e.g. #<buffer NAME> or #<NAME> where NAME may need to be quoted. Then
> > > > > > python-pdbtrack-set-tracked-buffer can find it by (get-buffer-create
> > > > > > "NAME").
> > > > >
> > > > > That might be a good idea. Why is `get-buffer-create' is necessary
> > > > > rather than `get-buffer'?
> > > >
> > > > Thanks for pointing it out. get-buffer should be used here.
> > >
> > > So can we please have an updated patch for this?
> >
> > Since it is an improvement to add a new feature and not a fix for
> > #79036, I think it would be better to separate the patches.
> >
> > Attached is my proposed patch to fix #79036.
>
> Hi,
>
> I find python-shell-send-file has the same issue as
> python-shell-send-string, and
> needs to use correct file-name too.
Thanks, I will update the patch.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Wed, 06 Aug 2025 14:16:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 79036 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
kobarity wrote:
>
> Liu Hui wrote:
> >
> > On Sun, Aug 3, 2025 at 7:47 PM kobarity <kobarity <at> gmail.com> wrote:
> >
> > > Eli Zaretskii wrote:
> > > >
> > > > > From: Liu Hui <liuhui1610 <at> gmail.com>
> > > > > Date: Thu, 24 Jul 2025 08:45:54 +0800
> > > > > Cc: Eli Zaretskii <eliz <at> gnu.org>, michael.albinus <at> gmx.de, 79036 <at> debbugs.gnu.org
> > > > >
> > > > > On Wed, Jul 23, 2025 at 11:08 PM kobarity <kobarity <at> gmail.com> wrote:
> > > > >
> > > > > > > For non-file buffers, could it return buffer name instead of <string>?
> > > > > > > e.g. #<buffer NAME> or #<NAME> where NAME may need to be quoted. Then
> > > > > > > python-pdbtrack-set-tracked-buffer can find it by (get-buffer-create
> > > > > > > "NAME").
> > > > > >
> > > > > > That might be a good idea. Why is `get-buffer-create' is necessary
> > > > > > rather than `get-buffer'?
> > > > >
> > > > > Thanks for pointing it out. get-buffer should be used here.
> > > >
> > > > So can we please have an updated patch for this?
> > >
> > > Since it is an improvement to add a new feature and not a fix for
> > > #79036, I think it would be better to separate the patches.
> > >
> > > Attached is my proposed patch to fix #79036.
> >
> > Hi,
> >
> > I find python-shell-send-file has the same issue as
> > python-shell-send-string, and
> > needs to use correct file-name too.
>
> Thanks, I will update the patch.
Attached is the revised patch to fix #79036.
[0001-Fix-Python-PDB-tracking-for-remote-inferior-Python.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Thu, 07 Aug 2025 08:13:01 GMT)
Full text and
rfc822 format available.
Message #140 received at 79036 <at> debbugs.gnu.org (full text, mbox):
On Wed, Aug 6, 2025 at 10:14 PM kobarity <kobarity <at> gmail.com> wrote:
>
> kobarity wrote:
> >
> > Liu Hui wrote:
> > >
> > > On Sun, Aug 3, 2025 at 7:47 PM kobarity <kobarity <at> gmail.com> wrote:
> > >
> > > > Eli Zaretskii wrote:
> > > > >
> > > > > > From: Liu Hui <liuhui1610 <at> gmail.com>
> > > > > > Date: Thu, 24 Jul 2025 08:45:54 +0800
> > > > > > Cc: Eli Zaretskii <eliz <at> gnu.org>, michael.albinus <at> gmx.de, 79036 <at> debbugs.gnu.org
> > > > > >
> > > > > > On Wed, Jul 23, 2025 at 11:08 PM kobarity <kobarity <at> gmail.com> wrote:
> > > > > >
> > > > > > > > For non-file buffers, could it return buffer name instead of <string>?
> > > > > > > > e.g. #<buffer NAME> or #<NAME> where NAME may need to be quoted. Then
> > > > > > > > python-pdbtrack-set-tracked-buffer can find it by (get-buffer-create
> > > > > > > > "NAME").
> > > > > > >
> > > > > > > That might be a good idea. Why is `get-buffer-create' is necessary
> > > > > > > rather than `get-buffer'?
> > > > > >
> > > > > > Thanks for pointing it out. get-buffer should be used here.
> > > > >
> > > > > So can we please have an updated patch for this?
> > > >
> > > > Since it is an improvement to add a new feature and not a fix for
> > > > #79036, I think it would be better to separate the patches.
> > > >
> > > > Attached is my proposed patch to fix #79036.
> > >
> > > Hi,
> > >
> > > I find python-shell-send-file has the same issue as
> > > python-shell-send-string, and
> > > needs to use correct file-name too.
> >
> > Thanks, I will update the patch.
>
> Attached is the revised patch to fix #79036.
Thanks! I confirm it works.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Thu, 07 Aug 2025 13:09:02 GMT)
Full text and
rfc822 format available.
Message #143 received at 79036 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 06 Aug 2025 23:14:47 +0900
> From: kobarity <kobarity <at> gmail.com>
> Cc: 79036 <at> debbugs.gnu.org
>
> Attached is the revised patch to fix #79036.
Thanks, now installed on master.
Should we close this bug now, or is there anything else left to do
here?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79036; Package
emacs.
(Thu, 07 Aug 2025 13:53:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 79036 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
>
> > Date: Wed, 06 Aug 2025 23:14:47 +0900
> > From: kobarity <kobarity <at> gmail.com>
> > Cc: 79036 <at> debbugs.gnu.org
> >
> > Attached is the revised patch to fix #79036.
>
> Thanks, now installed on master.
>
> Should we close this bug now, or is there anything else left to do
> here?
Thanks. I think we can close this bug. It would be best for Liu to
send a patch as a separate bug ID for the improvement using the buffer
name.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Thu, 07 Aug 2025 14:47:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Liu Hui <liuhui1610 <at> gmail.com>:
bug acknowledged by developer.
(Thu, 07 Aug 2025 14:47:02 GMT)
Full text and
rfc822 format available.
Message #151 received at 79036-done <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 07 Aug 2025 22:52:13 +0900
> From: kobarity <kobarity <at> gmail.com>
> Cc: 79036 <at> debbugs.gnu.org
>
> Eli Zaretskii wrote:
> >
> > > Date: Wed, 06 Aug 2025 23:14:47 +0900
> > > From: kobarity <kobarity <at> gmail.com>
> > > Cc: 79036 <at> debbugs.gnu.org
> > >
> > > Attached is the revised patch to fix #79036.
> >
> > Thanks, now installed on master.
> >
> > Should we close this bug now, or is there anything else left to do
> > here?
>
> Thanks. I think we can close this bug. It would be best for Liu to
> send a patch as a separate bug ID for the improvement using the buffer
> name.
Thanks, closing.
This bug report was last modified 1 day ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.