User messages printed in interative mode aren't currently fully preserved on stdout/stderr
since they are redirected to /dev/null.
Only messages that are not flushed out will be preserved.
Unless you redirect stdout/stderr of SciTECO of course since in this case no redirection
is necessary.

This is probably tolerable esp. once we support multi-line messages in the UIs.
At least it would be tricky to work around.

* Messages can be arbitrarily long, e.g. the following could provoke crashes in interactive mode
  `1000<@I/X/> HX$`
  It's hard to turn into a test case, though, as you could always increase the buffer
  size in teco_interface_msg().
* The message length is now only limited by RAM.
* This implementation is less effective, but code opting for efficience,
  including all programmable user messages, should not rely on the printf-API anyway
  but use teco_interface_msg_literal().

* In principle --stdin and --stdout could have been done in pure TECO code using the
  <^T> command.
  Having built-in command-line arguments however has several advantages:
  * Significantly faster than reading byte-wise with ^T.
  * Performs EOL normalization unless specifying --8bit of course.
  * Significantly shortens command-lines.
    `sciteco -qio` and `sciteco -qi` can be real replacements for sed and awk.
* You can even place SciTECO into the middle of a pipeline while editing
  interactively:
  foo | sciteco -qio --no-profile | bar
  Unfortunately, this will not currently work when munging the profile
  as command-line parameters are also transmitted via the unnamed buffer.
  This should be changed to use special Q-registers (FIXME).
* --quiet can help to improve the test suite (TODO).
  Should probably be the default in TE_CHECK().
* --stdin and --stdout allow to simplify many SciTECO scripts, avoiding
  temporary files, especially for womenpage generation (TODO).
* For processing potentially infinite streams, you will still have to
  read using ^T.

* n:^T always prints bytes (cf. :^A)
* ^T without arguments returns a codepoint or byte from stdin.
  In interactive mode, this currentply places a cursor in the message line and waits for a keypress.

* Greatly improved usability as a scripting language.
* The command is in DEC TECO, but in contrast to DEC TECO, we also
  support string building constructs in ^A.
* Required some refactoring: As we want it to write everything verbatim
  to stdout, the per-interface method is now teco_interface_msg_literal()
  and it has to deal with unprintable characters.
  When displaying in the UI, we use teco_curses_format_str() and TecoGtkLabel
  functions/widgets to deal with possible control codes.
* Numbers printed with `=` have to be written with a trailing linefeed,
  which would also be visible as a reverse "LF" in the UI.
  Not sure whether this is acceptable - the alternative would be to strip
  the strings before displaying them.
* Messages written to stdout are also auto-flushed at the moment.
  In the future we might want to put flushing under control of the language.
  Perhaps :^A could inhibit the flushing.

* You need to set 0,64ED to enable mouse processing in Curses.
  It is always enabled in Gtk as it should never make the experience worse.
  sample.teco_ini enables mouse support, since this should be the new default.
  `sciteco --no-profile` won't have it enabled, though.
* On curses, it requires the ncurses mouse protocol version 2, which will
  also be supported by PDCurses.
* Similar to the Curses API, a special key macro ^KMOUSE is inserted if any of the supported
  mouse events has been detected.
* You can then use -EJ to get the type of mouse event, which can be used
  with a computed goto in the command-line editing macro.
  Alternatively, this could have been solved with separate ^KMOUSE:PRESSED,
  ^KMOUSE:RELEASED etc. pseudo-key macros.
* The default ^KMOUSE implementation in fnkeys.tes supports the following:
  * Left click: Edit command line to jump to position.
  * Ctrl+left click: Jump to beginning of line.
  * Right click: Insert position or position range (when dragging).
  * Double right click: insert range for word under cursor
  * Ctrl+right click: Insert beginning of line
  * Scroll wheel: scrolls (faster with shift)
  * Ctrl+scroll wheel: zoom (GTK-only)
* Currently, there is no visual feedback when "selecting" ranges
  via right-click+drag.
  This would be tricky to do and most terminal emulators do not appear
  to support continuous mouse updates.

* this works by embedding the SciTECO parser and driving it always (exclusively)
  in parse-only mode.
* A new teco_state_t::style determines the Scintilla style for any character
  accepted in the given state.
* Therefore, the SciTECO lexer is always 100% exact and corresponds to the current
  SciTECO grammer - it does not have to be maintained separately.
  There are a few exceptions and tweaks, though.
* The contents of curly-brace escapes (`@^Uq{...}`) are rendered as ordinary
  code using a separate parser instance.
  This can be disabled with the lexer.sciteco.macrodef property.
  Unfortunately, SciTECO does not currently allow setting lexer properties (FIXME).
* Labels and comments are currently styled the same.
  This could change in the future once we introduce real comments.
* Lexers are usually implemented in C++, but I did not want to draw in C++.
  Especially not since we'd have to include parser.h and other SciTECO headers,
  that really do not want to keep C++-compatible.
  Instead, the lexer is implemented "in the container".
  @ES/SCI_SETILEXER/sciteco/ is internally translated to SCI_SETILEXER(NULL)
  and we get Scintilla notifications when styling the view becomes necessary.
  This is then centrally forwarded to the teco_lexer_style() which
  uses the ordinary teco_view_ssm() API for styling.
* Once the command line becomes a Scintilla view even on Curses,
  we can enabled syntax highlighting of the command line macro.

* this required adding several Q-Register vtable methods
* it should still be investigated whether the repeated calling of
  SCI_ALLOCATELINECHARACTERINDEX causes any overhead.