* this is a SciTECO extension - it's not in TECO-11
* Allows for select-case-like constructs with default-clauses as in
  :Os.^EQa$
    !* default *!
  !s.foo!
    !* ... *!
  !s.bar!
    !* ... *!
* Consistent with nOlabel0,label1,...$ if <n> is out of range.
  Unfortunately this form of computed goto is not applicable when
  "selecting" by strings or non-consecutive integers.
* In order to continue after the <:O> statement, we must keep the
  program counter along with the label we were looking for.
  At the end of the macro, the PC is restored instead of throwing
  an error.
* Since that would be very inefficient in loops - where potentially
  all iterations would result in rescanning till the end of the
  macro - we now store a completed-flag in the goto table.
  If it is set while trying to :O to an unknown label, we can
  just continue execution.

* 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.

* regression introduced in 2baa14add6d9976c29b27cf4470bb458a0198694

* Instead of separate stand-alone commands, they are now allowed only immediately
  in front of the commands that accept them.
* The order is still insignificant if both `@` and `:` are accepted.
* The number of colon modifiers is now also checked.
  We basically get this for free.
* `@` has syntactic significance, so it could not be set conditionally anyway.
  Still, it was possible to provoke bugs were `@` was interpreted conditionally
  as in `@ 2<I/foo/$>`.
* Even when not causing bugs, a mistyped `@` would often influence the
  __next__ command, causing unexpected behavior, for instance when
  typing `@(233C)W`.
* While it was theoretically possible to set `:` conditionally, it could also
  be "passed through" accidentally to some command where it wasn't expected as in
  `:Ifoo$ C`.
  I do not know of any real useful application or idiom of a conditionally set `:`.
  If there would happen to be some kind of useful application, `:'` and `:|` could
  be re-allowed easily, though.
* I was condidering introducing a common parser state for modified commands,
  but that would have been tricky and introduce a lot of redundant command lists.
  So instead, we now simply everywhere check for excess modifiers.
  To simplify this task, teco_machine_main_transition_t now contains flags
  signaling whether the transition is allowed with `@` or `:` modifiers set.
  It currently only has to be checked in the start state, after `E` and `F`.

* @ES/SCI_SETILEXER/lib^@name/ now opens the lexer <name> in library <lib>.
* You need to define the environment variable $SCITECO_SCINTILLUA_LEXERS to point
  to the lexers/ subdirectory (containing the *.lua files).
  Perhaps this should default to the dirname of <lib>?
* The semantics of SCI_NAMEOFSTYLE have been changed:
  It now returns style ids when given style names, so you can actually write
  Scintillua lexer *.tes files.
  This will be superfluous if we had a way to return strings from Scintilla messages into
  Q-Registers, e.g. 23@EPq/SCI_NAMEOFSTYLE/.
* We now depend on gmodule as well, but it should always be part of glib.
  It does not change the library dependencies of any package.
  It might result in gmodule shared libraries to be bundled in the Win32 and Mac OS
  packages if they weren't already.

* The colon modifier can now occur 2 times.
  Specifying `@` more than once or `:` more than twice is an error now.
* Commands do not check for excess colon modifiers - almost every command would have
  to check it. Instead, a double colon will simply behave like a single colon on most
  commands.
* All search commands inherit the anchored semantics, but it's not very useful in some combinations
  like -::S, ::N or ::FK.
  That's why the `::` variants are not documented everywhere.
* The lexer.checkheader macro could be simplified and should also be faster now,
  speeding up startup.
  Eventually this macro can be made superfluous, e.g. by using 1:FB or 0,1^Q::S.

* Allows storing pattern matches into Q-Registers (^YXq).
* You can also refer to subpatterns marked by ^E[...] by passing a number > 0.
  This is equivalent to \0-9 references in many programming languages.
* It's especially useful for supporting TECO's equivalent of structural regular expressions.
  This will be done with additional macros.
* You can also simply back up to the beginning of an insertion or search.
  So I...$^SC leaves dot at the beginning of the insertion.
  S...$^SC leaves dot before the found pattern.
  This has been previously requested by users.
* Perhaps there should be ^Y string building characters as well to backreference
  in search-replacement commands (TODO).
  This means that the search commands would have to store the matched text itself
  in teco_range_t structures since FR deletes the matched text before
  processing the replacement string.
  It could also be made into a FR/FS-specific construct,
  so we don't fetch the substrings unnecessarily.
* This differs from DEC TECO in always returning the same range even after dot movements,
  since we are storing start/end byte positions instead of only the length.
  Also DEC TECO does not support fetching subpattern ranges.