The previous version of MaybeDefault stores pointers to the Eq, Show, and Read instances of the defaulted value.
MaybeDefault is used with Style, Color, and Text. All of these types already have all of the necessary instances, and we never work with MaybeDefault generically. Defering the Show, Eq, and Read instances down to the SetTo case isn't helping us to work with types that don't have these instances.
This change adds a new 'strikethrough' Style value and uses the 'smxx'
and 'rmxx' Terminfo capabilities to activate and deactivate
strikethrough mode, respectively. If the terminfo does not report those
capabilities, this style is ignored.
For details, see
https://invisible-island.net/xterm/terminfo-contents.html#tic-ecma_strikeout
This change adds a new record field to the Input type to allow the end
user to have direct access to the logic needed to restore the terminal's
input state flags. Prior to this change, this state restoration logic
could only be invoked as part of calling 'shutdownInput', but since that
function does other things (like killing threads) it is not advisable to
call it repeatedly (which is necessary in the use case this change is
intended to support).
This change supports a use case where an application initializes
Vty repeatedly, with changes to the input state flags in between
initializations, but where the application wants to ensure that the
*final* input state flag configuration matches the terminal's condition
before Vty started handling input for the first time. This change allows
applications to access the state restoration for the initial Vty handle
by exposing the logic directly in a field of Input.
The input state restoration is still an implicit part of invoking
'shutdownInput' (and thus 'shutdown') so no user-facing changes are
required for applications that do not build their own Input structures.
Prior to this change, Vty would initialize the terminal by clearing the
flags it needed to clear. That is good, but it means that some flags
that were assumed to be enabled but not *explicitly* enabled by Vty
would cause trouble if they were not, in fact, enabled prior to Vty
initialization.
This comes up in (pathological?) cases where the terminal state prior to
Vty initialization is not what Vty assumes it will be, i.e., cases in
which some flags which are assumed to be set are not. We found this to
be true when an application (in this case vim) was terminated uncleanly,
leaving the terminal mode flags in a state that Vty did not anticipate.
To resolve this problem, this change explicitly sets one flag which we
now know to be required for Vty to function properly (the ICRNL flag).
