Subject: Re: bug#79036: [PATCH] Fix pdb tracking for remote filenames

From: Eli Zaretskii <[email-masked]>
Date: Thu, 17 Jul 2025 15:08:48 +0300

> From: Liu Hui <[email-masked]>
> Date: Thu, 17 Jul 2025 18:20:59 +0800
> Cc: Michael Albinus <[email-masked]>, kobarity <[email-masked]>, [email-masked]
> 
> On Thu, Jul 17, 2025 at 4:46 PM Eli Zaretskii <[email-masked]> 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.?