Prevent monit7 from exiting for inadvertent escape sequences

[wehimwich]

@jfhquick reported that monit7 exits for key combinations that generate escape sequences while the window has the focus. An example is <Ctrl>+<Alt>+<Down>. Not exiting on <Escape> would avoid this, but other characters in the escape sequences can cause monit7 to do unexpected things. It is not clear that it would be easy to filter out escape sequences in general (suggestions welcome!), but @jfhquick suggested that they might be detected by the arrival rate of the characters. In the meantime if they are causing a problem, particular combinations that are troublesome they can be filtered out using settings in ~/.Xresources or maybe in the window manager configuration.

[wehimwich]

Using escape sequence removal for the "CSI sequences" at ANSI escape code might be a solution. Testing suggests that it would handle the escape sequences generated by the available terminal key combinations.

The sticky issue would be what to do if the user hits an inadvertent<Escape>, thereby triggering escape sequence processing. That could be handled by treating anything other than [ after an initial <Escape> as new input, i.e., not part of the current escape sequence (but possibly the start of a new escape sequence). This would also handle repeated <Escape>s (auto-repeat). Similarly any other out-of-order character in an escape sequence could just be considered new input.

I doubt we can handle arbitrary escape-like sequences entered by the user, either accidentally or intentional. In come cases, some characters intended as commands could be absorbed into the escape sequence processing. The approach in this post would handle the most likely inadvertent key presses (desktop key combinations and <Escape>) without any visible effects. Currently [ is not a monit7 command and it would be good to avoid making it one in the future.

Not having a time-out (for arrival rate) avoids having to distinguish between input pauses and network delays OR having a one-size solution that does not fit both cases.

Writing an interpreter is a fraught business, even for a small one like this!