[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: term, utf-8 and cooked mode, combining characters

From: Roland McGrath
Subject: Re: term, utf-8 and cooked mode, combining characters
Date: Wed, 18 Sep 2002 01:46:15 -0400 (EDT)

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]