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

* It makes little sense to e.g. rub out until `I` in `@I/foo/`, but
  leave the `@` modifier.
  Modifiers have to be considered part of the command,
  even though the state machine is not currently modelled like that.

This was changed ages ago for some old version of Groff.
These workarounds should no longer be necessary.

* In string arguments, ^W first rubs out non-word chars (usually whitespace),
  so it makes sense if ^W would work analogously at the command level.
  A non-command would be one of the no-ops.

* All commands and their documentations were inconsistent.
  * ^W rubbed out to the beginning of words.
  * Shift+Right (fnkeys.tes) moved to the beginning of the next word if
    invoked at the beginning of a word and to the end of the next word otherwise.
  * <W> (and <V> and <Y> by extension) moved to the end of the next word.
  * The cheat sheet would claim that <W> moves to the beginning of the next word.
* Video TECO's <W> command would differ again from everything else.
  With positive arguments, it moved to the beginning of words, while
  with negative it moved to end of words.
  I decided not to copy this behavior.
* It has been decided to adopt a consistent beginning-of-words policy.
  -W therefore differs from Video TECO in moving to the beginning of the
  current or previous word.
* teco_find_words() is now based on parsing the document pointer, instead
  of relying on SCI_WORDENDPOSITION, since the latter cannot actually be
  used to skip strictly non-word characters.
  This requires a constant amount of Scintilla messages but will require fewer
  messages only when moving for more than 3 words.
* The semantics of <W> are therefore now consistent with Vim and Emacs as well.
* Shift+Right/Left is still based on SCI_WORDENDPOSITION, so it's behavior
  differs slightly from <W> for instance at the end of lines, as it will
  stop at linebreaks.
* Unfortunately, these changes will break lots of macros, among others
  the M#rf, M#sp and git.blame macros ("Useful macros" from the wiki).

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

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

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

* Allowing label redefinitions might have been useful when used as comments,
  since you will want to be able to define arbitrary comments.
  However as flow control constructs, this introduced a certain ambiguity since
  gotos might jump to different locations, depending on the progression
  of the parser.
* On the other hand, making label redefinition an error might disqualify labels as
  comments when writing or porting classic TECO code.
  Therefore, it has been made a warning as a compromise.
* Added test case

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