bug#57325: 27.1; functions in ff-other-file-alist

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 57325@debbugs.gnu.org
> Date: Mon, 22 Aug 2022 14:44:47 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Felician Nemeth <felician.nemeth@gmail.com>
> > Cc: 57325@debbugs.gnu.org
> > Date: Sun, 21 Aug 2022 21:37:31 +0200
> > 
> > I got confused because if I remove the
> > (setq uniquify-buffer-name-style nil) line from bug.el, then
> > ff-find-related-file will open the parent directory of xref.el, which
> > feels correct.  However, with that line setting
> > uniquify-buffer-name-style, ff-find-related-file selects /tmp/dir/1234,
> > which feels wrong because that buffer has nothing to do with xref.el.
> > 
> > In my case, a file can contain a link to another file (a .toml file to a
> > schema file).  I wasn't sure what to do when the original file did not
> > contain a link.  Maybe my-find-related-file should ask the user what to
> > do in this case, or just do a (user-error "There's no related file.").
> 
> OK, I will look closer at this specific use case and see whether
> there's some problem in find-file.el in that case.

AFAICT, what you saw is the consequence of one basic problem:
ff-find-the-other-file is unprepared to deal with a function that
returns nil (instead of a list of file-name extensions to try).  So it
tries to use that nil value as if it was a list of extensions, and the
result is basically random.

It should be easy to make ff-find-the-other-file detect the nil value
and handle it as if it found no match for the current buffer's file.
Do you think this would be better?  Or we could simply document that a
function in ff-other-file-alist must return a list of extensions.

WDYT?