console update

[Marcus Brinkmann]

Hi,

I checked in some changes that fix the off by one error in the server,
document the ECMA-48 compliance (note: we are not compliant, and probably
never will be, but I added what we can support easily, and checked what we
already tried to support for correctness), and added attribute support.
For now, I have chosen to interleave attributes with UCS-4 characters:

typedef struct
{
  wchar_t chr;
  conchar_attr_t attr;
} conchar_t;

The ncurses people did something similar with the cchar_t, but they had to
use an array of five(!) UCS-4 characters, because that is what is required
by the resp standard for combined characters.  Horrible, horrible, as this
means 24 bytes for each cchar_t, something that we might be forced into at
some time, too, but for now I prefer it a bit smaller and simpler.

With todays fixes, and with the console ncurses client from:
ftp://alpha.gnu.org/gnu/contrib/marcus/hurd/console-client-unix.c

and the terminfo from
ftp://alpha.gnu.org/gnu/contrib/marcus/hurd/hurd.ti

(Incorporate with "tic hurd.ti", use with "TERM=hurd ..."),
the console is already quite operational.  The following enhancements are
visible:

In the server:
* Most display bugs gone.  Some minor bugs remain, which have to be
  debugged.  (Notably, emacs is sometimes leaving some cruft behind in the
  minibuffer/status line).
* Attributes are now included in the display file.

In the curses client:
* Attribute support, so now you have colors, bold, dim etc! 
  Tested with emacs, mutt, dselect, dircolors/ls, ...
* Keycode translation table for curses.  This makes the
  home/end/insert/delete/backspace/arrow keys functional.
  Terminal is now put into raw mode, so that ^C etc are passed through,
  so you have to use ^W to terminate the program!
* Keyboard input is passed through directly without blocking.

Bugs:
* Minor display bugs, notably with emacs.  Also, aafire doesn't use the
  right attributes, or the attributes it uses don't come out correctly.
  The fire becomes brighter, not dimmer, at the border.  This needs more
  investigation. 
* When running like this: "TERM=hurd foo < term > term 2> term", where foo
  is a curses program, the application will think that LINES is 24.  Curses
  seems to assume that we have only 24 lines, although we have 25.  I don't
  know why.  Maybe that is the internal default or so.
* Likewise, when running like the above, ^C etc are not passed through. 
  (Interestingly, if you type ^C in the terminal you started the program,
  it is passed through.  Also, password checking happens on the original
  terminal.  It seems the controlling terminal is not set correctly.
  I will have to try to run a real getty on the terminal node next time.
* A lot of keycodes are missing.  It's straightforward to add them, but I
  have to look around if there is some standard for them we can simply comply
  to.

It seems that one problem is that curses scrolling is slowing things down.
The performance issue is a bit tricky, but I want to see what I can squeeze
out of it.  After all, I am doing most of my testing with the curses client,
running inside screen, which adds another curses layer, running on the
GNU Mach console.  It's not surprising that this slows things down a bit.
I think I can start with the VGA display client, soon.

BTW, there are always little projects around the console code that are not
really Hurd specific or require a lot of expertise.  For example, support
for user defined tabulator stops should be added to display.c.  I will come
to them as I see the need to do it, but I don't mind someone else to send in
patches for them.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de