On Mon, Jun 13, 2005 at 05:20:55PM +0200, Martin Husemann wrote:
> 
> I personally would use a multibyte character encoding and variable (from a
> storage space point of view) line lengths [allocating new lines with the
> maximum lentgh used ever and expanding by reallocating as needed], making it
> easy to get to the start of the previous or next line, but requiring scans
> accross the line to find a specific postion. This would probably cause a
> major rewrite of all of curses ;-)
> 

I suspect more than you would imagine - the current refresh code
attempts to minimise the updates to the screen by keeping a range of
bytes on the line that have changed - this logic would have to be
totally rewritten to cope with the locations changing, addressing
calculations would have to be performed every time you wanted to go
to a particular screen location.  It would result in a lot of overhead
when the cursor is being positioned.

We need to trade that CPU expense off against using extra storage,
before we get too tangled up with that, consider that a 80x40 screen
needs about 3k of storage for 8-bit characters (actually, the current
curses will use more than this) - even if we end up with ten times
that for doing wide characters we are talking 32k of storage.  Even on
a minimal memory machine that will translate into a lot of curses
windows. (I will avoid the obligatory "memory is cheap" excuse here ;)

As I said before, if we do this right then we can tailor the wide
character support out when targetting a very tight memory machine.

-- 
Brett Lymn