[PD] recursive searching with [text search]

[José de Abreu]

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_uw at 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 <msp at 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 at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180725/cf739e4e/attachment.html>