Tasks:
 * Wiki page about creating and maintaining lexer configurations.
   Also mention how to use the "lexer.test..." macros in the
   "edit" hook.

Known Bugs:
 * Gtk sometimes allows scrolling with the mouse when it shouldn't.
   All mouse events should currently be blocked.
 * Editing very large files, or at least files with very long lines, is painstakingly slow.
   Try for instance openrussian-custom-2023-10-09.sql.
   For some strange reason, this affects both Curses and GTK.
   In UTF-8 mode, this doesn't even load anytime soon.
 * PDCurses/WinGUI: There is still some flickering, but it got better
   since key macros update the command line only once.
   Could already be fixed upstream, see:
   https://github.com/Bill-Gray/PDCursesMod/issues/322
 * Win32: Interrupting <EC> will sometimes hang.
   Affects both PDCurses/WinGUI and Gtk.
   This no longer happens with ECbash -c 'while true; do true; done'$.
   However ECping -t 8.8.8.8$ still cannot be interrupted.
 * PDCurses/Win32: Crashes sometimes without any error message.
 * dlmalloc's malloc_trim() does not seem to free any resident memory
   after hitting the OOM limit, eg. after <%a>.
   Apparently an effect of HAVE_MORECORE (sbrk()) - some allocation is
   always left at the end.
 * S<LF>^ES^N<$ does not find the first line that does not begin with "<".
   This is because \s+ backtracks and can match shorter sequences.
   Perhaps ^ES should always be translated to \s++ (possessive quantifier)?
 * Colors are still wrong in Linux console even if TERM=linux-16color
   when using Solarized. Affects e.g. the message line which uses the
   reverse of STYLE_DEFAULT.
   Perhaps we must call init_color() before initializing color pairs
   (currently done by Scinterm).
 * Saving another user's file will only preserve the user when run as root.
   Generally, it is hard to ensure that a) save point files can be created
   and b) the file mode and ownership of re-created files can be preserved.
   We should fall back silently to an (inefficient) memory copy or temporary
   file strategy if this is detected.
 * Crashes on large files: S^EM^X$ (regexp: (.)+)
   Happens because the Glib regex engine is based on a recursive (backtracking)
   Perl regex library.
   I can provoke the problem only on Ubuntu 20.04.
   This is apparently impossible to fix as long as we do not
   have control over the regex engine build.
   We need something based on a non-backtracking Thompson's NFA with Unicode (UTF-8), see
   https://swtch.com/~rsc/regexp/
   Basically only RE2 would check all the boxes.
 * It is still possible to crash SciTECO using recursive functions,
   since they map to the C program's call stack.
   It is perhaps best to use another stack of
   macro strings and implement our own function calling.
 * SciTECO crashes can leave orphaned savepoint files lying around.
   Unfortunately, both the Windows and Linux ways of deleting files
   on close cannot be used here since that would disallow cheap
   savepoint restoration.
   * On UNIX, it's possible to open() and unlink() a file,
     avoiding any savepoint links.
     On abnormal program termination, the inodes are reclaimed
     automatically.
     Unfortunately, neither Linux, nor FreeBSD allow the re-linking
     based on file descriptors. On Linux this fails because the
     file's link count will be 0;
     On BSD linkat(AT_EMPTY_PATH) requires root privileges and does not
     work with unlinked files anyway.
   * Windows NT has hard links as well, but they don't work with
     file handles either.
     However, it could be possible to call
     CreateFile(FILE_FLAG_DELETE_ON_CLOSE) on the savepoint file,
     ensuring cleanup even on abnormal program termination.
     However, this flag cannot be cleared once we restore a save point,
     so we'd have to copy its contents just like in the UNIX case.
     There is also MoveFileEx(file, NULL, MOVEFILE_DELAY_UNTIL_REBOOT).
   * Windows has file system forks, but they can be orphaned just
     like ordinary files but are harder to locate and clean up manually.
 * Setting window title is broken on ncurses/XTerm.
   The necessary capabilities are usually not in the Terminfo database.
   Perhaps do some XTerm magic here. We can also restore
   window titles on exit using XTerm.
 * The XTerm OSC-52 clipboard feature appears to garble Unicode characters.
   This is apparently an XTerm bug, probably due to 8-bit-uncleanliness.
   It was verified by `printf "\e]52;c;?\a"` on the command line.
 * Glib (error) messages are not integrated with SciTECO's
   logging system.
 * Gtk on Unix: On ^Z, we do not suspend properly. The window is still shown.
   This would be a useful feature especially with --xembed on st.
   Perhaps we should try to catch SIGTSTP?
   This does not work with g_unix_signal_add(), though, so any
   workaround would be tricky.
   We could create a pipe via g_unix_open_pipe() which we
   write to using write() in a normal signal handler.
   We can then add a watcher using g_unix_fd_add() which will
   hide the main window.
   Unfortunately, it is also not trivial to get notified when
   the window has really been hidden/unrealized.
   Even if everything worked, it might well be annoying if
   you accidentally suspend your instance while not being
   connected to a terminal. Although this could be checked at runtime.
   Suspension from the command-line has therefore been disabled
   on Gtk for the time being.
 * Many Scintilla commands <ES> can easily crash the editor.
   A lot of the dangerous cases could be catched by parsing
   Scintilla.iface instead of the C header.
   This would also allow automatically mapping a part of the messages
   (property getters and setters) into the global Q-Reg space using
   special registers.
   This feature would especially be important in order to support
   e.g. the SCI_SETPROPERTY message with two strings in order to
   set lexer properties.
 * Mac OS: The colors are screwed up with the terminal.tes color scheme
   (and with --no-profile) under Mac OS terminal emulators.
   This does not happen under Linux with Darling.
   See https://github.com/rhaberkorn/sciteco/issues/12
 * File name autocompletion should take glob patterns into account.
   The simple reason is that if a filename really contains glob characters
   and you are trying to open it with EB, you might end up not being
   able to autocomplete it if a previous autocompletion inserted
   escaped glob patterns.
   Unfortunately, this would be very tricky to do right.
 * The git.blame macro is broken, at least on Git v2.45.2 and v2.25.1. Compare
   cat sample.teco_ini | git blame --incremental --contents - -- sample.teco_ini | grep -E '^[a-f0-9]{40}'
   (which is wrong and does not even contain all commits) with
   git blame --incremental --contents sample.teco_ini -- sample.teco_ini | grep -E '^[a-f0-9]{40}'
   which is correct. Without --incremental even the formatting is broken.
   This could well be a Git bug.
 * Margins, identions and the like are not configured on the unnamed
   buffer by sample.teco_ini.
   And this is probably correct.
   However when saving a new unnamed file for the first time,
   nothing will change either and it's tricky to apply the correct
   settings. You have to EF and EB the file after the initial
   save to get everything set up correctly.
   Or manually run 0M#ED, but this cannot be rubbed out.
   We need a "save" ED hook to get this right.
   For instance, you could check whether the margin is set up
   as a sign of whether lexing has already been applied.
   On the other hand, this Save also can't be properly rubbed out and
   will not restore the original margins and styling unless we add native
   commands for ALL of the Scintilla messages involved.
   Automatically running EF EB...$ in the "save" hook could
   also have unwanted side effects.
 * session.vcs does not properly work in MSYS2 environments.
 * At least the GTK version with --xembed is prone to unexpected
   crashes. Interestingly, while this does leave orphaned savepoint
   files around, it does not produce a core dump.

Features:
 * Auto-indention could be implemented via context-sensitive
   immediate editing commands similar to tab-expansion.
   Avoids having to make LF a magic character in insertion
   commands.
   Perhaps more flexible would be adding key macro states for
   insert commands with default escape chars.
   Then this could be part of fnkeys.tes.
 * :$ and :$$ to pop/return only single values
 * allow top-level macros to influence the proces return code.
   This can be used in macros to call $$ or ^C akin to exit(1).
 * Special macro assignment command.
   It could use the SciTECO parser for finding the end of the
   macro definition which is more reliable than @^Uq{}.
   Also this opens up new possibilities for optimizations.
   Macros could be special QRegs that are not backed by a
   Scintilla document but a normal string. This would immensely
   speed up macro calls.
   Perhaps more generically, we should add a number of alternative
   balanced string terminators (<> [] () {}) and assign one
   to parse SciTECO code. "' is not really an option here, since
   we want to be able to write @I"..." etc.
   Since ] and } can occur as stand-alone commands, we would have to
   use <> and/or () for SciTECO code parsing.
   The advantage would be that we save introducing a special
   assignment command and can use the same escape with @I<> for
   editing macro files while still getting immediate interactive
   syntax feedback.
   Plus: Once we have a parser-based terminator, there would
   be no more real need for command variants with disabled
   string building (as string building will naturally always
   be disabled in parser-terminator-mode).
   Instead, a special string building character for disabling
   string building character processing can be introduced,
   and all the command variants like EI and EU can be repurposed.
   Q-Reg specs should support alternative balanced escapes as well
   for symmetry.
 * Numbers could be separate states instead of stack operating
   commands. The current behaviour has few benefits.
   If a number is a regular command that stops parsing at the
   first invalid character in the current radix, we could write
   hexadcimal constants like 16^R0BEEF^D (still clumsy...).
   On the other hand, the radix is runtime state and parsing
   must not depend on runtime state in SciTECO to ensure
   parseability of the language.
   (Perhaps ^H should go to a special hexadecimal number state.)
   * Furthermore, this opens the possibility of floating point
     numbers. The "." command does not take arguments, so it
     could be part of the number syntax. This disallows constructs
     like "23." to push 23 and Dot which have to be replaced by
     "23,.".
   * In the most simple case, all TECO numbers could be
     floats/doubles with division/modulo having integer semantics.
     A separate floating point division operator could be introduced
     (e.g. ^/ with modulo being remapped to ^%).
   * SciTECO could also be "dynamically" typed by using
     integer and floating point types internally.
     The operator decides how to interpret the arguments
     and the return type.
   * Having a separate number parser state will simplify
     number syntax highlighting.
 * Key macro masking flag for the beginning of the command
   line. May be useful e.g. for solarized's F5 key (i.e. function
   key macros that need to terminate the command line as they
   cannot be rubbed out properly).
 * Key macros could support special escape sequences
   that allow us to modify the parser state reliably.
   E.g. one construct could expand to the current string argument's
   termination character (which may not be Escape).
   In combination with a special key macro state
   effective only in the start state of the string building
   state machine, perhaps only in insertion commands, this
   could be used to make the cursor movement keys work in
   insertion commands by automatically terminating the command.
   Even more simple, the function key flag could be effective
   only when the termination character is $.
 * Support more function keys.
   We can define more function keys via define_key(3NCURSES).
   Unfortunately they are not really standardized - st and urxvt for instance
   have different escape sequences for Ctrl+Up or Alt+Up.
   It seems they can be looked up with tigetstr() and
   then passed to define_key().
   Alternatively call use_extended_names(TRUE) and look up the
   key codes with key_defined().
   At the very least PDCurses and Gtk could support much more
   keys and Alt and Ctrl modifiers.
   See also https://stackoverflow.com/questions/31379824/how-to-get-control-characters-for-ctrlleft-from-terminfo-in-zsh
   https://gist.github.com/rkumar/1237091
 * Mouse support. Not that hard to implement. Mouse events
   use a pseudo key macro as in Curses.
   Using some special command, macros can query the current
   mouse state (this maps to an Interface method).
   This should be configurable via an ED flag as it changes
   the behavior of the terminal.
 * Support loading from stdin (--stdin) and writing to
   the current buffer to stdout on exit (--stdout).
   This will make it easy to write command line filters,
   We will need flags like and --quiet with
   single-letter forms to make it possible to write hash-bang
   lines like #!...sciteco -q8iom
   Command line arguments should then also be handled
   differently, passing them in an array or single string
   register, so they no longer affect the unnamed buffer.
 * Once we've got --stdout, it makes sense to ship a version of
   tecat written in SciTECO.
   This is useful as a git diff textconv filter.
   See https://gist.github.com/rhaberkorn/6534ecf1b05de6216d0a9c33f31ab5f8
 * For third-party macro authors, it is useful to know
   the standard library path (e.g. to install new lexers).
   There could be a --print-path option, or with the --quiet
   and --stdout options, one could write:
   sciteco -qoe 'G[$SCITECOPATH]'
 * The C/C++ lexer supports preprocessor evaluation.
   This is currently always enabled but there are no defines.
   Could be added as a global reg to set up defines easily.
   NOTE: This requires the SCI_SETPROPERTY message which
   is currently unsupported by <ES>.
 * Now that we have redo/reinsertion:
   When ^G modifier is active, normal inserts could insert
   between effective and rubbed out command line - without
   resetting it. This would add another alternative to { and }
   for fixing up a command line.
 * Instead of discarding a rubbed out command line once the user
   presses a non-matching key, a redo-tree could be built instead.
   When you rub out to a character where the tree branches,
   the next character typed always determines whether and which
   existing redo branch will be activated (ie become the new
   rubbed out command line).
 * some missing useful VideoTECO/TECO-11 commands and unnecessary
   incompatibilities:
   * EF with buffer id
   * ER command: read file into current buffer at dot
   * nEW to save a buffer by id
   * EI is used to open an indirect macro file in classic TECO.
     EM should thus be renamed EI.
     EM (position magtape in classic TECO) would be free again,
     e.g. for execute macro with string argument or as a special version
     of EI that considers $SCITECOPATH.
     Current use of EI (insert without string building) will have
     to move, but it might vanish anyway once we can disable string building
     with a special character, eg. you could write I^C instead.
   * <I> doesn't have string building enabled in classic TECO.
     Changing this would perhaps be a change too radical.
     Also, we would then need a string-building variant like <:I>.
   * <FN> as a search-replace variant of <N>.
   * FB for bounded search and FC for bounded search-replace.
     One advantage in comparison to ::S
     (which also supports arguments in SciTECO), would be the ability
     to bound comparisons by line with n:FB.
   * Searches can extend beyond the given bounds in DEC TECO
     as long as they start within the range.
     That's why ::S is equivalent to .,.:FB in DEC TECO.
     In SciTECO, matches must currently be entirely within the given bounds,
     just like in Video TECO.
     The DEC behavior could be achieved by always searching till the end
     of the buffer, but excluding all matches beyond the target range.
   * ^A, :Gq, T and stdio in general
   * nA returned -1 in case of invalid positions (similar to SciTECO's ^E)
     instead of failing in DEC TECO.
     The failing <A> command is inherited from Video TECO.
   * ^W was an immediate action command to repaint the screen.
     This could be a regular command to allow refreshing in long loops.
     Video TECO had ET for the same purpose.
     TECO 10 had a ^W regular command for case folding all strings,
     but I don't think it's worth supporting.
 * Perhaps there should be a command for converting absolute line numbers
   to positions (i.e. ESPOSITIONFROMLINE$$:^E).
   This should also include the opposite as currently supported by :^Q.
   An advantage would also be that :^Q could be made to return -1 for invalid
   line ranges as well.
 * _pattern$ as equivalence to Spattern$^SC.
   Well almost, since ^SC must not be executed in the failure case.
 * String building construct for subpattern references: ^Yx
   Perhaps support ^Y(x) as well.
   Since this is mainly useful for search-replace commands,
   we'd have to store the actual data in teco_range_t as the
   matched pattern is removed from the buffer before inserting the replacement
   string.
 * For symmetry, there should be a command for -W,
   eg. P. Macros and modifiers are obviously not a solution here
   since they're too long.
 * Visual selections via `...'.
   Allows them to be used recursively (eg. as a tool in macros).
   Returns the buffer range.
 * Perhaps there should be a built-in command for joining
   lines as has been requested by users.
   ^J (caret+J) would still be free.
 * Buffer ids should be "circular", i.e. interpreted modulo the
   number of buffers in the ring. This allows "%*" to wrap at the
   end of the buffer list.
 * instead of 0EB to show the list of buffers, there should perhaps
   be a special TAB-completion (^G mode?) that completes only buffers
   in the ring. It should also display the numeric buffer ids.
 * Gtk: Unicode IME support for asiatic languages.
   Have a look how it is done in Scintilla.
 * Progress indication in commandline cursor:
   Perhaps blinking or invisible?
   The problem is, this won't work so easily once we use a Scintilla
   minibuffer everywhere.
   Gtk could at the very least use the hourglass cursor.
 * Command to free Q-Register (remove from table).
   e.g. FQ (free Q). :FQ could free by QRegister prefix name for
   the common use case of Q-Register subtables and lists.
 * TECO syntax highlighting.
   This should now be relatively easy to implement by reusing
   the parser.
 * multiline commandline
   * Perhaps use Scintilla view as mini buffer.
     This means patching Scintilla, so it does not break lines
     on new line characters and we can use character representations
     (extend SCI_SETLINEENDTYPESALLOWED?).
     cmdline.c can then directly operate on the Scintilla document.
   * A Scintilla view will allow syntax highlighting
 * command line could highlight dead branches (e.g. gray them out)
 * Perhaps add a ^E register analogous to ":", but working with
   byte offsets. This would mainly be useful in ^E\^E.
 * EL command could also be used to convert all EOLs in the current
   buffer.
 * nEL should perhaps dirtify the buffer, at least when automatic
   EOL translation is active, or always (see above).
   The dirty flag exists to remind users to save their buffers and
   nEL changes the result of a Save.
 * exclusive access to all opened files/buffers (locking):
   SciTECO will never be able to notice when a file has been
   changed externally. Also reversing a file write will overwrite
   any changes another process could have done on the file.
   Therefore open buffers should be locked using the flock(), fcntl()
   or lockf() interfaces. On Windows we can even enforce mandatory locks.
   A generic fallback could use lock files -- this would guard against
   concurrent SciTECO instances at least.
 * Multi-window support is probably never going to realize.
   Perhaps we could add a Gtk-frontend option like -X for opening
   all filenames with the same options in separate processes.
   For the Curses version, you will need a shell wrapper, or we could
   add an environment variable like $SCITECO_LAUNCH that can be set
   to a command for launching a new terminal.
   For multi-window SciTECO to work properly, file locking is probably
   a must as it is otherwise too easy to confuse SciTECO if multiple
   instances open the same file.
 * To faciliate data exchange between multiple SciTECO instances,
   there may be a TCP/UNIX server mode that allows read-only access
   to the Q-Register space of any running instance.
   Clipboards are not flexible enough and not supported everywhere.
   I am not sure how to elegantly address instances, though.
   Especially without some kind of central name registry.
 * Touch restored save point files - should perhaps be configurable.
   This is important when working with Makefiles, as make looks
   at the modification times of files.
 * There should really be a backup mechanism. It would be relatively
   easy to implement portably, by using timeout() on Curses.
   The Gtk version can simply use a glib timer.
   Backup files should NOT be hidden and the timeout should be
   configurable (EJ?).
 * Error handling in SciTECO macros: Allow throwing errors with
   e.g. [n]ET<description>$ where n is an error code, defaulting
   to 0 and description is the error string - there could be code-specific
   defaults. All internal error classes use defined codes.
   Errors could be catched using a structured try-catch-like construct
   or by defining an error handling label.
   Macros may retrieve the code and string of the last error.
 * Backtracking execution semantics, bringing the power of SNOBOL
   (and more!).
   This can be a variant of a structured error handling construct.
   This will also require managing our own function call stack.
   See https://github.com/rhaberkorn/sciteco/issues/26#issuecomment-2449983076
 * Once we have our own function call stack,
   it will be possible, although not trivial, to add support for
   user-definable macros that accept string arguments, eg.
   EMq<param>$
   This will have to switch back and forth between the macro and
   the invoking frame supplying the macro (similar to a coroutine).
   In the most simple case, a special command returns the next character
   produced by the callers string building machine including rubout and
   the user will have to implement rubout-support manually.
   For a lot of common cases, we could also allow a string building
   construct that symbolizes the string parameter supplied by the
   caller. This could activate interactive processing in the macro's
   current command, allowing you to easily "wrap" interactive commands in
   macros. The same construct would also be useful with
   non-interactive commands as a way to store the supplied parameter
   using EU for instance.
 * Emscripten nodejs port.
   This may be a viable way to run SciTECO "cross"-platform, at least
   for evaluation... on UNIX-like systems in absence of prebuilt binaries.
   I already got netbsd-curses to build against
   Emscripten/nodejs using some UNIX shell wrapper calls, so practically
   all of SciTECO can be run against nodejs as a runtime.
   I'm not aware of any (working) alternatives, like cross-compiling
   for the JVM.
   See also https://gist.github.com/VitoVan/92ba4f2b68fec31cda803119686295e5
 * Windows supports virtual terminals now. See:
   https://docs.microsoft.com/en-us/windows/console/classic-vs-vt
   Perhaps we should transition from PDCurses to something using
   terminal escape sequences like ncurses for Windows.
 * Improve the message line so it can log multiple messages.
   Especially important on GUI platforms and Win32 so we can get
   rid of the attached console window.
 * A dirtify-hook would be useful and could be used for
   spell checking. Naturally it could only be exected at the
   end of executing interactive commands) and it should be triggered
   only at the end of command lines.
 * CSS lexer config
 * Add a dedicated JSON lexer.
   JSON files are currently handled by the Javascript lexer (js.tes).
 * <'> and <|> should result in an error outside of If-statements.
   This is not strictly necessary and complicates the parser.
   <'> is currently a no-op outside of dead If-branches.
   | ... ' is basically equivalent to 0< ... >.
   Furthermore, it may not be trivial to detect such dangling
   Else/End-If statements as the parser state does not tell us enough.
   There is nothing that makes code after a successful If-condition
   special. Even if we always incresed the nest_level, that
   variable does not discern Ifs and Whiles.
 * Possible Nightly Build improvements (and therefore releases):
   * Build 32-bit Ubuntu packages
   * Push nightly builds into the Ubuntu PPA.
     We should probably create a new PPA sciteco-nightly.
     A new private key has already been registered on Launchpad and
     Github. We just need to integrate with CI.
     See also https://github.com/marketplace/actions/import-gpg
   * 64-bit Windows builds
   * Mac OS Arm64 builds either separately or via universal binary.
     See https://codetinkering.com/switch-homebrew-arm-x86/
     Target flag: `-target arm64-apple-macos11`
 * Get into appimage.github.io and AppImageHub.
   See https://github.com/AppImage/appimage.github.io/pull/3402
 * Get into mentors.debian.net. First step to being adopted
   into the Debian repositories.
 * Get meta-rhaberkorn into https://layers.openembedded.org
 * sample.teco_ini: Support opening files on certain lines
   (filename:line).
   Theoretically, this could also be added to the <EB> syntax,
   although the colon character is allowed in filenames under Windows.
   In principe there is little need for that in interactive mode,
   but it would ease opening filenames copied from compiler errors
   or grep -n results.
   Other editors use the +line[,col] syntax (see nano).
 * <:EF> for saving and closing a buffer, similar to <:EX>.
 * Bash completions.
 * Case-sensitive search command (modifier or flag).
 * FreeBSD: rctl(8) theoretically allows setting up per-process actions
   when exceeding the memory limit.
   This however requires special system settings.
 * Auto-completions customization via external programs.
   This among other things could be used to integrate LSPs-driven
   autocompletions.
 * Whereever we take buffer positions (nJ; n,mD; nQ...),
   negative numbers could refer to the end of the buffer or
   Q-Register string.
 * Support extended operators like in TECO-64:
   https://github.com/fpjohnston/TECO-64/blob/master/doc/oper.md
   However, instead of introducing a separate parser state, better
   use operators like ~=, ~< etc.
 * Perhaps ignore whitespace after @ as does TECO-64.
   There is little benefit in using spaces or tabs as string delimiters,
   but ignoring whitespace may increase readability. Eg.
   @^Ua {...}
 * It should be possible to disable auto-completions of one-character
   register names, so that we can map the idention macro to M<TAB>.
 * Add a configure-switch for LTO (--enable-lto).
 * There should be a string building character for including
   a character by code. Currently, there is only ^EUq where
   q must be set earlier.
   This would be useful when searching in binary files or
   to include Unicode characters by code point.
   Unfortunately its syntax cannot depend on the string argument's
   encoding, as that could confuse parse-only mode.
   Perhaps ^E!xxxx or overload ^Qx0123.
   TECO-11 has ^Ennn (octal), but only for searching?
 * There should be a string building construct for escaping
   search patterns.
   Since string building is performed immediately before
   search pattern translation, you cannot currently
   search for a Q-Register verbatim.
 * Tweak the Makefile lexer for Automake support.
   In the simplest case, just add the *.am file extension.
 * Add an fnkeys.tes alternative where moving cursor keys
   leaves you in the insert (I) command.
   That will behave very similar to classical editors.
 * Lexing via SciTECO macros?
   They would have to be in their own parser instance since Scintilla
   could ask us to restyle at any time and within string arguments,
   which would confuse the parser as it is.
   Also, parsers are not fully embeddable right now.
   At the same time, it would need access to the view/document it's
   supposed to style. Tricky, but not impossible.
 * Support external lexers.
   Eg. @ES/SCI_SETILEXER/scintillua:APL/
   automatically loads libscintillua.so or scintillua.dll, caches
   the library handle and creates the "APL" lexer.
   There would also have to be some kind of SCI_NAMEDSTYLE wrapper,
   so we can look up style ids by name (specifically for Scintillua).
 * Lexilla: Could also add an APL lexer to Lexilla.
   APL has very simple lexical rules.
 * ^^ in string building expanding to a single caret is not
   consistent. Perhaps we should allow only ^Q^ as a way to insert a
   single caret?
 * Support for non-ANSI single byte encodings is still incomplete.
   You can set them with EE and they will be correctly
   displayed (on Gtk at least), but there is no way
   to insert text in these codepages, at least outside
   of the latin range of course.
   There are two ways this could be implemented:
   * Either all sorts of commands automatically iconv
     from/to the configured encoding.
   * Or we iconv once to UTF-8 when loading the file
     and iconv back when saving.
     This is probably easier but means, you have to
     somehow specify the codepage on EB as you cannot
     change it later on.
     We could say that nEB...$ specifies the code page
     if the string argument is nonempty.
     On the other hand, iconv uses symbolic identifiers.
 * Perhaps the Unicode "icons" should be configurable via TECO.
   In the easiest case there could simply be 2 Q-Reg namespaces:
   ^F... for filenames and ^E... for extensions.
   The numeric part could be used to store the codepoints.
 * It would be good if we could somehow run the testsuite
   with --valgrind during CI (Ubuntu).
   This did not work out of the box.
 * session.tes: Perhaps persist the search-replace registers "-" and "_".
   Unfortunately, there is currently no way to reliably escape their
   contents in the generated .teco_session.
   Ideally we would also persist any manually configured lexer,
   but we cannot easily store the current buffer's lexer.
 * session.tes: Could mung a .teco_ini in the VCS directory as well.
   This is only really useful once we can elegantly append to various
   ED hooks.
 * grosciteco: Does not currently support diacritics.
   This is because Groff decomposes characters in intermediate output.
   Either we have to consult devutf8/R or use wrap g_unichar_compose().
   This will be important once we want to localize documentation.
 * Search and replace registers ("-" and "_") should probably be local
   to the current macro frame, so you don't have to save and restore
   them all the time in portable macros.
   This however means they should be in local Q-Registers which
   is a significant deviation from DEC TECO.
   Perhaps a few select local Q-Registers (-, _, ^X, ^R) should be
   accessible with the global reg syntax as well, so G- is equivalent
   to G.-?
 * Real block comments (!* ... *!) that don't spam the goto tables.
   TECO-64 has end of line comments beginning with !! as well.
   We may want both as 0<...> cannot be used to comment out all sorts
   of blocks as it necessarily drives the parser.
 * `-` currently inverts the number sign in teco_state_start_minus().
   So --1 == 1 and --C == C.
   There is probably no need for this "feature" and an error
   should be thrown instead on the second `-`.

Optimizations:
 * Use SC_DOCUMENTOPTION_STYLES_NONE in batch mode.
   However, we do not actually know that we do not continue
   in interactive mode. Also, some scripts like grosciteco.tes
   make use of styling in batch mode. So this would have to be
   requested explicitly per ED flag or command line option.
 * There should be a common error code for null-byte tests
   instead of TECO_ERROR_FAILED.
 * teco_string_append() could be optimized by ORing a padding
   into the realloc() size (e.g. 0xFF).
   However, this has not proven effective on Linux/glibc
   probably because it will already allocate in blocks of
   roughly the same size.
   Should be tested on Windows, though.
 * commonly used (special) Q-Registers could be cached,
   saving the q-reg table lookup.
   This is already done with ^R (radix) in teco_qreg_table_t.
 * refactor search commands (create proper base class)
 * undo__teco_interface_ssm() could always include the check for
   teco_current_doc_must_undo().
 * Avoid Scintilla Undo actions entirely.
   This will make undo token creation of deletions harder,
   since we must first query the text to be reinserted again,
   but will probably save lots of memory and one huge source
   of bugs.
 * Newer GCC and C23 features:
   * Perhaps teco_bool_t usage could be simplified using
     __attribute__((hardbool)).
   * Use `#elifdef` instead of `#elif defined`.
   * Use `[[gnu::foo]]` instead of `__attribute__((foo))`.
   * The TECO_FOR_EACH() hack could be simplified at least marginally
     using __VA_OPT__().
   * A few macros like TECO_CTL_KEY() could be turned into
     constexpr functions.
 * Compound literals could be abused for default values in the
   Scintilla SSM functions. All the wrapper functions would have to be
   turned into macros, though.
   However, we cannot use macros in TECO_DEFINE_UNDO_CALL().
   Also, we cannot nest such macros for some strange reason.
 * We could save around 500 bytes in every teco_machine_main_transition_t
   table (2kb in total) if we would wrap entries in a macro and decrement
   32 (' ').
 * Parsing might be optimized with libc's Unicode handling
   functions and/or custom optimized versions.
 * The new Scintilla IDocumentEditable interface could be
   used to speed up Q-Register string accesses.
   That is, when it actually supports anything useful.
   This is a provisional feature and supported only via C++,
   so we would need a small wrapper to call it from C world.
 * Perhaps replace glib with gnulib. Could improve
   portability and reduce binary size on platforms where
   I have to ship the glib shared library.
   Also we could control memory allocations more tightly.
   We could also make use of the fnmatch and canonicalize
   modules.
   On the other hand, this imports tons of sh*t into the
   repository and chains us to Autotools.
 * Does it make sense to import glib-2.0.m4?
 * According to ChatGPT (sic) the glibc and jemalloc malloc_usable_size()
   do not change during the lifetime of an object,
   although this is an implementation detail.
   Perhaps we should support these system allocators by default
   if malloc_usable_size() and the original functions as __malloc()
   are defined.
   But how to even test for glibc's ptmalloc?
   Linux could use musl as well for instance.

Documentation:
 * Doxygen docs could be deployed on Github pages
   automatically.
 * The ? command could be extended to support looking
   up help terms at dot in the current document (e.g. if called ?$).
   Furthermore, womanpages could contain "hypertext" links
   to help topics using special Troff markup and grosciteco support.
 * The command reference should include an overview.
 * Command reference is poorly formatted.
   tedoc.tes should be reviewed.
 * Write some tutorials for the Wiki, e.g. about paragraph
   reflowing...
   Object-oriented SciTECO ideoms etc. ;-)
 * What to do with `--xembed`: tabbed, st
   when used as the git editor, etc.
 * Perhaps there should be a Getting Started document,
   that is automatically opened by sample.teco_ini.
 * People are demanding a Youtube tutorial.
 * The HTML manuals lack monospaced fonts.
   This is partly because an.tmac removes the Courier family
   in nroff mode, but it still doesn't work if you undo this.