On Thu, Dec 06, 2007 at 01:27:00AM +0100, Jehan wrote: > > From my understanding of an X terminal emulator (again, as incomplete as > > you too :-)), here is how it works: the emulator accepts input from > > keyboard (though X keyboard events), sends it to the slave process > > (typically > > a shell); it also accepts output from the slave process, and prints it on > > the screen. So the terminal emulator must listen on two input channels: the > > X keyboard event and the slave process's stdout/stderr, it redirects one > > input channel (X keyboard event) to the slave process as well as echoes the > > input on the screen, it then renders the data from the other input channel > > (slave process) on the screen. > > I would have thought than input from X keyboard events would be sent > to the slave process, but not echoed to the screen. If it has to be > displayed on screen, the slave process would then channel back the > input on its output (for a shell for instance where what you type is > effectively on screen). Imagine indeed if the slave process is not a > shell but some terminal program (for instance a ncurse program?) which > does not display what you type?
I think Jimmy meant that the input from the slave is processed, and then echoed if necessary. Here's the nity-gritty details: X keyboard events are processed in rxvt_process_keypress(): Macros, and other events useful to us are processed first. If it is a "regular" keypress, it is written into the slave's input buffer (via rxvt_tt_write I think). Input from the slave is read back in rxvt_cmd_getc (look for the select() call). We process the output (rxvt_process_getc) and store the output generated by the slave in our screen structure (PSCR(r, page)). Final output to the screen is done in rxvt_scr_refresh(). BE VERY CAREFUL when messing with this function. Most of the bottleneck in mrxvt is here. Especially when users (like me) insist on running mrxvt with Xft and anti-aliasing on an ancient AMD-K6 500 mhz. > > The biggest issue from my point of view, is in screen.c. In the current > > implementation, we assume each character is either 1 byte or 2 bytes (CJK > > multichar). On screen, a 1-byte character only occupies the space of one > > column and a 2-byte character occupies the space of exactly two columns. > > Thus, if the window width is 80, it allows exactly 80 bytes of data > > regardless of how many actual characters there are. In this case, for > > each line, we allocated 80 bytes for the actual characters, and 80 words > > for the rendering characteristics, such as color, bold font, CJK property > > (first byte or second byte of a CJK character). But this mechanism will > > be broken for UTF8 because each UTF8 character may use a different number > > of bytes (from one to six), and its width on screen is also different! > > > > My suggestion (again, immature) is to redesign text_t and rend_t. For > > text_t, we should allow multiple bytes. For rend_t, we should store the > > actual width of the character on screen. The second is easy: only one > > bit is needed if we assumes each character uses up to 2 columns. But > > the first needs a careful consideration: if we simply define text_t as > > an array of 6 bytes, we may end up wasting a huge amount of memory! > > > > Any ideas? > > Not yet. But what is sure is that huge work may await us. ;-) > > > > > I think the following link provides a good reference and we should carefully > > study it: > > > > http://www.cl.cam.ac.uk/~mgk25/unicode.html#term > > <http://www.cl.cam.ac.uk/%7Emgk25/unicode.html#term> > > > > Ehehehe... this is indeed also my main reference and it has been in a > tab of my browser for the last 2 days at least (since I decided I should > have a look inside mrxvt's code) and I already read it some time ago > when I became interested in utf-8. Perhaps you would also want to look at urxvt/rxvt-unicode. One of them is a ground up rewrite in C++ (so not useful for us). The other one I think is still based on the rxvt code! If you send us a sourceforge username, we can get you SVN access. GI -- You feel stuck with your debt if you can't budge it. ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ Materm-devel mailing list Materm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/materm-devel mrxvt home page: http://materm.sourceforge.net
