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

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

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

C-h f find-sibling-file RET

The documentation says "By default, return only files that exist, but if
ALL is non-nil, return all matches.", but there is no ALL argument you
can pass to the command.

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.

Thanks.

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

[Eli Zaretskii]

> Resent-From: Daniel Martín <mardani29@yahoo.es>
> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
> Resent-CC: bug-gnu-emacs@gnu.org
> Resent-Sender: help-debbugs@gnu.org
> Date: Thu, 09 Jun 2022 23:27:46 +0200
> From:  Daniel Martín via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> 
> C-h f find-sibling-file RET
> 
> The documentation says "By default, return only files that exist, but if
> ALL is non-nil, return all matches.", but there is no ALL argument you
> can pass to the command.
> 
> 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.

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

[Juri Linkov]

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

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

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.

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.

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

[Lars Ingebrigtsen]

Daniel Martín <mardani29@yahoo.es> writes:

> The documentation says "By default, return only files that exist, but if
> ALL is non-nil, return all matches.", but there is no ALL argument you
> can pass to the command.

I've now fixed this in Emacs 29.

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

Good idea; now done.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Jose A Ortega Ruiz]

Lars, perhaps it'd be a good idea to make find-sibling-file--search a
public function, so that it can be used from elisp? (i know it already
can be used, you know what i mean :))

thanks,
jao
-- 
Dealing with failure is easy: Work hard to improve. Success is also
easy to handle: You've solved the wrong problem. Work hard to improve.
  - Alan Perlis, Epigrams on Programming

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

[Lars Ingebrigtsen]

Jose A Ortega Ruiz <jao@gnu.org> writes:

> Lars, perhaps it'd be a good idea to make find-sibling-file--search a
> public function, so that it can be used from elisp? (i know it already
> can be used, you know what i mean :))

It's just a helper function for `find-sibling-file' -- do you have a use
case for it outside of that command?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Jose A Ortega Ruiz]

On Sat, Jun 11 2022, Lars Ingebrigtsen wrote:

> Jose A Ortega Ruiz <jao@gnu.org> writes:
>
>> Lars, perhaps it'd be a good idea to make find-sibling-file--search a
>> public function, so that it can be used from elisp? (i know it already
>> can be used, you know what i mean :))
>
> It's just a helper function for `find-sibling-file' -- do you have a use
> case for it outside of that command?

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.

Cheers,
jao
-- 
I used to think that the brain was the most wonderful organ in my
body. Then I realized who was telling me this.
  -Emo Phillips, comedian, actor

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

[Lars Ingebrigtsen]

Jose A Ortega Ruiz <jao@gnu.org> 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...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Jose A Ortega Ruiz]

On Sat, Jun 11 2022, Lars Ingebrigtsen wrote:

> Jose A Ortega Ruiz <jao@gnu.org> 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

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

[Lars Ingebrigtsen]

Jose A Ortega Ruiz <jao@gnu.org> writes:

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

OK, I've now made the function public (and changed the arglist a bit).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Jose A Ortega Ruiz]

On Sun, Jun 12 2022, Lars Ingebrigtsen wrote:

> Jose A Ortega Ruiz <jao@gnu.org> writes:
>
>> 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).
>
> OK, I've now made the function public (and changed the arglist a bit).

excellent, thanks!

jao
-- 
Life isn't about finding yourself. Life is about creating yourself.
   -George Bernard Shaw, writer, Nobel laureate (1856-1950)

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

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Jose A Ortega Ruiz <jao@gnu.org> 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 think decoupling the computation of the list of siblings for a given
file and the action to perform on them (find-file for now) may be a good
idea.  That would offer programmatic access to extensions or user
customizations that want to do things to sibling files other than
visiting them.  If I'm not mistaken, this is what José is interested
about.