* 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-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 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-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 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 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 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
* 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
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 external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.