bug#55879: 29.0.50; Missing ALL argument in find-sibling-file

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Daniel Martín <mardani29@yahoo.es>,
>   55879@debbugs.gnu.org
> Date: Fri, 10 Jun 2022 10:55:28 +0300
> 
> >> Also, the Info documentation could reference ff-find-related-file when
> >> it gives the example of going from the source file to the header file in
> >> C files.
> >
> > I still think we should have extended ff-find-related-file instead of
> > introducing a completely new facility with an incompatible UI.
> 
> I started to use find-sibling-file and noticed that it's quite powerful
> despite its simplicity.  For example, with such configuration:
> 
> dir1/.dir-locals-2.el:
>   ((nil . ((find-sibling-rules . (("src/[^/]+/\\(.*\\)\\'"
>                                    "src/dir2/\\1\\'"))))))
> dir2/.dir-locals-2.el:
>   ((nil . ((find-sibling-rules . (("src/[^/]+/\\(.*\\)\\'"
>                                    "src/dir3/\\1\\'"))))))
> dir3/.dir-locals-2.el:
>   ((nil . ((find-sibling-rules . (("src/[^/]+/\\(.*\\)\\'"
>                                    "src/dir1/\\1\\'"))))))
> 
> it allows cycling between sibling files of three source trees
> in the predefined order.

I don't think I understand what "cycling" means in this context, let
alone why it would make sense.  If file A has a "related" file B, then
file B should have file A as its related file, and any feature similar
to these two should support this concept.  If this concept is
supported, then you can get from any file to any of its "siblings", in
any order you like.

> Can ff-find-related-file do the same?

ff-find-related-file separates the directories to look in from the
rules for basenames of the files, but other than that, these two
features are equivalent.

And please note that I said "extended", i.e. if ff-find-related-file
doesn't support some use case, it should be extended to do so.  I
expect the extension to be simple enough, given the infrastructure
that already exists.