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

[Juri Linkov]

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

Cycling is visiting siblings in the defined order such as
dir1 -> dir2 -> dir3 -> dir1 -> ...

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

find-sibling-file supports more than 2 siblings, i.e. triplets and more.

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

I have no opinion about extending find-file.el, but when looking at it,
it strikes as too complicated, so extending will make it complicated even more.