* (in a bizarre fashion, see below) automatically.
*
* Windows can be almost any width (number has to fit into 16 bits); the virtual
- * screen grows with them as needed -- but only horizontally. Their height is
- * limited by the height of the terminal screen.
+ * screen grows with them as needed -- but only horizontally and only up to 2^16
+ * cells. Their height is limited by the height of the terminal screen.
*
* Positioning of windows can only indirectly be influenced: by resizing them,
* and by shifting their relative position inside the (currently invisible)
* Functions that return uint8_t return these error codes:
* 0 - success
* 1 - memory allocation error (of ncurses' pads/windows, or scroll hint texts)
- * 2 - activity makes virtual screen grow beyond uint16 height/width confines
+ * 2 - activity forces virtual screen to grow beyond width of 2^16 cells
*
* TODO: Think up a more intuitive window positioning algorithm or at least make
* the chain that windows are positioned by visible.
#include "yx_uint16.h" /* for yx_uint16 coordinates */
-/* Individual windows consist of potential (real if window is visible) ncurses
- * WINDOWs wrapped inside Frame structs (that keep a window's designated size
- * even when it is invisible) wrapped inside metadata-rich Win structs. Win
- * structs are chained into a linked list of all the windows visible on the
- * virtual screen and also contain pointers to what content is to be drawn
- * inside the window, and by use of what method.
+
+/* Individual windows consist of potential (real only if window is visible
+ * inside the virtual screen) ncurses WINDOWs wrapped inside Frame structs (that
+ * keep a window's designated size even when it is invisible) wrapped inside
+ * metadata-rich Win structs. Win structs are chained into a linked list of all
+ * the windows visible on the virtual screen and also contain pointers to what
+ * content is to be drawn inside the window, and by use of what method.
*/
struct Frame