documentation/protocol issue with peek_ready()

[QuadeHale]

peek_ready gives the first job in the using() tube, not the first job you would get from watching().

The documentation says:
To peek at the same job that would be returned by reserve -- the next ready job -- use peek-ready:

When in reality, peek_ready() returns the next job that will be consumed on the tube you are using, not watching. This completely threw me for a loop.

I wanted to double check and make sure this was intentional and confirmed before I changed the docs.

[earl]

Thanks a lot for this careful attention, and my apologies for the confusion and derailment this has caused. You are absolutely correct, the quoted sentence is just plain wrong. I'm quite embarrassed that it survived for so long.

From the protocol specification:

The peek commands let the client inspect a job in the system. There are four variations [ed: peek, peek-ready, peek-delayed, peek-buried]. All but the first operate only on the currently used tube.

I'd very much appreciate if you go ahead and submit a pull request to fix this so that you are properly attributed as committer as well. If that's too much of a hassle, just let me know, and I'll push a fix with an attribution in the commit message.

[QuadeHale]

I had totally forgotten about this. I'd rather you made the change yourself, if that's okay.