GNU bug report logs - #57325
27.1; functions in ff-other-file-alist

Previous Next

Full log

View this message in rfc822 format

From: Felician Nemeth <felician.nemeth <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 57325 <at> debbugs.gnu.org
Subject: bug#57325: 27.1; functions in ff-other-file-alist
Date: Tue, 30 Aug 2022 10:46:22 +0200

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

Eli Zaretskii <eliz <at> gnu.org> writes:

>> >> Also, when the function returns an absolute file name, then the
>> >> returned file should be already opened, otherwise ff-find-other-file
>> >> cannot find it.
>> >
>> > Hmm... not sure how this is relevant.  The function should return a
>> > list of extensions, not a file name.  What am I missing?
>> 
>> In my case, the related file of foo.toml is bar.json.  From an extension
>> it is not possible to guess whether the related file is bar.json or
>> baz.json.  find-file.el of Emacs 27.1 has this in the Commentary
>> section:
>> 
>> ;; These functions must return a list consisting of the possible names of the
>> ;; corresponding file, with or without path.
>> 
>> That's why I thought my function could return an absolute file name.
>
> If the returned list includes file names with leading directories,
> find-file.el strips the leading directories and uses the basename to
> match against.

I think that not how it works.  Even if the attached file is in a
directory that contains a file named "hosts", when I

  1. emacs -Q test.el
  2. y
  3. M-x eval-buffer RET
  4. M-x ff-find-other-file RET

Emacs is going to switch to the buffer containing /etc/hosts.

> Another thing to clarify in the docs?

Playing with the implementation, I think that these functions shouldn't
return extensions.  They should return file names.

[test.el (application/emacs-lisp, attachment)]

Previous Next

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