bugfix: ivy does not support symbolic require-match values to completing-read

[equwal]

This bug affects sly, which uses 'require-match as the value to the argument named require-match instead of a boolean argument (which is perfectly legal!) to completing-read-function.

joaotavora/sly#296

Here is the relevant portion of the docstring from completing-read

REQUIRE-MATCH can take the following values:
- t means that the user is not allowed to exit unless the input is (or
  completes to) an element of COLLECTION or is null.
- nil means that the user can exit with any input.
- `confirm' means that the user can exit with anyt input, but she needs
  to confirm her choice if the input is not an element of COLLECTION.
- `confirm-after-completion' means that the user can exit with any
  input, but she needs to confirm her choice if she called
  `minibuffer-complete' right before `minibuffer-complete-and-exit'
  and the input is not an element of COLLECTION.
- anything else behaves like t except that typing RET does not exit if it
  does non-null completion.

The fourth one is the expected behaviour.

[abo-abo]

Thanks.

[basil-conto]

I think there's a misunderstanding here. In Elisp, and returns either nil or its final argument, without casting non-nil values to t. That means that, when both collection and require-match are non-nil, (and collection require-match) evaluates to the same value as require-match.

So, I'm really curious how this PR could affect anything in either Ivy or SLY.

[basil-conto]

So, I'm really curious how this PR could affect anything in either Ivy or SLY.

In the meantime, I've reverted the logic change in commit 9180550.