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

From: Jose A Ortega Ruiz <[email-masked]>
Date: Sat, 11 Jun 2022 22:23:37 +0100

On Sat, Jun 11 2022, Lars Ingebrigtsen wrote:

> Jose A Ortega Ruiz <[email-masked]> writes:
>
>> I was thinking of reusing the sibling files mechanism programmatically,
>> outside the mere "find a single file" scenario.  For instance, i have a
>> few functions that associate a list of note org files to a single pdf,
>> and i might want to display them all (perhaps in other window), or add
>> text to one of them (with the decision of which one taken
>> programmatically, depending on context)... For cases like that, i would
>> start with the result of obtaining the list of siblings inside my
>> commands, and find-sibling-file--search looked like the function doing
>> that.
>
> find-sibling-file--search is there to find matches in the
> `find-sibling-rules' variable, which is a user option, and returns
> values in an order that's appropriate for the commmand.  It sounds like
> you want something slightly different, really -- pass in the rules,
> perhaps?  But I'm not sure that really makes that much sense, either,
> because associating org files with a pdf sounds like something you'd
> want a data file for, really...

i was thinking of a rule saying for instance 'the siblings of
dir/foo.pdf are dir/foo/*.org'.  that might be a bad example.

but even in the "normal" case, i'd like to be able to define
find-first-sibling, or maybe find-last-modified-sibling, or
show-sibling-other-window, or...  for that i'd use
find-sibling-file--search (i think).

in other words, i am thinking that there are two parts to this new api,
one is defining/listing the siblings of a given file and the other is
actually finding (in the find-file sense) one of them.  i was asking for
a public way of accessing the first half.

jao
-- 
I always pass on good advice. It's the only thing to do with it. It is
never any use to oneself.
 -Oscar Wilde