Re: new console server code checked in

[Marcus Brinkmann]

On Wed, Jun 05, 2002 at 05:38:38AM -0400, Roland McGrath wrote:
> > Or from UCS-4 to the internal format of the console client, whatever it is.
> > Rolands hint for UTF-32LE etc was very helpful.
> 
> I was (and am still sort of) unclear on UTF-32 vs UCS-4.  There is also
> UCS4-LE and UCS-4BE, which is all but identical to the internal form (all
> the converter does is check for high bits).

UCS and Unicode started out as separate standards, but where unified after
it became clear that the world doesn't need two incompatible world wide
character sets :)

I am on my part a bit confused about the glibc code.  Where is the high bits
check?

> > For rectangular and scrolling updates, I am unprejudiced enough to just use
> > new flags for the file update, which mean that it is the rectangular area of
> > the screen as indicated by start and end, rather than the whole area
> > [start:end].  I suggested this in an earlier mail, and nobody was kicking
> > and screaming, so I guess it is not totally absurd ;)
> 
> So I am wondering, what rectangular operations does the terminal emulator
> engine really do?  Aren't they all whole-line operations?

Holy mother, you are right.  I could have sworn there were rectangular
screen (scroll) operations that don't cover the whole breadth of the screen,
but there simply arent (or they are single-line).  I was just making it up.

> Whole line
> operations in your file layout are in fact just operations on contiguous
> stretches of the file: scrolling is deleting a stretch of the file.  If
> those are all you really need, then your new update types could be more
> generic than the rectangle-oriented ones and map handily to editting
> operations (e.g. say you are translating display operations into edits of
> an Emacs buffer).

As long as the client always sees one insertion followed by one deletion
operation of the same size, it can determine the scrolling thing.
This could just work, although the synchronization of the two messages in
the client worries me a bit.  Well, maybe the client can just register one
RPC of this type and match it up with the other RPC of this type following
it (immediately, or after some RPCs of a different type, eg normal change
RPCs).

This is a bit related to changing the size of the file, which we probably
should never do if the client mmap's it.  Or can I sensefully use
default_pager_object_set_size?  This is mostly only an issue if the screen
size is changed.  But that is a little detail I am not very worried about
right now.  (For now I am cool with a configurable fixed size, let's say 100k,
and change the number of scrollback lines accordingly when the screen size
changes).

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