Generated a test case for this issue (TestProximityIterablePosting) that this addition fails.

We need to define what block distance in proximity means.

Example:
Document: "Whenever you win a coin flip, put a luck counter on Chance Encounter"
Query: "coin flip luck"
Window: 3

The current implementation would return this document because window radius is calculated as Window*numQueryTerms (3*3=9)

My expectation is that window radius should be equal to Window?

Probably, the implementation will be even simpler if you consider just 'window' instead of 'window * num_query_terms'.
But what if, for instance, window is less than num_query_term? Ex: "coin flip luck counter"~2, does it have to return no results? Or does it have to return all the documents s.t. the distance between consecutive query term is <= 2?

I think the best idea is to define proximity as follows: 'All query terms must be contained within a window of n terms'. In this case, if Window is less than num_query_terms then we have two options

1) window is set to num_query_terms
2) return nothing

Per-term radius proximity is different I think.

Option 1 sounds better to me. If you want, I can re-implement the class. Can you attach your test case, please?

I recall that Richard and I agreed that the Distance class was appropriate to use for this class.

Committed patch and test case for interpretation 'All query terms must be contained within a window of n terms'. Window is set to num_query_terms if window is less than num_query_terms.

Commit 3754.

Resolve?

Related note:

The patch uses the local isInWindow method rather than Distance.noTimes method

Either implementation should be valid, but each will be faster in different use cases.
isInWindow will be faster for long documents when the query terms appear only rarely. (Complexity: |Q| . window . occurences(Q,d))
Distance.noTimes will be faster when the query terms appear often in a document. (Complexity: |Q| . documentLength-window)

Do you have numbers to prove this?
Also, does isInWindow() pass similar tests to Distance.noTimes
Could the method be moved to the Distance class, to keep everything in the same place?

Did a test of Distance.noTimes for the proximity, but it fails all of the tests. Looking at the Distance test case, I think that noTimes is looking for n-grams not term sets in windows.

If so, it is not applicable for this issue.

Current implementation passes all of the unit tests. Resolving this issue.

Query language documentation should be updated to describe what this functionality does and how it differs from proximity score modifiers.