I got really weird error (invalid panel passed to top_panel) when there
was no such call, so I guess there was some memory corruption.
formatLine is the only suspect, but when I put in the guard, the error
wasn't reproduced (just scrolling through qwaq's makefile in a big
window).
With this, windows can be resized using any of the corners or the three
sides other than top (top side is move-only, otherwise moving a window
without resizing would be impossible).
It's a fairly high-level wrapper for TextBuffer in that it implements
file ops (load/save), searching, navigation, and formatting (simple
line-oriented with tab stops (currently at 4 spaces)).
While the key escape sequences are xterm-specific, they are only the
default and preliminary provision has been made for overriding them.
However, no override mechanism has been implemented beyond using dynamic
table lookup.
I'd left qwaq-curses running overnight and found it locked up: both
threads were looping because pthread_cond_timedwait was returning
EINVAL. Thus bail if anything other than 0 is returned, and try to
ensure tv_nsec is in the range 0..999999999
This doesn't fix the problem of lost events: that seems to be inside
ncurses. I've done some investigations, and it seems xterm sends
separate events for motion and pre/release (which have current coords),
in both 1003 and 1006 modes. No idea what ncurses is doing (does it even
handle 1003 properly?), and it requires the use of xterm-1006 for it to
use 1006 mode (which is nice in that it disambiguates button releases
and allows for huge terminals (not that I would use such normally)).
Guess I've got some side-work cut out for me :P
While writing the code I suspected this would be necessary, but it's
nice to know. Now the window seems to be correctly fetched, but
get_event locks up.
I realized that with dynamic thread creation the arrays resizing could
cause them to move around in memory which would be bad for anything
holding a pointer to the data, and even using indices wouldn't help that
much as the array would need to be mutex protected.
If none are specified, default to qwaq-app.dat (for now, anyway). For
each progs file, an optional args set can be specified in the same order
(separated by --). Missing sets default to empty, excess sets are
ignored.
The sets are separated by --, and the first set is passed to
getopt_long which currently recognizes only --qargs and non-options. The
--qargs options parses out a set (to -- or end of args) that is passed
to the qargs sub-system for standard qf command line parsing. Set 0 is
for the main qwaq application. Any additional sets (excluding --qargs)
will be used to spawn additional threads when that's working.
