* The main interface is the `FT` command.
  `FT` was an undocumented Video TECO command for etags/ctags lookups.
  I don't want to exactly copy its interface, though.
* `FT` allows looking up symbol names,
  definitions and references.
* ctags will be supported via ctags-lsp.
  LSP support is more powerful though and works without
  regenerating TAGS files all the time.
  The LSP will also allow you to customize auto-completions
  using SciTECO itself (i.e. by writing a language server
  in SciTECO).
* For multiple results, `FT$` can be used to cycle through
  results - this should mimic repeated `S$` or `N$`.
* `:FT...$` does a fuzzy search. IMHO it's not important
  to return a status integer instead. `FT` will only
  really be used in interactive mode.
* Document synchronization is supported via hooks from
  ring.c and via Scintilla notifications.
* Currently, the LSP communication is based on blocking
  GIOChannels. This means that a misbehaving hanging
  server could "lock up" the entire editor (FIXME).
  Only on ncurses you can always kill the subprocess by
  pressing CTRL+C.
  We need helper functions in spawn.c to read and write
  with interruptions.
* The textDocument/didChange notification transmits
  not only all edits, but all files' contents as well
  during initial synchronization.
  Therefore it is optimized to write and JSON-escape
  data without copying them around in memory and without
  destroying the buffer gap.
* Use $SCITECO_LSP to configure the language server.
  You can also use `tee` to capture stdin and stdout.
  Perhaps $SCITECO_LSP should be saved in .teco_session,
  so you can change it between projects?
* $SCITECO_LSP_ROOT is used to point to the project's
  root directory. session.tes will set it up automatically.

Previously almost all glyph-to-byte offset conversions consulted
Scintilla's line index and counted characters on the resulting line.
For instance a simple expression like `.+1J` would scan the same line
twice completely, which would be very slow on pathologically long lines.
Even insertions did that due to having to update the ^Y ranges.
If you repeat such an operation over all characters as in `<.+1:J;>`
you would have complexity O(n^2) for n = line length.
Only commands with an explicit relative nature like `C` and `A` would
use teco_view_glyph2bytes_relative() which scans beginning at dot
as long as the relative movement is less than 1024 glyphs.

Wit the new heuristics almost all glyph-to-byte and byte-to-glyph
conversions can make use of that optimization.
This requires that dot must at all times be known in glyphs as well -
the byte position is managed by Scintilla (SCI_GETCURRENTPOS).
We therefore introduced teco_current_doc_set_dot() and
teco_current_doc_get_dot() to update dot in the current buffer or
Q-Register -- it cannot be stored along with the view since
Q-Registers share a single view.
A number of auxiliary functions have been introduced for
converting relative to a known (glyphs,bytes) offset pair
and for converting absolute and relative positions with regard
to the current doc and SCI_GETCURRENTPOS position.
Of course this is error-prone since the glyph and dot positions
are interdependant - they must always be kept in sync.

With these new optimizations even pathologically long lines can
(usually) be managed even in UTF-8 documents.
It does not address slow-downs in Scintilla's line layout, yet.
grosciteco.tes for instance runs twice as fast now.

* The terminal's default foreground and background colors
  are now used by default (`sciteco --no-profile`), so SciTECO
  integrates naturally into all terminal color schemes, even
  dark-on-bright ones.
* The default Scintilla colors use only 0x000000 (COLOR_BLACK) and 0xC0C0C0 (COLOR_WHITE)
  now.
* You can use `7EJ` to configure the default colors in color
  schemes or your profile.
  All existing color schemes had to disable default colors
  (`-1,-1,7EJ`) since they wouldn't look well otherwise.
* You may add `-1,7EJ` to ~/.teco_ini when using a terminal emulator
  with a washed-out palettized COLOR_BLACK.
  We cannot detect the terminal's default colors automatically.
* Scinterm updated to v6.0.
  We require a not-yet-upstreamed patch:
  https://github.com/orbitalquark/scinterm/pull/40
* In fact, we might decide not to support default colors at all in Scinterm,
  so this feature should be considered experimental.

* Had been broken since introduction in v2.3.0.
* This slowed down EQq<filename>$ on large files.

* Scinterm was simply rendering them as black, thus effectively
  breaking the Linux and FreeBSD vts with terminal.tes.
* I was considering to render light black as white on 8-color terminals,
  so it's always readable.
  However, if you add in A_BOLD there is a good chance that the
  color will end up grey - at least it does in the virtual terminals (consoles).
* There is no need to use bright colors in the Scintilla view defaults.
  E.g. 0xFFFFF is "light white".
  However on 8-color terminals this will be rendered like white anyway.
  The new defaults are closer to what terminal.tes does.

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

* It emits undo tokens which would bring internal datastructures - especially the undo stack -
  out of sync.
* We now document that teco_view_save_to_channel() will always be without undo token emission.

* FILENAME_MAX is a standard C macro, but it may be arbitrarily long on some platforms
  (like the popular GNU/Hurd). See:
  https://www.gnu.org/software/libc/manual/html_node/Limits-for-Files.html#index-FILENAME_005fMAX
* This means there is no portable macro for the maximum path length.
  You could perhaps define PATH_MAX to MAX_PATH on Windows.
* Instead, we use g_strdup_printf() to calculate the save point name.
  We avoid another g_build_filename() by prepending the directory in the printf().

* teco_file_get_absolute_path() does not currently guarantee to resolve
  non-existent parts of the path.
  When opening a symbolic link to a non-existing file, it would only
  be created when writing out the file.
  The undo token to remove it, however would remove the original
  unresolved path.
  When rubbing out the EW, the symlink would get removed instead
  of the newly written file.
* We now resolve/canonicalize the path again immediately after
  opening the new file, which should ensure that it resolves.
* As an alternative, we might have also tried to reliably canonicalize
  non-existent symlinks. This however is tricky and there would have
  to be a break condition to guard against cyclic symlinke.
  In the end there is no guarantee to be able to resolve a path
  exactly like the OS does.
  Therefore, teco_file_get_absolute_path() was not touched,
  not even on UNIX.
* A test case was not added since it would rely on creating real symlinks.
  It wouldn't work on MSYS when `ln -s` falls back to hardlinks.
  Perhaps other non-UNIX platforms would have similar restrictions.