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@gmail.com>
> > Cc: 79036@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.