* ALL keypresses (the UTF-8 sequences resulting from key presses) can now be remapped.
* This is especially useful with Unicode support, as you might want to alias
  international characters to their corresponding latin form in the start state,
  so you don't have to change keyboard layouts so often.
  This is done automatically in Gtk, where we have hardware key press information,
  but has to be done with key macros in Curses.
  There is a new key mask 4 (bit 3) for that purpose now.
* Also, you might want to define non-ANSI letters to perform special functions in
  the start state where it won't be accepted by the parser anyway.
  Suppose you have a macro M→, you could define
  @^U[^K→]{m→} 1^_U[^K→]
  This effectively "extends" the parser and allow you to call macro "→" by a single
  key press. See also #5.
* The register prefix has been changed from ^F (for function) to ^K (for key).
  This is the only thing you have to change in order to migrate existing
  function key macros.
* Key macros are enabled by default. There is no longer any way to disable
  function key handling in curses, as I never found any reason or need to disable it.
  Theoretically, the default ESCDELAY could turn out to be too small and function
  keys don't get through. I doubt that's possible unless on extremely slow serial lines.
  Even then, you'd have to increase ESCDELAY and instead of disabling function keys
  simply define an escape surrogate.
* The ED flag has been removed and its place is reserved for a future mouse support flag
  (which does make sense to disable in curses sometimes).
  fnkeys.tes is consequently also enabled by default in sample.teco_ini.
* Key macros are handled as an unit. If one character results in an error,
  the entire string is rubbed out.
  This fixes the "CLOSE" key on Gtk.
  It also makes sure that the original error message is preserved and not overwritten
  by some subsequent syntax error.
  It was never useful that we kept inserting characters after the first error.

* When enabled with bit 2 in the ED flags (0,4ED),
  all registers and buffers will get the raw ANSI encoding (as if 0EE had been
  called on them).
  You can still manually change the encoding, eg. by calling 65001EE afterwards.
* Also the ANSI mode sets up character representations for all bytes >= 0x80.
  This is currently done only depending on the ED flag, not when setting 0EE.
* Since setting 16,4ED for 8-bit clean editing in a macro can be tricky -
  the default unnamed buffer will still be at UTF-8 and at least a bunch
  of environment registers as well - we added the command line option
  `--8bit` (short `-8`) which configures the ED flags very early on.
  As another advantage you can mung the profile in 8-bit mode as well
  when using SciTECO as a sort of interactive hex editor.
* Disable UTF-8 checks in 8-bit clean mode (sample.teco_ini).

* There isn't much we can do anyway.
  We can detect if it's Unicode and otherwise default to _some_ codepage.
  However, we do not even known which codepage should be preferred.
* This is actually trivial to implement in pure SciTECO.
  Having it in the profile gives you the ability to customize the default non-UTF code page.
  E.g. if you are working a lot with KOI-8 documents, you could change <1EE> to <204EE>.
* Since the Unicode validity check is a noticable slowdown,
  we limit it to the first 1024 bytes.
  This speeds up startup significantly compared to checking all codepoints in every document.

* ^E is heavily overloaded and can also be used to check whether a given index is valid
  (as it is the same that most movement commands to internally).
  Besides that, it is mainly useful for interfacing with Scintilla messages.
* EE takes a code page or 0 for ANSI/ASCII.
  Currently all documents and new registers are UTF-8.
  There will have to be some kind of codepage inheritance and a single-byte-only mode.

* Horizontal movements (left/right cursor keys) establish the current column
  and vertical movements (up/down) will try to keep on that column.
* This has long been problematic in SciTECO as it requires state that gets
  reversed when the command line replacement takes place.
* I experimented with encoding the current horizontal position into the braced
  movement operations as in (123C5U$), but I decided that this was clumsy and
  I generally did not want these expressions to become even larger.
* Instead I decided to add some minimal support to the C core in the form of 4EJ
  which is like a number register only that it does NOT get reversed on rubout.
  This is exploited by the fnkeys.tes macros by storing the current position
  beyond replacements.
* In theory, this should be a property of the document, but we cannot easily
  store custom parameters per document.
  So instead, there is just one global variable.
  When editing another buffer, it gets reset to .ESGETCOLUMN$$.
  sample.teco_ini has been updated.
* The current X position only makes sense in the context of fnkeys.tes, as
  TECO commands like <C> are not necessarily "horizonal" movements.
  For the same reason, the core does not try to initialize 4EJ automatically
  when editing new buffers.
  It's entirely left to the TECO macros.
* The commandline replacement is more robust now as it checks braced
  expressions at the end of the command line more thorougly.
  It will no longer swallow all preceding braced expressions.
  Only if they are at least 4 characters in length and end in `C)` or `R)`.

* The lexer.test.* macros don't work on the unnamed buffer,
  so any per-language indention settings etc. could be accidentally
  applied to the unnamed buffer.

 * when enabled, it will automatically upper-case all
   one or two letter commands (which are case insensitive).
 * also affects the up-carret control commands, so they when inserted
   they look more like real control commands.
 * specifically does not affect case-insensitive Q-Register specifications
 * the result are command lines that are better readable and conform
   to the coding style used in SciTECO's standard library.
   This eases reusing command lines as well.
 * Consequently, string-building and pattern match characters should
   be case-folded as well, but they aren't currently since
   State::process_edit_cmd() does not have sufficient insight
   into the MicroStateMachines. Also, it could not be delegated
   to the MicroStateMachines.
   Perhaps they should be abandoned in favour of embeddedable
   regular state machines; or regular state machines with a stack
   of return states?

 * the new "?" (help) command can be used to look up
   help topics.
 * help topics are index from $SCITECOPATH/women/*.woman.tec
   files.
 * looking up a help topic opens the corresponding "womanpage"
   and jumps to the position of the topic (it acts like an anchor
   into the document).
 * styling is performed by *.woman.tec files.
 * Setting up the Scintilla view and munging the *.tec file
   is performed by the new "woman.tes" lexer.
   On supporting UIs (Gtk), womanpages are shown in a variable-width
   font.
 * Woman pages are usually not hand-written, but generated from manpages.
   A special Groff post-processor grosciteco has been introduced for this
   purpose. It is much like grotty, but can output SciTECO macros for styling
   the document (ie. the *.woman.tec files).
   It is documented in its own man-page.
 * grosciteco also introduces sciteco.tmac - special Troff macros
   for controlling the formatting of the document in SciTECO.
   It also defines .SCITECO_TOPIC which can be used to mark up
   help topics/terms in Troff markup.
 * Woman pages are generated/formatted by grosciteco at compile-time, so
   they will work on platforms without Groff (ie. as on windows).
 * Groff has been added as a hard compile-time requirement.
 * The sciteco(1) and sciteco(7) man pages have been augmented with
   help topic anchors.