+ - TTerminalWindow by default launches 'script -fqe /dev/null' or
+ 'script -q -F /dev/null' on non-Windows platforms. This is a
+ workaround for the C library behavior of checking for a tty:
+ script launches $SHELL in a pseudo-tty. This works on Linux and
+ Mac but might not on other Posix-y platforms.
+
+ - Closing a TTerminalWindow without exiting the process inside it
+ may result in a zombie 'script' process.
+
+ - When using the Swing backend, and not using 'ptypipe', closing a
+ TTerminalWindow without exiting the process inside it may result
+ in a SIGTERM to the JVM causing it to crash. The root cause is
+ currently unknown, but is potentially a bug in more recent
+ releases of the 'script' utility from the util-linux package.
+
+ - TTerminalWindow can only notify the child process of changes in
+ window size if using the 'ptypipe' utility, due to Java's lack of
+ support for forkpty() and similar. ptypipe is available at
+ https://gitlab.com/klamonte/ptypipe.
+
+ - Java's InputStreamReader as used by the ECMA48 backend requires a
+ valid UTF-8 stream. The default X10 encoding for mouse
+ coordinates outside (160,94) can corrupt that stream, at best
+ putting garbage keyboard events in the input queue but at worst
+ causing the backend reader thread to throw an Exception and exit
+ and make the entire UI unusable. Mouse support therefore requires
+ a terminal that can deliver either UTF-8 coordinates (1005 mode)
+ or SGR coordinates (1006 mode). Most modern terminals can do
+ this.
+
+ - jexer.session.TTYSession calls 'stty size' once every second to
+ check the current window size, performing the same function as
+ ioctl(TIOCGWINSZ) but without requiring a native library.
+
+ - jexer.backend.ECMA48Terminal calls 'stty' to perform the
+ equivalent of cfmakeraw() when using System.in/out. System.out is
+ also (blindly!) put in 'stty sane cooked' mode when exiting.
+
+ - jexer.backend.ECMA48Terminal uses a single palette containing
+ MAX_COLOR_REGISTERS colors for all sixel images. These colors are
+ generated in the SixelPalette.makePalette() method with bits for
+ hue, saturation, and luminance, and the two extremes set to pure
+ black and pure white. This provides a reasonable general-purpose
+ palette light on CPU, but at a cost that individual images do not
+ look as good as the terminal is actually capable of.
+
+
+
+See Also
+--------
+
+[Tranquil Java IDE](https://tjide.sourceforge.io) is a TUI-based
+integrated development environment for the Java language that was
+built using a very lightly modified GPL version of Jexer. TJ provided
+a real-world use case to shake out numerous bugs and limitations of
+Jexer.
+
+
+
+Maintainers Wanted
+------------------
+
+Both Jexer and TJIDE are seeking additional maintainers. I am not in
+a position in life to take on significant off-hours programming work,
+and am willing to hand these projects over to one or more persons with
+time and interest.
+
+My personal code design philosophy for TJIDE/Jexer is outlined at
+https://gitlab.com/klamonte/tjide/blob/master/java/docs/code_design.txt
+. I realize that some of the features listed below may require
+deviations from this philosophy, but this is what I have built so far.
+
+Some of the areas that will likely require significant efforts are:
+
+ * Editor improvements. The editor is currently very minimalistic,
+ much closer to MS-DOS edit.com than a real programmer's editor.
+ Users will probably desire many more features: drag-and-drop, real
+ syntax or at least regexp highlighting (not just keywords), paren
+ matching, paragraph/comment reflow, and dozens more. The
+ underlying Document/Line/Word model is not going to be sufficient
+ to meet these features.
+
+ * Better Windows and OSX support. It would be nice to ship a
+ jlink'ed JVM on these platforms with the JRE, JDK, and JPDA
+ modules all together. For Windows, it might be preferable to
+ consider doing any of the following: ship a third-party terminal,
+ use PowerShell, or use the newer ConPTY for TTerminalWindow.
+
+ * Bug fixes. The Jexer codebase is quite large despite my best
+ efforts. Bugs are typically very small to fix, but can take some
+ time to find: a simple NPE or AssertionError can sometimes take
+ 4-8 hours to squash. Fortunately, fixing issues in one place has
+ not often led to breakages elsewhere.
+
+ * New Jexer applications. So far as I know, Jexer is the only
+ mouse-supporting full TUI windowing framework with sixel image
+ support in existence. I cannot predict what kinds of applications
+ could be built out of it, and how those needs will push back to
+ the framework.
+
+These are what I can clearly see right now. Obviously users are
+capable of finding many more.
+
+I intend to continue poking on Jexer and TJIDE, and will maintain a
+branch to be "the fastest and simplest Java language IDE available",
+which will deliberately remain small.
+
+I hope that other languages choose to transliterate Jexer to provide
+TUIs to their own platforms. I will be happy to help them understand
+the code to support those efforts.