unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
       [not found] <m1r13xbk8d.fsf.ref@yahoo.es>
@ 2022-06-09 21:27 ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-06-10  5:46   ` Eli Zaretskii
  2022-06-10  9:49   ` Lars Ingebrigtsen
  0 siblings, 2 replies; 14+ messages in thread
From: Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-06-09 21:27 UTC (permalink / raw)
  To: 55879


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.





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
  2022-06-09 21:27 ` 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
@ 2022-06-10  5:46   ` Eli Zaretskii
  2022-06-10  7:55     ` Juri Linkov
  2022-06-10  9:49   ` Lars Ingebrigtsen
  1 sibling, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2022-06-10  5:46 UTC (permalink / raw)
  To: Daniel Martín; +Cc: 55879

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
  2022-06-10  5:46   ` Eli Zaretskii
@ 2022-06-10  7:55     ` Juri Linkov
  2022-06-10 10:57       ` Eli Zaretskii
  0 siblings, 1 reply; 14+ messages in thread
From: Juri Linkov @ 2022-06-10  7:55 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 55879, Daniel Martín

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
  2022-06-09 21:27 ` 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
  2022-06-10  5:46   ` Eli Zaretskii
@ 2022-06-10  9:49   ` Lars Ingebrigtsen
  2022-06-10 16:18     ` Jose A Ortega Ruiz
  1 sibling, 1 reply; 14+ messages in thread
From: Lars Ingebrigtsen @ 2022-06-10  9:49 UTC (permalink / raw)
  To: Daniel Martín; +Cc: 55879

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
  2022-06-10  7:55     ` Juri Linkov
@ 2022-06-10 10:57       ` Eli Zaretskii
  2022-06-10 16:39         ` Juri Linkov
  0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2022-06-10 10:57 UTC (permalink / raw)
  To: Juri Linkov; +Cc: 55879, mardani29

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
  2022-06-10  9:49   ` Lars Ingebrigtsen
@ 2022-06-10 16:18     ` Jose A Ortega Ruiz
  2022-06-11 10:58       ` Lars Ingebrigtsen
  0 siblings, 1 reply; 14+ messages in thread
From: Jose A Ortega Ruiz @ 2022-06-10 16:18 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Daniel Martín; +Cc: 55879


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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
  2022-06-10 10:57       ` Eli Zaretskii
@ 2022-06-10 16:39         ` Juri Linkov
  0 siblings, 0 replies; 14+ messages in thread
From: Juri Linkov @ 2022-06-10 16:39 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 55879, mardani29

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
  2022-06-10 16:18     ` Jose A Ortega Ruiz
@ 2022-06-11 10:58       ` Lars Ingebrigtsen
  2022-06-11 13:00         ` Jose A Ortega Ruiz
  0 siblings, 1 reply; 14+ messages in thread
From: Lars Ingebrigtsen @ 2022-06-11 10:58 UTC (permalink / raw)
  To: Jose A Ortega Ruiz; +Cc: 55879, Daniel Martín

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
  2022-06-11 10:58       ` Lars Ingebrigtsen
@ 2022-06-11 13:00         ` Jose A Ortega Ruiz
  2022-06-11 16:09           ` Lars Ingebrigtsen
  0 siblings, 1 reply; 14+ messages in thread
From: Jose A Ortega Ruiz @ 2022-06-11 13:00 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 55879, Daniel Martín

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
  2022-06-11 13:00         ` Jose A Ortega Ruiz
@ 2022-06-11 16:09           ` Lars Ingebrigtsen
  2022-06-11 21:23             ` Jose A Ortega Ruiz
  2022-06-11 23:53             ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 2 replies; 14+ messages in thread
From: Lars Ingebrigtsen @ 2022-06-11 16:09 UTC (permalink / raw)
  To: Jose A Ortega Ruiz; +Cc: 55879, Daniel Martín

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
  2022-06-11 16:09           ` Lars Ingebrigtsen
@ 2022-06-11 21:23             ` Jose A Ortega Ruiz
  2022-06-12 10:10               ` Lars Ingebrigtsen
  2022-06-11 23:53             ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 1 reply; 14+ messages in thread
From: Jose A Ortega Ruiz @ 2022-06-11 21:23 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 55879, Daniel Martín

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
  2022-06-11 16:09           ` Lars Ingebrigtsen
  2022-06-11 21:23             ` Jose A Ortega Ruiz
@ 2022-06-11 23:53             ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 0 replies; 14+ messages in thread
From: Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-06-11 23:53 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 55879, Jose A Ortega Ruiz

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.





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
  2022-06-11 21:23             ` Jose A Ortega Ruiz
@ 2022-06-12 10:10               ` Lars Ingebrigtsen
  2022-06-13  1:21                 ` Jose A Ortega Ruiz
  0 siblings, 1 reply; 14+ messages in thread
From: Lars Ingebrigtsen @ 2022-06-12 10:10 UTC (permalink / raw)
  To: Jose A Ortega Ruiz; +Cc: 55879, Daniel Martín

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#55879: 29.0.50; Missing ALL argument in find-sibling-file
  2022-06-12 10:10               ` Lars Ingebrigtsen
@ 2022-06-13  1:21                 ` Jose A Ortega Ruiz
  0 siblings, 0 replies; 14+ messages in thread
From: Jose A Ortega Ruiz @ 2022-06-13  1:21 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 55879, Daniel Martín

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)





^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2022-06-13  1:21 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <m1r13xbk8d.fsf.ref@yahoo.es>
2022-06-09 21:27 ` 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
2022-06-10  5:46   ` Eli Zaretskii
2022-06-10  7:55     ` Juri Linkov
2022-06-10 10:57       ` Eli Zaretskii
2022-06-10 16:39         ` Juri Linkov
2022-06-10  9:49   ` Lars Ingebrigtsen
2022-06-10 16:18     ` Jose A Ortega Ruiz
2022-06-11 10:58       ` Lars Ingebrigtsen
2022-06-11 13:00         ` Jose A Ortega Ruiz
2022-06-11 16:09           ` Lars Ingebrigtsen
2022-06-11 21:23             ` Jose A Ortega Ruiz
2022-06-12 10:10               ` Lars Ingebrigtsen
2022-06-13  1:21                 ` Jose A Ortega Ruiz
2022-06-11 23:53             ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).