Re: console plans

[Marcus Brinkmann]

On Thu, Feb 14, 2002 at 04:12:32PM -0500, Roland McGrath wrote:
> > I thought there might be problems because the UTF-8 encoding is multi-byte. 
> > I don't see a problem with transfering UTF-8 data through our system (that's
> > what UTF-8 is about), but I thought term and maybe other things need to be
> > UTF-8 aware to get the character boundary right.  
> 
> I don't think things are expected to be MB-aware at that level.  libc
> expects byte-oriented io from the system with no special grouping
> guarantees, and it does the MB decoding.

Mmmh.  If you have some funky cheap line editing mode in the terminal, you
want it to be MB aware (in UTF8, to skip all 0x80 - 0xBF characters on
delete, for example), and some characters are actually wide characters
occupy two slots)... if we ever get Thomas' libreadline enabled term, I
would think that libreadline would take care of that or so.

> The big attraction of using X data is that it's
> the set of data describing the same hardware and the same features that we
> will already have installed.  There are already handy tools for users to
> select the configurations they like, etc.  Every other system not only has
> a reinvented configuration system different from every other system's, but
> in fact has two different ones and the second one (X) just happens to be
> universally compatible among all systems.  So among all the choices, the
> smallest possible leverage (no leverage at all) is in making our own new
> one and the greatest available leverage is in using X.

Yes, this is a very good argument.  I am already using X fonts (although I
am not yet supporting PCF or X font servers, it would probably feasible to
do it at any later time).  Actually, it occured to me that for the input
devices, the same info as in the XF86Config file is needed.  And, if we
woudl use a framebuffer, we would need similar info as in the Display
section of the X config files.  So I am actually a bit panicking because
that sounds incredibly like reinventing X, just in text mode :) [which is
one of the reasons why I don't want to do framebuffer right now, because
that _would_ be reinventing X).

> xkb has a lot of stuff that is sort of specific to the X context.  I don't
> think we'll want to use code from it or even all its configuration files,
> but from the files describing hardware and dead keys and so on we can
> extract the data (either parse the source or grok the compiled .xkm format).

I have only looked very briefly into it yet (still busy with the output
half), but it looks promising.  Everything seems to be encapsulated with
symbolic names, which we would need to map to our internal format.  The
symbolic names specific to X don't worry me in the least, we need some of
their functionality as well (maybe we can reuse them).  We will probably add
some own symbolic names for our functionality, which we can probably load on
top of it.  It seems all very modular.

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