On Thu, Jul 17, 2025 at 10:31 PM Eli Zaretskii <eliz@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.