GNU bug report logs -
#79036
[PATCH] Fix pdb tracking for remote filenames
Previous Next
Reported by: Liu Hui <liuhui1610 <at> gmail.com>
Date: Thu, 17 Jul 2025 04:59:01 UTC
Severity: normal
Tags: patch
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> 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.
This bug report was last modified 19 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.