Andreas Lind

Hmm, yeah, we don't guard against circularity in the right hand-side of `to satisfy`. I don't think anyone imagined that being anything but a plain, non-circular object. It works fine...

Those are fine ideas! Would be nice to derive some principles and apply to other assertions, especially `to satisfy`.

Could take advantage of https://github.com/sunesimonsen/magicpen/issues/17 :)

Added your example as a failing test: https://github.com/unexpectedjs/unexpected/tree/fix/adaptErrorMessageToPreferredWidth Should be possible to hack something together in `createStandardErrorMessage.js`.

The old idea of compound assertions came up again today on the gitter channel as a solution to this problem and eliminate the need for the weird (and luckily undocumented)...

> That will still just be a hash lookup Yeah, exactly. It would just be something to try if we end up in the current "no matching assertion found" case....

Thinking about it a little more, I think it'll be sufficient to find the longest prefix of the assertion string that yields a supported assertion (the greedy algorithm) AND ends...

Cool, let's go for that, then. I agree that the limits should be communicated somehow. Maybe it would be possible to detect potential ambiguities at `addAssertion` time? The troublesome case...

A very simple (but breaking!) solution would be to always require `expect.it` for non-compound assertions: ```js expect([1, 2], 'to have items satisfying', expect.it('to be a number')); expect([1, 2], 'to have...

That sounds likely. Can you think of a way I can test your theory? I'm running with sharp's cache disabled via `require('sharp').cache(false)`. I assume this particular part of libvips' operation...