GNU bug report logs - #55879
29.0.50; Missing ALL argument in find-sibling-file

Previous Next

Package: emacs;

Reported by: Daniel Martín <mardani29 <at> yahoo.es>

Date: Thu, 9 Jun 2022 21:29:02 UTC

Severity: normal

Found in version 29.0.50

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 55879 <at> debbugs.gnu.org, mardani29 <at> yahoo.es
Subject: bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
Date: Fri, 10 Jun 2022 19:39:24 +0300
>> 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.




This bug report was last modified 3 years and 31 days ago.

Previous Next


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