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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 55879 in the body.
You can then email your comments to 55879 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Daniel Martín <mardani29 <at> yahoo.es>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Missing ALL argument in find-sibling-file
Date: Thu, 09 Jun 2022 23:27:46 +0200

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.

Message #8 received at 55879 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: 55879 <at> debbugs.gnu.org
Subject: Re: bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
Date: Fri, 10 Jun 2022 08:46:10 +0300

> Resent-From: Daniel Martín <mardani29 <at> yahoo.es>
> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
> Resent-CC: bug-gnu-emacs <at> gnu.org
> Resent-Sender: help-debbugs <at> 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 <at> 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.

Message #11 received at 55879 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 55879 <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
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.

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

Message #14 received at 55879 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: 55879 <at> debbugs.gnu.org
Subject: Re: bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
Date: Fri, 10 Jun 2022 11:49:04 +0200

Daniel Martín <mardani29 <at> 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

Message #19 received at 55879 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 55879 <at> debbugs.gnu.org, mardani29 <at> yahoo.es
Subject: Re: bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
Date: Fri, 10 Jun 2022 13:57:04 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: Daniel Martín <mardani29 <at> yahoo.es>,
>   55879 <at> 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.

Message #22 received at 55879 <at> debbugs.gnu.org (full text, mbox):

From: Jose A Ortega Ruiz <jao <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Daniel Martín
 <mardani29 <at> yahoo.es>
Cc: 55879 <at> debbugs.gnu.org
Subject: Re: bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
Date: Fri, 10 Jun 2022 17:18:31 +0100

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

Message #25 received at 55879 <at> debbugs.gnu.org (full text, mbox):

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

Message #28 received at 55879 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Jose A Ortega Ruiz <jao <at> gnu.org>
Cc: 55879 <at> debbugs.gnu.org, Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
Date: Sat, 11 Jun 2022 12:58:04 +0200

Jose A Ortega Ruiz <jao <at> 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

Message #31 received at 55879 <at> debbugs.gnu.org (full text, mbox):

From: Jose A Ortega Ruiz <jao <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 55879 <at> debbugs.gnu.org, Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
Date: Sat, 11 Jun 2022 14:00:11 +0100

On Sat, Jun 11 2022, Lars Ingebrigtsen wrote:

> Jose A Ortega Ruiz <jao <at> 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

Message #34 received at 55879 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Jose A Ortega Ruiz <jao <at> gnu.org>
Cc: 55879 <at> debbugs.gnu.org, Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
Date: Sat, 11 Jun 2022 18:09:22 +0200

Jose A Ortega Ruiz <jao <at> 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

Message #37 received at 55879 <at> debbugs.gnu.org (full text, mbox):

From: Jose A Ortega Ruiz <jao <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 55879 <at> debbugs.gnu.org, Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
Date: Sat, 11 Jun 2022 22:23:37 +0100

On Sat, Jun 11 2022, Lars Ingebrigtsen wrote:

> Jose A Ortega Ruiz <jao <at> 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

Message #40 received at 55879 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 55879 <at> debbugs.gnu.org, Jose A Ortega Ruiz <jao <at> gnu.org>
Subject: Re: bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
Date: Sun, 12 Jun 2022 01:53:31 +0200

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

> Jose A Ortega Ruiz <jao <at> 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.

Message #43 received at 55879 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Jose A Ortega Ruiz <jao <at> gnu.org>
Cc: 55879 <at> debbugs.gnu.org, Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
Date: Sun, 12 Jun 2022 12:10:16 +0200

Jose A Ortega Ruiz <jao <at> 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

Message #46 received at 55879 <at> debbugs.gnu.org (full text, mbox):

From: Jose A Ortega Ruiz <jao <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 55879 <at> debbugs.gnu.org, Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
Date: Mon, 13 Jun 2022 02:21:25 +0100

On Sun, Jun 12 2022, Lars Ingebrigtsen wrote:

> Jose A Ortega Ruiz <jao <at> 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)

Previous Next

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