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

From: Michael Albinus <[email-masked]>
Date: Thu, 17 Jul 2025 17:52:59 +0200

Eli Zaretskii <[email-masked]> writes:

Hi Eli,

> I meant to call expand-file-name only in the local case.  AFAIU, if
> file-remote-p returns non-nil, its argument is already an absolute
> file name.  But the alternative:
>
>   (concat (file-remote-p default-directory) file)
>
> will not necessarily produce an absolute file name.

Sure. That's why I don't use it in case FILE is relative.

>> (defun file-remote-name (file)
>>   "Return the remote file name of FILE.
>> If FILE is a relative file name, return FILE as it is.
>> If FILE is already remote, return FILE as it is.
>> If `default-directory' is local, return FILE as it is.
>> Otherwise, prepend the remote file name component of `default-directory'
>> to FILE."
>
> I would like this to be the equivalent of expand-file-name, so we
> could use it instead of expand-file-name when an absolute file name
> actually names a remote file.  If we return a relative file name, Lisp
> programs will need to call expand-file-name on them, which is not what
> we want, IMO.

Again, the function shall be as cheap as file-local-name or
file-remote-p. No round-trip to the remote, in no case.

(I remember when I've added file-local-name. I was blamed for
performance problems.)

> And I'm not sure I understand what you are trying to say here:
>
>> expand-file-name has a price on remote systems, it should be called
>> explicitly by the callee of file-remote-name
>
> (I guess you meant "caller", not "callee".)

Of course.

> If you want to avoid the
> price of calling expand-file-name when FILE is already expanded, we
> can call expand-file-name only on relative file names and only if
> default-directory is local.  Would that solve the problem?

It isn't simply needed. Whatever the new function returns, it is good
for being used with expand-file-name. Just a granular function.

It is up to the callee (sic :-) to apply expand-file-name if needed.

Best regards, Michael.