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

Previous Next

Package: emacs;

Reported by: Felician Nemeth <felician.nemeth <at> gmail.com>

Date: Sun, 21 Aug 2022 18:35:01 UTC

Severity: normal

Found in version 27.1

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

Bug is archived. No further changes may be made.

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: Sun, 21 Aug 2022 21:37:31 +0200
> Thanks, now fixed on the emacs-28 branch.

Thank you.

>> More importantly, if the associated value is a function, then there's no
>> way for the function to signal that it cannot find a related file.

> What would you have the package do instead when "the other" file is
> not found?

Most probably I just failed to understand that my-find-related-file
should not return nil and, as you say, it cannot meaningfully signal a
failure.  If this is the case, this bug can be closed and I'm sorry for
the noise.

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.").

Thanks again.




This bug report was last modified 2 years and 328 days ago.

Previous Next


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