* Simplifies the common task of querying an integer or string from a Q-Register table.
* Undefined Q-Regs are reported as TECO_ERROR_QREGUNDEF, so you can theoretically
  handle this case. In practice however, it requires less boilerplating to
  just call teco_qreg_table_find() manually.
* It also doesn't make sense to use these functions when getting and setting
  a register at the same time as you will want to avoid repeated lookups.

This is useful when writing small macros directly on the
command-line as in `sciteco --eval`. If you use double quoted shell
strings, too many characters have to be escaped.
If you use single-quotes, though, embedding the conditional end (')
is annoying -- it would have to be written as '\''.

* terex is based on Henry Spencer's regular expression engine for Tcl.
  It is a hybrid NFA/DFA design which has better worst-time runtimes than
  the backtracking PCRE. Memory usage is also limited and can no longer
  increase catastrophically.
* It should no longer be possible to crash SciTECO with pathological
  searches.
* Since it reliably supports partial matches (REG_EXPECT) we can
  now enable the new backwards-search algorithm by default.
  This used to be broken because of a glib bug, which I already
  fixed. It would however take a long time until this ends up
  on the majority of glib installations.
* Regexp executions can still be quite slow if you are looking
  for a pattern at the end of a huge file, which can hang the editor,
  but this can now at least theoretically be solved by adding
  hooks into terex to poll for interruptions.
* We can now also get rid of a TECO-pattern to regexp translation
  step by directly generating terex tokens (TODO).
* Performance-wise terex appears to be slower than PCRE for simple
  forward searches even when linking everything with optimzations (FIXME).
* Having a stand-alone regular expression engine is also a huge
  step in getting rid of glib.

See also: https://git.fmsbw.de/terex/about/

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