Subject: Re: bug#78925: 31.0.50; ffap's filename prompt problem in remote files

From: Michael Albinus <[email-masked]>
Date: Mon, 30 Jun 2025 17:48:04 +0200

Eli Zaretskii <[email-masked]> writes:

Hi,

>> When using ffap in remote files, I find the guess of filename at point
>> in the prompt, which is mainly determined by ffap-file-at-point, is
>> not suitable or at least inconsistent.
>> 
>> Case 1:
>> 
>> 1. emacs -Q
>> 2. Open a remote file:
>>    C-x C-f /ssh:server:~/test_file
>> 3. type a filename that exists in localhost (e.g. /etc/hosts), and M-x ffap
>> 
>> ffap finds the local file /etc/hosts instead of the remote one. The
>> reason is that ffap-file-at-point always checks the local file first.
>> ffap-file-at-point only tries to find remote file if there is no
>> existing local file.
>> 
>> However, it is more reasonable to first check (or only check) remote
>> file and always prompt remote filename (i.e. /ssh:server:/etc/hosts)
>> in remote cases.
>
> I don't think I agree.  However, perhaps a user option or a prefix
> argument could be used to control which behavior is preferred.

FTR, /etc/hosts is an absolute file name; ffap is right showing the
local file. And changing the default to always prepend the remote prefix
isn't right: there might be use cases, that you have a reference to a
local file /etc/hosts in your buffer, the buffer has a remote default
directory, and you still want to see the local file. It depends on the
context.

A user option might help, but it is all-or-nothing. Either, you will
always see the remote file, or always the local file. Your expectation
might change, case by case.

Another possibility would be a command prefix. If ffap is called with
the universal-argument non-nil (C-u invoked), a local file like
/etc/hosts might be displayed from the remote host. Or vice-versa,
whatever we declare as default.

Best regards, Michael.