setStatus() draws lines in place, cut to the width of the terminal, with
the cursor hidden and shown again on shutdown; the next write() erases
them and the next setStatus() draws them again below it. It takes whole
lines, so a status never erases output that did not end with one, and
nothing to draw erases the status instead of drawing an empty one.

It is the line rewriting every progress bar wrote by hand, and it does
nothing where the stream is not a terminal, so a redirected output holds
only the real lines.

2.0 has no compatibility layer. The skill in docs/skills rewrites 1.x
code faithfully and reports every place where 2.0 behaves differently.
The package ships it and the readme points to it.

Without the mode a Windows console may print the escape sequences as
text. It is switched on only for a stream that is a terminal.

NO_COLOR turned the colors off even when set to an empty string, and any
FORCE_COLOR, 0 included, turned them on. By the specs an empty NO_COLOR
means nothing, a non-empty one wins over everything, and FORCE_COLOR set
to 0 or false forces the colors off.

The bright colors were bold plus a dark color, and a bright background
collapsed to the dark one. Foregrounds are now 30-37 and 90-97,
backgrounds the same plus ten, so every one of the sixteen colors is
what its name says.

color() takes the text as its second argument, since a color without one
had no use, and a null color is no color at all, which spares the caller
a branch. An unknown name throws \InvalidArgumentException instead of an
undefined index, even when the colors are off, and so does anything but
a foreground and a background.

write() and writeLine() take the color of the whole text, which is what a
line of one color always meant: writeLine($text, 'red') instead of
writeLine($console->color('red', $text)). A line of several colors is
still composed of color() calls.

The settings shape the help only. hidden keeps a parameter out of the
help and the generated usage while it still works, defaultDescription
puts the default value into words and an empty string leaves it out, and
valueName names the value of an option, --output <file>.

Headings and paragraphs are items of the command beside its parameters,
in the order they were added. With a heading of their own the author
arranges the help, so no headings are added. The usage given to
new Command() or addCommand(), a line or a list of lines, replaces the
generated one and still opens the help.

HelpRenderer draws the help of any command: the generated usage, the
description, the items with an Options, Arguments or Commands heading in
front of every run of one kind, the inherited options under Global
options, a syntax column as wide as the longest syntax that still fits,
and descriptions with the default value, wrapped to the width of the
terminal or to a given one. Widths are measured by Ansi, so a colored
help wraps like the plain one.

render() writes the help to the console of the renderer, or to a new one
on STDOUT, and renderToString() returns it, plain without a console. It
takes the command as Parser does, colors only through its own roles and
never runs a normalizer; the colored output is the plain one in escape
sequences. Snapshots record the help of a program at three widths and in
color.

The width in columns, 80 when the stream of the console is not a
terminal. COLUMNS holding a positive integer wins and is read every
time, so a narrow terminal can be simulated. tput or mode con is asked
only on a real terminal, only once and not at all when exec() is
disabled.

A console is one stream and its colors and terminal follow that stream, so
an application writing to stdout and stderr makes one for each and a
redirected output cannot decide the colors of the other. Both answers can
be given to the constructor, which is what --no-color needs and what lets
a test drive a memory stream.

The static detectColors() and detectTerminal() became hasColors() and
isTerminal(), useColors() needs its argument, and writeLine() writes a
line. write() passes the text on as it is: stripping the escape sequences
with colors off is right for what a person reads and wrong for the content
of a file or a machine-readable format, which a console cannot tell apart,
so a caller printing the output of a subprocess drops the colors itself
with Ansi::strip().

An escape sequence takes no column, a grapheme cluster one and a wide
character two, so text that carries colors lines up in a column like the
plain one. measure() answers the width, pad() fills it up, truncate()
cuts to it and strip() takes the escape sequences away.

Nothing truncate() returns is ever wider than asked: an ellipsis that
would not fit is left out. It keeps the escape sequences of what it
drops, so a color it opened is still closed, and with keepEnd it cuts
the front, where a path is least interesting.

A program whose commands are its only sensible use does not have to
check for itself that the line named one. The parser throws "Missing
command." with the reason ParseError::MissingCommand, and a standalone
flag such as --help still answers.

A negatable flag parses as false when used as --no-color, so a flag that
is on by default can be switched off. The negation is a name like any
other, checked for conflicts and suggested for typos, and a negated
standalone flag does not answer.

--help has to work before the configuration is read and the paths are
resolved, even when a required argument is missing. Once the tokens are
read and the command is selected, a used standalone flag is true and
every other parameter of the path is its default; nothing is checked,
converted or demanded. The line itself still has to be valid.

A normalizer such as fn($v) => (int) $v silently turns 'abc' into 0 and
'1.8' into 1. int() and float() convert only what is really a number,
can keep it within a range, and report the rest as "Option --count:
expects an integer, 'abc' given." realPath() resolves a path and refuses
one that does not exist.

Given enum: Format::class, the allowed values are the values of its
cases and the value parses as the case itself, so the application gets
Format::Xml instead of 'xml'. The normalizer receives the case.

An enum also decides what an optional value may swallow: the next token
is taken when it is one of the values, so --color never works, while
nothing outside the enum, an argument or a command name, is ever read as
a value.

--count -1 failed as an unknown option -1. A token that looks like a
negative number is a value, unless an option of that name is valid at
the command, so -0 still works as a flag where a program defines it.

An unknown name within two edits of a known one gets a hint, "Unknown
option --verbos. Did you mean --verbose?". A short flag that is merely
another short flag is not suggested. An option of another command says
where it belongs instead of being unknown.

A token of several letters that is not a defined option is read as
-a -b -c when every letter is a single-letter flag; only the last one may
take a value. A defined multi-letter short option such as -vf stays what
it is.

The 1.x parser held the definition, parsed the line and printed a help
text it was given. It is gone together with addFromHelp(), addSwitch(),
parseOnly(), help(), isEmpty(), normalizeRealPath(), the constants,
Option and ValueType; 2.0 has no compatibility layer.

parse() reads the line against a Command and returns an immutable
Result, which is read like an array and carries the selected command as
a property. It runs in three phases: collect the raw occurrences while
following the command names down the tree, convert what was supplied,
fill in what was not. Presence is recorded apart from value, so a
normalizer may return null, a default never overwrites a given value
and wasProvided() tells a given value from the default. The line is
always read from the root and the valid options are those of the
selected command and its ancestors.

A bare option yields the literal true, which neither the enum check nor
the normalizer sees, and an optional value is only ever attached with =,
so it cannot swallow an argument or a command name. Invalid input throws
ParseException with the command in which the line went wrong, a
ParseError reason and the parameter; control characters of the line are
escaped in the messages.

Since nette/schema 1.4 an Expect::array() without a shape is an ArrayType,
not a plain Type, so the extension asks Expect::array() for the class the
same way the Expect::type() one does; up to 1.3 the answer stays Type.

Expect::type() declares Type (Type|AnyOf since schema 2.0), while the element
it returns depends on the expression: 'int' is a NumberType with min() and
max(), 'int|string' an AnyOf. The extension resolves a constant expression by
asking Expect::type() itself, so it needs no knowledge of the expression
language and its answer follows whatever the installed nette/schema builds; a
non-constant expression, or one the installed version refuses, keeps the
declared type.