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 [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
