Also, Scinterm had to be updated again since NetBSD curses stores up to 8 wchar_t per cell.

* Turns out that it works perfectly with the default --enable-malloc-replacement
  as malloc() is replaced globally.
* Added note to configure.ac that malloc() replacement may be useful on platforms
  without a global symbol namespace - you just have to link statically (--enable-static-executables)
  as well.
  This wasn't necessary on Haiku, though.
* Only the test suite required a minor fix since Haiku doesn't support `ulimit`.
* The Gtk interface is broken though on Haiku: You cannot type dead keys,
  Ctrl and AltGr combinations.
  Doesn't appear to be SciTECO-specific though. The libraries simply doesn't
  report modifiers. Appears to be a bug in Haiku's GTK 3 port,
  at least in their Beta5 branch. It can be reproduced with gtk-demo as well.
* This opens the door for contributing a port into HaikuPorts.
  This will probably be Curses-only for the time being (see above).

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

* In contrast to the old Github workflow, we can no longer create pkgs,
  but instead create tar balls. You don't necessarily have to unpack
  it into the root, though, since the binaries are relocatable.
* We cannot execute the resulting binaries, so the testsuite is no
  longer run under OS X. It could be executed with Darling, but only
  under Linux.
* Resulting binaries are currently apparently fully statically linked.

* The Knowledge Base replaces the Github wiki.
* The mailing lists replace the Github bug tracker, discussions and pull requests.