so assume the client can be made small enough to run with RAMTOP
set to 40K or less...

for windowing to be useful, we have to have at least 4 of them,
preferably more.

scrollback would be a nice feature. it's a tradeoff of course,
more scrollback per window = fewer windows.

suppose we can manage to set RAMTOP to 36K ($9000).

we need 1K for a font. for one thing, we want { } ~ ` glyphs (and
maybe some chunk of latin-1 based on the XL intl set). for another,
we want the font to be in screen order, so putting $41 in screen RAM
actually show a capital A, etc. this will speed things up, and also
allow for nick tab-completion to search backwards through screen
memory (so we won't have to keep a separate list).

we *don't* need a regular GR.0 screen. all display will be done with
the windowing UI.

we *do* need a GR.0-like display list, with an LMS for every line.
probably it'll be 23 lines of channel/query text, and 2 lines for the
input/status area (and a blank line between them). this will be ~80
bytes, and the different screens can share it (the LMS addresses get
updated when switching windows).

a GR0 line is 40 bytes. we have, say, 12200 bytes. that's 300 lines.
the inputbox is shared between all the windows. that gives us 13
23-line screens, if we don't do scrollback. if we allocate 60 lines
per screen (23 of which are visible at any given time), that gives us
5 scrollable windows. not really enough of them: one for each channel
or query, and one "everything else" (server messages and PMs that
aren't queries).

if it's 50 lines per window, we get 6 of them.

how about they aren't all the same height?

the 'everything else' window and the primary channel can have more lines.
say, they get 59 lines each, and we have 4 more windows at 46 lines.
that puts us a bit over (12080 bytes) but I think it's doable. that still
only gives us 6 windows though. not worth doing.

what about a non-scrollable server window, then 6 46-line scrollable
windows, one of which is "msgs" (all non-query PMs). that gets us 5
channel/query windows, plus the msgs window will be more convenient
than having the msgs mixed with server text.

what if we want 8 windows? they'd only be 37 lines each (not even a
whole screen of scrollback).

maybe we can scrunch the client down so it fits under 32K... maybe
that can include the font too, so we have 16K for window lines. that
would give us 8 51-line windows or 7 58-line ones.