GNU bug report logs - #78925
31.0.50; ffap's filename prompt problem in remote files

Previous Next

Package: emacs;

Reported by: Liu Hui <liuhui1610 <at> gmail.com>

Date: Mon, 30 Jun 2025 09:55:02 UTC

Severity: normal

Found in version 31.0.50

To reply to this bug, email your comments to 78925 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#78925; Package emacs. (Mon, 30 Jun 2025 09:55:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Liu Hui <liuhui1610 <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Mon, 30 Jun 2025 09:55:03 GMT) Full text and rfc822 format available.

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

From: Liu Hui <liuhui1610 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; ffap's filename prompt problem in remote files
Date: Mon, 30 Jun 2025 17:54:31 +0800
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.

Case 2:

1. emacs -Q
2. Open a file in a remote project:
   C-x C-f /ssh:server:~/a_git_project/test_file
3. Create a file that exists outside the project in the remote host, e.g.
   M-! touch /tmp/abc
4. type the above filename (i.e. /tmp/abc), in test_file, and M-x ffap

ffap prompts /ssh:server:~/a_git_project/tmp/abc, while in Emacs 29
prompts /ssh:server:/tmp/abc correctly. This problem seems to be
related to commit 1eae0e7edf4.

Thanks.

--
Liu Hui




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78925; Package emacs. (Mon, 30 Jun 2025 12:59:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Liu Hui <liuhui1610 <at> gmail.com>
Cc: 78925 <at> debbugs.gnu.org
Subject: Re: bug#78925: 31.0.50; ffap's filename prompt problem in remote files
Date: Mon, 30 Jun 2025 15:58:11 +0300
> From: Liu Hui <liuhui1610 <at> gmail.com>
> Date: Mon, 30 Jun 2025 17:54:31 +0800
> 
> 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.

> Case 2:
> 
> 1. emacs -Q
> 2. Open a file in a remote project:
>    C-x C-f /ssh:server:~/a_git_project/test_file
> 3. Create a file that exists outside the project in the remote host, e.g.
>    M-! touch /tmp/abc
> 4. type the above filename (i.e. /tmp/abc), in test_file, and M-x ffap
> 
> ffap prompts /ssh:server:~/a_git_project/tmp/abc, while in Emacs 29
> prompts /ssh:server:/tmp/abc correctly. This problem seems to be
> related to commit 1eae0e7edf4.

This is a separate issue, please submit a separate bug report for it.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78925; Package emacs. (Mon, 30 Jun 2025 15:49:01 GMT) Full text and rfc822 format available.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Liu Hui <liuhui1610 <at> gmail.com>, 78925 <at> debbugs.gnu.org
Subject: Re: bug#78925: 31.0.50; ffap's filename prompt problem in remote files
Date: Mon, 30 Jun 2025 17:48:04 +0200
Eli Zaretskii <eliz <at> gnu.org> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#78925; Package emacs. (Tue, 01 Jul 2025 04:46:01 GMT) Full text and rfc822 format available.

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

From: Liu Hui <liuhui1610 <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 78925 <at> debbugs.gnu.org
Subject: Re: bug#78925: 31.0.50; ffap's filename prompt problem in remote files
Date: Tue, 1 Jul 2025 12:45:07 +0800
On Mon, Jun 30, 2025 at 11:48 PM Michael Albinus <michael.albinus <at> gmx.de> wrote:
>
> Eli Zaretskii <eliz <at> gnu.org> 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.

Thanks for your comments.

> 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.

I'm not saying ffap is wrong, after all, it's just guessing. The key
is that we should use the more likely option as the default, while
also providing options for other contexts.

When the buffer's default directory and buffer-file-name are both
remote, without other prior information, I think the filenames in the
buffer are much more likely to be remote files than local ones. If the
user wants to access the corresponding local file, removing the
preceding remote host part manually is quite easy.

> 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.

A user option is useful for file-name-at-point-functions (C-x C-f
M-n), embark-target-file-at-point etc, which cannot use prefix argument.

How about 'ffap-remote-context-preference'? Depending on whether the
file exists on remote and local hosts, current ffap behavior and
possible options are as follows. IMO, perfer-remote or
perfer-remote-exist is more suitable to be the default behavior.

 | file   | prefer-local-exist | prefer-remote | prefer-remote-exist |
 | exist? | (current behavior) |               |                     |
 |--------+--------------------+---------------+---------------------|
 | both   | local              | remote        | remote              |
 | remote | remote             | remote        | remote              |
 | local  | local              | remote parent | local               |
 | none   | local parent       | remote parent | remote parent       |

> 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.




This bug report was last modified 5 days ago.

Previous Next


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