docs: function (matcher) {
      var self = this;
  
      if (self._keyFilter)
        throw Error("called _useWithMatcher twice?");
  
      // If we are only sorting by distance, then we're not going to bother to
      // build a key filter.
      // XXX figure out how geoqueries interact with this stuff
      if (_.isEmpty(self._sortSpecParts))
        return;
  
      var selector = matcher._selector;
  
      // If the user just passed a literal function to find(), then we can't get a
      // key filter from it.
      if (_.isFunction(selector))
        return;
  
      var constraintsByPath = {};
      _.each(self._sortSpecParts, function (spec, i) {
        constraintsByPath[spec.path] = [];
      });
  
      _.each(selector, function (subSelector, key) {
        // XXX support $and and $or
  
        var constraints = constraintsByPath[key];
        if (!constraints)
          return;
  
        // XXX it looks like the real MongoDB implementation isn't "does the
        // regexp match" but "does the value fall into a range named by the
        // literal prefix of the regexp", ie "foo" in /^foo(bar|baz)+/  But
        // "does the regexp match" is a good approximation.
        if (_.isRegExp(subSelector)) {
          // As far as we can tell, using either of the options that both we and
          // MongoDB support ('i' and 'm') disables use of the key filter. This
          // makes sense: MongoDB mostly appears to be calculating ranges of an
          // index to use, which means it only cares about regexps that match
          // one range (with a literal prefix), and both 'i' and 'm' prevent the
          // literal prefix of the regexp from actually meaning one range.
          if (subSelector.ignoreCase || subSelector.multiline)
            return;
          constraints.push(regexpElementMatcher(subSelector));
          return;
        }
  
        if (isOperatorObject(subSelector)) {
          _.each(subSelector, function (operand, operator) {
            if (_.contains(['$lt', '$lte', '$gt', '$gte'], operator)) {
              // XXX this depends on us knowing that these operators don't use any
              // of the arguments to compileElementSelector other than operand.
              constraints.push(
                ELEMENT_OPERATORS[operator].compileElementSelector(operand));
            }
  
            // See comments in the RegExp block above.
            if (operator === '$regex' && !subSelector.$options) {
              constraints.push(
                ELEMENT_OPERATORS.$regex.compileElementSelector(
                  operand, subSelector));
            }
  
            // XXX support {$exists: true}, $mod, $type, $in, $elemMatch
          });
          return;
        }
  
        // OK, it's an equality thing.
        constraints.push(equalityElementMatcher(subSelector));
      });
  
      // It appears that the first sort field is treated differently from the
      // others; we shouldn't create a key filter unless the first sort field is
      // restricted, though after that point we can restrict the other sort fields
      // or not as we wish.
      if (_.isEmpty(constraintsByPath[self._sortSpecParts[0].path]))
        return;
  
      self._keyFilter = function (key) {
        return _.all(self._sortSpecParts, function (specPart, index) {
          return _.all(constraintsByPath[specPart.path], function (f) {
            return f(key[index]);
          });
        });
      };
    }