Liam, there are many objects that change the number of inlets when is instantiated differently... so, when you give the -r flag, the text search could be, by default, give all the matches, but also create more inlets to set the range, and if you set a -1 to (bigger than max number of lines) range, it will give all the matches again.
Miller, what about this? Em Qua, 25 de jul de 2018 04:43, Liam Goodacre <liamg...@hotmail.com> escreveu: > I think that the second option of outputting multiple matches together > would be the simplest and most useful. It should definitely be an optional > feature though, otherwise it would again damage old patches which use [text > search] and are expecting only one match. A simple -r flag would seem > sufficient for this. > > I would also suggest that the output should be a sequence of floats, > rather than a list. This seems more consistent with other PD objects, and > more useful, since you probably want to [get] the matches immediately > anyway. But this is a minor detail. > > I can see that the first option of introducing ranges is more powerful and > opens up more possibilities. However, I'm guessing it would require a new > inlet on the object, and the second inlet on [text search] is already taken > for setting the pointer. So you'd either need to break backwards > compatibility for [text search], or break the convention of the pointer > being the farthest right inlet. > > However, I have another idea for fixing ranges in [text search]. You can > currently search in specific fields using arguments (so [text search mytext > 0 1] allows you to search in the 1st and 2nd fields of the text only). I > suggest a special field--say "-1" or "range"--that allows you to search > against the line number. So for instance, searching "cat 5 10" into [text > search mytext 0 < field > field] would search for a text entry after line > number 5 but before 10 with "cat" as its 1st term. This would allow you to > access ranges without having to worry about new inlets. > > I've suggested this before and I still think that it would be a great > feature. However, I don't think that it would be the best solution for > recursive searching, and I would love to see a new "-r" feature and a > "range" feature implemented together. I say this because 1: using ranges to > achieve multiple results is not trivial--not for new users anyway, and > especially not compared to a simple "-r" flag. And 2: I'm guessing that it > would be less efficient. > > ------------------------------ > *From:* Miller Puckette <m...@ucsd.edu> > *Sent:* 21 July 2018 13:28 > *To:* Liam Goodacre > *Cc:* PD list > *Subject:* Re: [PD] recursive searching with [text search] > > I keep thinking about that too. One idea would be to specify a range of > lines to search in, so that one could use the results of the previous > search > to start teh next one. > > Another would be to output a list of ALL search-matches. > > cheers > Miller > > On Sat, Jul 21, 2018 at 09:10:57AM +0000, Liam Goodacre wrote: > > People often ask about how to get multiple matches with [text search] > (see here< > https://forum.pdpatchrepo.info/topic/11504/multiple-search-results-in-text>). > There are a few ways of doing it but none of them are very optimal, and it > seems like something that would be much easier and more efficient if it > were implemented with code. > > > > Would there be any traction for a new feature, say [text search -r], to > allow for recursive searching? > > > _______________________________________________ > > Pd-list@lists.iem.at mailing list > > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list