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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: felician.nemeth <at> gmail.com
Cc: 57325 <at> debbugs.gnu.org
Subject: bug#57325: 27.1; functions in ff-other-file-alist
Date: Thu, 25 Aug 2022 11:14:20 +0300

> Cc: 57325 <at> debbugs.gnu.org
> Date: Mon, 22 Aug 2022 14:44:47 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Felician Nemeth <felician.nemeth <at> gmail.com>
> > Cc: 57325 <at> 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?

Previous Next

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