GNU bug report logs -
#79036
[PATCH] Fix pdb tracking for remote filenames
Previous Next
Full log
View this message in rfc822 format
> 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.?
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.