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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Liu Hui <liuhui1610 <at> gmail.com>
Subject: bug#78925: closed (Re: bug#78925: 31.0.50; ffap's filename prompt
 problem in remote files)
Date: Sat, 12 Jul 2025 08:44:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

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

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 78925 <at> debbugs.gnu.org.

-- 
78925: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=78925
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Eli Zaretskii <eliz <at> gnu.org>
To: Liu Hui <liuhui1610 <at> gmail.com>
Cc: 78925-done <at> debbugs.gnu.org
Subject: Re: bug#78925: 31.0.50; ffap's filename prompt problem in remote files
Date: Sat, 12 Jul 2025 11:43:40 +0300

> From: Liu Hui <liuhui1610 <at> gmail.com>
> Date: Mon, 7 Jul 2025 17:58:17 +0800
> Cc: 78925 <at> debbugs.gnu.org
> 
> On Mon, Jun 30, 2025 at 8:58 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > > 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.
> 
> The attached patch adds an option 'ffap-prefer-remote-file', which
> defaults to nil. A non-nil value means ffap always finds remote files
> for absolute filenames in remote case, instead of finding local files
> first.

Thanks, installed on master, and closing the bug.

[Message part 3 (message/rfc822, inline)]

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

Previous Next

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