GNU bug report logs - #79036
[PATCH] Fix pdb tracking for remote filenames

Previous Next

Full log

Message #92 received at 79036 <at> debbugs.gnu.org (full text, mbox):

From: Liu Hui <liuhui1610 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79036 <at> debbugs.gnu.org, kobarity <at> gmail.com, michael.albinus <at> gmx.de
Subject: Re: bug#79036: [PATCH] Fix pdb tracking for remote filenames
Date: Fri, 18 Jul 2025 23:31:50 +0800

On Fri, Jul 18, 2025 at 10:52 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Liu Hui <liuhui1610 <at> gmail.com>
> > Date: Fri, 18 Jul 2025 22:06:56 +0800
> > Cc: michael.albinus <at> gmx.de, kobarity <at> gmail.com, 79036 <at> debbugs.gnu.org
> >
> > On Fri, Jul 18, 2025 at 8:08 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > >
> > > > 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.
> > >
> > > Sorry, I don't understand the problem and its solution.  What do you
> > > mean by "local file name in a remote python shell"?
> >
> > 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.
>
> Doesn't the value of default-directory tells us whether it's a local
> or a remote file?  If not, why not?

In the example:

    >>> f()
    > /tmp/test.py(3)f()
    -> return 1
    (Pdb)

The current buffer is the Python shell buffer, default-directory is
remote only means
 python process is remote. "/tmp/test.py" may be on the local host because users
may send code in local file "/tmp/test.py" to the remote process.

> > > > 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.
> > >
> > > This can be handled by other means.  But again, I don't understand why
> > > is this important, so please elaborate.
> >
> > I was explaining why file-exists-p is needed. It is another possible
> > case.
>
> If a file doesn't exist, debugging it will not work.  The fact that we
> leave behind an empty buffer is not important.

Since an empty buffer is useless, why not just not show it in the
first place? I find it disturbing.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.