* After installation, SciTECO will therefore start into a more userfriendly mode
  even if the user does not create a custom ~/.teco_ini.
  It is hoped that this will scare away less of new users, who
  are not willing to read through all of the documentation.
  Still, users are warned in the absence of ~/.teco_ini.
  This warning however, might not be immediately visible, especially
  not when running gsciteco without an attached console.
  (This will change once I redo the UI and allow a number of messages
  to be queued in the message area.)
* Theoretically, you could also just extend fallback.teco_ini from ~/.teco_ini,
  but that would require installing it into $SCITECOPATH.
* Since the fallback profile will now be munged automatically
  on a wide range of systems, we set up xclip only when detecting X11
  ($DISPLAY is non-empty).
  E.g. when running under Wayland or the Linux console, you still won't
  get the clipboard registers, which is probably better than having the
  clipboard operations fail once you try to use them.
* xclip is now "suggested" on Debian/Ubuntu.
  Unfortunately we cannot pull it in only in the presence of X11.

* As an alternative to OSC-52, which is rarely supported by terminal emulators.
* Makes the new mouse support much more useful since you rely on good builtin
  clipboard support. You can no longer e.g. just double-click a word to copy it into
  the "primary" selection as terminal emulators do by default.
* Set $SCITECO_CLIPBOARD_SET/GET e.g. to xclip, way-copy, pbcopy or some wrapper script.
* This is currently using POSIX-specific popen() API, so it behaves a bit different
  to command execution via EC/EG.
  I am not sure if it's worth rewriting with the GSpawn-API, since it will be used
  only on POSIX anyway and a GSpawn-based implementation is likely to be a bit larger.
* Should there be some small command-line utility for interacting (esp. pasting) via OSC-52,
  built-in OSC-52 support could well be removed from SciTECO.
  Currently, I know only of https://github.com/theimpostor/osc/ and it requires
  very recent Go compilers. (I still haven't tested it. Quite possibly, pasting when run as
  a piped command is impossible.)

* 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 is done via the new opener.tes in the standard library.
* Some programs that use $EDITOR expect the +line syntax to work.
* You can copy filename:line:column directly from GCC error messages
  and filename:line from grep output.
* Since there may be safe file names beginning with "+" or containing colons,
  there needs to be a way to turn this off, especially for scripts that don't
  know anything about the filenames to open.
  This is done with "--".
  Unfortunately, the first "--", that stops parameter processing,
  is always removed from the command line and not passed down into TECO land.
  This is not a problem for stand-alone scripts,
  since the script filename is already stopping option processing, so "--"
  would get passed down.
  But when calling the profile via `sciteco -- ...`, you could prevent leading
  minus signs to cause problems but since the `--` is removed, opener.tes cannot
  use it as a hint.
  Therefore, we introduced `-S` as a new alternative to `--`, that's always passed
  down as `--` (i.e. it is equivalent to "-- --").
  In other words, `sciteco -S *` will always open exactly the specified files
  without any danger of misinterpreting certain file names.
  Should we ever switch to a custom option parsing algorithm, we might preserve
  "--" (unless after --mung) and thus get rid of "-S".
* This advanced behavior can be tweaked by the user relatively easily.
  In the easiest case, we could replace M[opener] with
  <:L;R 0X.f [* @EB/^EN.f/ ]* L>
  in ~/.teco_ini to completely disable the special syntax.

* The previous convention of !* ... *! are now true block comments,
  i.e. they are parsed faster, don't spam the goto table and allow
  embedding of exclamation marks - only "*!" terminates the comment.
* It is therefore now forbidden to have goto labels beginning with "*".
* Also support "!!" to introduce EOL comments (like C++'s //).
  This disallows empty labels, but they weren't useful anyway.
  This is the shortest way to begin a comment.
* All comment labels have been converted to true comments, to ensure
  that syntax highlighting works correctly.
  EOL comments are used for single line commented-out code, since it's
  easiest to uncomment - you don't have to jump to the line end.
  This is a pure convention / coding style.
  Other people might do it differently.
* It's of course still possible to abuse goto labels as comments
  as TECO did for ages.
* In lexing / syntax highlighting, labels and comments are highlighted differently.
* When syntax highlighting, a single "!" will first be highlighted as a label
  since it's not yet unambiguous. Once you type the second character (* or !),
  the first character is retroactively styled as a comment as well.

* The XTerm version is still checked if we detect running under XTerm.
* Actually, the XTerm implementation is broken for Unicode clipboard contents.
* Kitty supports OSC-52, but you __must__ enable read-clipboard.
  With read-clipboard-ask, there will be a timeout.
  But we cannot read without a timeout since otherwise we would hang indefinitely
  if the escape sequence turns out to not work.
* For urxvt, I have hacked an existing extension:
  https://gist.github.com/rhaberkorn/d7406420b69841ebbcab97548e38b37d
* st currently supports only setting the clipboard, but not querying it.

* Practically requires one of the "Nerd Font" fonts,
  so it's disabled by default.
  Add 0,512ED to the profile to enable them.
* The new ED flag could be used to control Gtk icons as well,
  but they are left always-enabled for the time being.
  Is there any reason anybody would like to disable icons in Gtk?
* The list of icons has been adapted and extended from exa:
  https://github.com/ogham/exa/blob/master/src/output/icons.rs
* The icons are hardcoded as presorted lists,
  so we can binary search them.
  This could change in the future. If there is any demand,
  they could be made configurable via Q-Registers as well.

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