GNU bug report logs -
#78925
31.0.50; ffap's filename prompt problem in remote files
Previous Next
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
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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 1 day ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.