# io.github.libtmux.TextOutcome.TextOutcome

- **Module:** io.github.libtmux.TextOutcome
- **Package:** io.github.libtmux:libtmux
- **Language:** Java
- **Kind:** enum
- **Source:** https://github.com/libtmux/libtmux-java/blob/842228310449e879ebcaa3f910597757c9dbffd6/libtmux/src/main/java/io/github/libtmux/TextOutcome.java#L18
- **Page:** https://libtmux.org/en/java/latest/reference/io-github-libtmux-textoutcome-textoutcome/

Why a wait for text on a pane ended.

Separate from {@link WakeReason}, which answers for a tmux channel, because this wait reads a
screen rather than blocking on a signal and so can end a way a channel never does: with the text
already there. A pane that has said {@code ready} since an hour ago must not answer a wait for
{@code ready} the way output that just arrived does, and it must not be reported as a timeout
either — a caller told only "not found" would go looking for text that is in plain sight.

{@link Pane#await(java.util.function.Predicate, Duration)} keeps {@link WakeReason}: a caller
wrote that condition and can test it before waiting, so the library is not the only thing that can
see it was already true.

## Members

- `APPEARED` (constant): The text appeared while the wait was running.
- `PRESENT_AT_ENTRY` (constant): The first look already showed the text, so this wait did not see it arrive.
- `TIMED_OUT` (constant): The deadline passed with the text absent.
- `SERVER_GONE` (constant): The server went away underneath the wait, so nothing it was guarding can be relied on.