readline would need some work to have a different backend hooking into the term bottom half instead of the POSIX termios world it's written for. I fear it's also kind of big to have in term, and I worry it might not be as robust in all ways we would want term to be.
The real reason to use readline is for all its fancy features, i.e. full-featured line-editting in cooked mode as you get in bash et al. That requires a lot of configuration to make it reasonable, and is also a distraction from what you were really interested in. For the multibyte issue, console already knows all about the characters. So it can naturally dtrt if the term functionality is built in via libtermserver. That seems like the righter thing. The (unfinished) code I have for libtermserver is just taken from term and has essentially the same interfaces, which are all on single characters passed as int. It seems libtermserver interface should instead use a consr char * and length parameter so that multibyte-aware callers like console can give it a single multibyte character at a time. It will process this as multiple raw input chars, but calculate one position for purposes of cooked mode features. I seems like the right thing in a multibyte-aware terminal is that no multibyte char can be a special character since there is no termios interface for setting a char to match one (there is just c_cc). Otherwise if there are multibyte chars whose nth bytes might match a byte set in c_cc, a spurious signal or editting feature will be invoked. The mention of readline along with all this makes me think of an incidental console feature that would be nice once console uses libtermserver. There should be a hook/protocol feature by which the console server notifies clients of term state changes like cooked mode. Then a client can e.g. present a different UI for cooked mode (ICANON) input vs raw input. For example, using libreadline with history records and so forth for cooked mode, and a more direct input interface when not in cooked mode. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
