* The old heuristics - scroll if dot changes after key press -
  turned out to be too simplistic.
  They broke the clang-format macro (M#cf), which left the view at the
  top of the document since the entire document is temporarily erased.
  Other simplified examples of this bug would be:
  @^Um{[: HECcat$ ]:} Mm
  Or even: @^Um{[: H@X.aG.a ]:} Mm
* Actually, the heuristics could be tricked even without deleting any
  significant amount of text from the buffer.
  The following test case replaces the previous character with a linefeed
  in a single key press:
  @^Um{-DI^J$} Mm
  If executed on the last visible line, dot wouldn't be scrolled into the view
  since it did not change.
* At the same time, we'd like to keep the existing mouse scroll behavior from
  fnkeys.tes, which is allowed to scroll dot outside of the visible area.
  Therefore, dot is scrolled into view always, except after mouse events.
  You may have to call SCI_SCROLLCARET manually in the ^KMOUSE macro,
  which is arguably not always straight forward.
* Some macros like M#cf may still leave the vertical scrolling position
  in unexpected positions. This could either be fixed by eradicating all
  remaining automatic scrolling from Scintilla or by explicitly restoring
  the vertical position from the macro (FIXME).
* This was broken since the introduction of mouse support,
  so it wasn't in v2.3.0.

Also makes sense since all other GObject classes are in separate files.

* The old implementation would scroll only once for the file first opened and too early.
  As a result, opening via `sciteco file:number` did not always scroll to the correct position.
  Also, `?` would usually not scroll the topic into view.
* Instead, we now always scroll in all views, but only if the size allocation changed.
  This ensures, we can still scroll with the mouse wheel.
* Therefore, we have to store the current size allocation per view.
  Instead of allocating a separate heap object, I decided to subclass the Scintilla GTK class.
* Some explicit casts are still necessary since teco_view_t is typedefed
  to `struct teco_view_t`, but we cannot easily rename the GObject instance structure.

* By default, use the "text" cursor - this is the default Scintilla cursor, but
  inhibited by the GtkEventBox I used to catch all input events.
* When processing input events, the cursor is changed to "wait".
  This is done with a small delay in order to avoid flickering during normal typing.
  The cursor is only changed after 100ms of activity, i.e. only when executing long loops
  or external programs.
* We use the raw GSource API since it's tricky to work with source ids if the
  source could be removed in the meantime.
* The popup entries' cursor is also changed to "pointer" (hand) to give a hint that
  it can be clicked.

* At the SciTECO API level (-nEJ), there are no double clicks.
  We must therefore ignore the GDK_2BUTTON_PRESS and GDK_3BUTTON_PRESS events,
  that are delivered when GTK detects double or triple clicks.
  They are only sent in addition to GDK_BUTTON_PRESS, so it's safe to
  simply ignore them.
* This was causing spurious RELEASED events, which were confusing the ^KMOUSE
  macro from fnkeys.tes, causing the wrong buffer range to be inserted into the
  command line.

* Curses allows scrolling with the scroll wheel at least
  if mouse support is enabled via ED flags.
  Gtk always supported that.
* Allow clicking on popup entries to fully autocomplete them.
  Since this behavior - just like auto completions - is parser state-dependant,
  I introduced a new state method (insert_completion_cb).
  All the implementations are currently in cmdline.c since there is some overlap
  with the process_edit_cmd_cb implementations.
* Fixed pressing undefined function keys while showing the popup.
  The popup area is no longer redrawn/replaced with the Scintilla view.
  Instead, continue to show the popup.

* Fixes scrolling with default ^KMOUSE macro from fnkeys.tes which adjusts
  the scroll position without changing dot.
  The unconditional SCI_SCROLLCARET would effectively prevent scrolling to any position
  that does not contain dot.

* 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 works by embedding the SciTECO parser and driving it always (exclusively)
  in parse-only mode.
* A new teco_state_t::style determines the Scintilla style for any character
  accepted in the given state.
* Therefore, the SciTECO lexer is always 100% exact and corresponds to the current
  SciTECO grammer - it does not have to be maintained separately.
  There are a few exceptions and tweaks, though.
* The contents of curly-brace escapes (`@^Uq{...}`) are rendered as ordinary
  code using a separate parser instance.
  This can be disabled with the lexer.sciteco.macrodef property.
  Unfortunately, SciTECO does not currently allow setting lexer properties (FIXME).
* Labels and comments are currently styled the same.
  This could change in the future once we introduce real comments.
* Lexers are usually implemented in C++, but I did not want to draw in C++.
  Especially not since we'd have to include parser.h and other SciTECO headers,
  that really do not want to keep C++-compatible.
  Instead, the lexer is implemented "in the container".
  @ES/SCI_SETILEXER/sciteco/ is internally translated to SCI_SETILEXER(NULL)
  and we get Scintilla notifications when styling the view becomes necessary.
  This is then centrally forwarded to the teco_lexer_style() which
  uses the ordinary teco_view_ssm() API for styling.
* Once the command line becomes a Scintilla view even on Curses,
  we can enabled syntax highlighting of the command line macro.