It occurred to me that often during searching I am looking for some text X that is "near to" some text Y, and I don't know of a tool that can do that..Where "near" is some configurable distance in bytes.

I thought about using a regex, but it seems pretty painful way to do what i want.

I suppose one workaround might be a little tool that would let you specify 2 (or more) literal strings, and a distance value, and generate for you the regex search that will search for occurences of these literal strings within that distance (in any order).

Reading this request, I had hoped that someone came by with a solution by one of the indexing search tools - rjbull correctly mentioning FL Pro (50$) which does this indeed, but if you need this functionality for searching within gigabytes of data, FL isn't the right tool, except for special, not regular use cases, ie when you're willing to wait, and wait, and wait... in order to get half-way-neat search results, instead of then checking much too many search results visually, which time-wise would probably be the same nuisance but which is even less fun, for the following reason:

It's odd that nobody except for me ever mentioned this lack of functionality of some (/all???) search tools: When you have got some "hit list" (with or without indexed search), and when then you visually check the results, one by one, discarding the not-relevant hits by just reading their "context-line" in the hit-table, or needing to look into the preview for that, or even needing to open the respective original files before discarding those files/hits as irrelevant for your current purpose -

so when you do the triage relevant-not-relevant, you would want to discard the non-relevant hits from the hit list, by pressing the "delete" button, in order to visually narrow down that list to an acceptable format (original length perhaps 80 hits, length after narrowing the list down perhaps 12 hits) - some search tools I trialed did NOT react to the deletion button though, while it's evident that this would have been very important functionality.

So, what about the usual searchers here, X1, dtSearch, Copernic, Lokeen (any experiences about the general-search value of this originally OL specialist?), HyperSearch, Archivarius, SearchInform...?

What about InfoRapid, which is said to have "special strengths with plain text files" (which seems mouser's task here and often is the task at hand)?

As for FL, the Lite version is simply what originally had been "Agent Ransack"; the developer renamed it for acceptability reasons (weird, "aggressive" original name), so there aren't but 2 versions but (probably even today) under 3 denominations; it's correct that the FL Lite version doesn't have "vicinity search" - the developer wants to sell the paid version, understandably.

With FL (Lite AND Pro), you always must bear in mind the possible problem of them not finding special/European/Asian characters, depending on the file format; it's a similar problem for indexer-searchers which most of the time will not even those file formats in question while in fact, you would prefer them to at least index, even wrongly for the special characters, those files, in order for them to at least find/list search terms without special characters! It's odd, here again, that their developers don't even see the problem since of course, you would happily except ugly, foiled-up search results (the hit list containing command characters, too) but which correctly indicate the search target lines within "exotic" file formats, and let's be frank, for some of the indexer-searches, almost everything except MS Office, simple rtf and plain text is more or less "exotic" so that they don't even index, ie will never show any results.

That's the strength of FL (even Lite): It will trawl (almost?) anything, so that you will get some character jungle in the hit table, but that list will probably show you (also) what you will have been looking for, and that's not only the case with Amercian standard characters a...zA...Z, but you also CAN search for special characters IF you know how they are encoded within the file format in question.

I'm thinking of buying FL after all (newer versions didn't run with XP, so that problem isn't a problem for me anymore); unfortunately, the developer isn't that "responsive": I've been longing for FL to implement a "search within the search results" for years - that functionality missing had been the reason for me never buying that tool even when it ran with XP (there's always an XP-running free version available btw, but I think that's not pertinent for the readers of this forum).

Since it's evident that a non-indexing searcher is in heavy need for a "search within the results", when each search takes long minutes if the file body to be searched is big enough (the developer brings - imo quite weak - arguments for leaving this out, but if I accept to gratuitously wait minutes for search results if the tool is free, I do not do so if I have to pay more than 60$ incl. VAT) - and you cannot delete non-pertinent search results (as described above) in FL either.

Search-within-search isn't the same as vicinity search of course, but often, you could use either one or the other to get to your means. (This isn't true when the vicinity searched-for would be a very close one.)

I have used below quick steps to get this "near" type searches. Obviously both the "words" are in same line.1. List all lines containing "word1" from all required files.2. Search for "word2" in the listed lines and list those lines.

Manually look at the lines finally generated to find the one looking for.

I have found these steps quicker to perform than make the regex for it. Try it.

It occurred to me that often during searching I am looking for some text X that is "near to" some text Y, and I don't know of a tool that can do that..Where "near" is some configurable distance in bytes.

I'm thinking of buying FL after all (newer versions didn't run with XP, so that problem isn't a problem for me anymore); unfortunately, the developer isn't that "responsive": I've been longing for FL to implement a "search within the search results" for years - that functionality missing had been the reason for me never buying that tool even when it ran with XP (there's always an XP-running free version available btw, but I think that's not pertinent for the readers of this forum).

Since it's evident that a non-indexing searcher is in heavy need for a "search within the results", when each search takes long minutes if the file body to be searched is big enough (the developer brings - imo quite weak - arguments for leaving this out, but if I accept to gratuitously wait minutes for search results if the tool is free, I do not do so if I have to pay more than 60$ incl. VAT) - and you cannot delete non-pertinent search results (as described above) in FL either.

Search-within-search isn't the same as vicinity search of course, but often, you could use either one or the other to get to your means. (This isn't true when the vicinity searched-for would be a very close one.)