* An empty message line would actually contain "(Unnamed)".
* Info popups must discern the "(Unnamed)" string (e.g. a file with that name)
  from the actual unnamed buffer since when clicking the unnamed buffer, you
  must insert nothing (`EB$`). Therefore, the unnamed buffer is represented
  as an empty string. "(Unnamed)" is just a placeholder for rendering.
  This was carried over into TecoGtkLabel which always rendered the empty string
  as "(Unnamed)".
  But TecoGtkLabels are used for the info and message lines as well.
* Therefore the fallback/placeholder string is now configurable per label.
* On the downside, this wastes one more machine word per TecoGtkLabel.
  The alternative would have been to use {NULL, 0} as the representation
  for unnamed buffers, so you can actually discern the empty string from the
  unnamed buffer representation.
  However it feels wrong to have this kind of info-popup-specific handling
  in a more generic label widget.
  Also, for consistency we'd have to touch the Curses UI as well where
  the unnamed buffer is also currently internally represented by empty
  strings (as opposed to NULL).
* Regression introduced by 0c89fb700957e411885e7e7835e15f441e8b5e84,
  so it was in v2.5.0.

This is useful to launch from a terminal without "blocking" this terminal.
There are tools like nohup and daemonize (BSD) to do the same, but having it
builtin is shorter to write.

* When passing a struct that should not be modified, I usually use a const pointer.
* Strings however are small 2-word objects and they are often now already passed via separate
  `gchar*` and gsize parameters. So it is consistent to pass teco_string_t by value as well.
  A teco_string_t will usually fit into registers just like a pointer.
* It's now obvious which function just _uses_ and which function _modifies_ a string.
  There is also no chance to pass a NULL pointer to those functions.

* When constructing the list of popup items, the unnamed buffer is stored as the empty string
  instead of a prerendered "(Unnamed)".
  Using the empty string simplifies autocompletions, which will actually have to insert nothing
  at all (in addition to terminating the string).
* Since unnamed buffers are now special in the popup list, we can render them with special
  icons as well.
  Currently, only on Curses we use a file symbol with a question mark.
  There doesn't appear to be a fitting standard Freedesktop icon to use on GTK and there
  isn't even any fitting standard emblem to lay over the default file icon.

* Other editors call "backup files" previous copies of saved files.
  This role would be served by savepoint files in SciTECO.
* Likewise filename~ would point to such a backup file.
  It therefore makes sense that savepoint files also end in tildes (.teco-n-filename~).
* Security copies of modified buffers would be called "auto-saves" (Emacs) or
  "swap files" (Vim).
  Both of these terms is IMHO misleading, so SciTECO now uses the
  term "recovery file".
* "Recovery files" are now named #filename# just like in Emacs.

* The backup mechanism is supposed to guard against crashes of SciTECO and
  unexpected program terminations (e.g. power cycling, etc.)
* In a given interval (no matter whether busy or idlying on the prompt)
  SciTECO saves all modified buffers with the filename~ (like most other editors).
  As an optimization files are not backed up if they have been backed up
  previously to avoid pointless and possibly slow file system writes.
* While the backup mechanism exists outside of the usual undo-paradigm -
  backup file creating is not bound to character input and it makes no sense
  to restore the exact state of backup files - there are some interesting
  interactions:
  * When a buffer is dirtyfied or saved that was previously backed up, it must always
    be reset to the DIRTY state on rubout, so backups are eventually recreated.
  * When a buffer is dirtyfied first (was clean), the backup file must be
    removed on rubout as well - we don't expect backup files for clean buffers.
* There is currently no automatic way to restore backup files.
  This could potentially be done by opener.tes and session.tes in the future,
  although you couldn't currently always get meaningful user feedback
  (whether he wants to restore the file).
  Perhaps we should at least log a message when detecting backup files that
  are newer than the file that is being opened.

We cannot rely on the central teco_cmdline_update() call per keypress
in this case.
The analogous call was removed in 4e6ddd6c329d56055a732c6344df019f0d997aaf,
so this was a recent regression.

* This allows for several customizations.
  * You can simply increase the visible command line history.
    For that you must also set SCI_SETWRAPMODE(SC_WRAP_CHAR).
    An example was added to fallback.teco_ini.
  * You could also set SCI_SETLINEENDTYPESALLOWED(SC_LINE_END_TYPE_DEFAULT)
    to see the structure of inserted text.
* Alternatively we could have introduced a new command like EP or FW
  and also overload it to replace the current ED&2048 (e.g. -EP and EP).
  In DEC TECO `W` comes closest to what 5EJ now does.