On Wed, Sep 18, 2002 at 04:17:18PM -0400, Roland McGrath wrote: > > I think I am not aware of what configuration you mean. I agree that it is > > probably not reasonable to have filename tab completion by default in term's > > cooked mode, but the default settings should be good enough for normal > > interactive mode. > > Hardwired key bindings are unacceptable. If you don't add any kind of > configuration interface, then the only one you get is stty, which lets you > bind characters to the things c_cc represents but not other editting commands. > > Another reason using readline is good is that people already use it and > configure it how they like it for bash and whatnot using their .inputrc. > So the desireable thing is to allow configuration of the terminal in a way > that can be fed from .inputrc. For example, fsysopts options that take > lines in .inputrc syntax would be a minimally adequate interface. But > you'd want that configuration to act more like stty configuration than like > fsysopts usually does, i.e. reset to defaults by a revoke or something.
Mmh, ok, you have a point here. Although I think that even if a system term only works with the system wide default configuration (/etc/inputrc) it would already be a useful feature. I think I will try to hack it up just for the fun of it (and the basic functionality must be there anyway before you can work on the configuration stuff, so it's a useful first step). > True. I had meant to bring this up (ptys, serial, etc) in the first > message but ran out of steam typing. I don't have a good answer, I am just > not happy with a bloated term. I meant to ask what exactly is being done > or considered in Linux, since you mentioned something was happening. The > latest Linux 2.5 kernel sources I am aware of don't appear to do anything > about it. If the extent of the support there will just be a bit to assume > UTF8, then that is probably good enough for us too in the simple term. > If only the snazzy readline-enabled term handles multibyte characters > optimally, we will live. There doesn't seem to be a consensus among the Linux folks that the kernel built in tty driver needs to be multi-byte aware. Maybe they think it should eventually but it is low priority. The patch I had seen is available here: ftp://ftp.ilog.fr/pub/Users/haible/utf8/linux-2.3.12-tty.diff To go with that: ftp://ftp.ilog.fr/pub/Users/haible/utf8/stty.diff OTOH, this is also not covered by POSIX.1 yet, AFAIK. The patch has a flaw in that it is not double-width character aware, I think. Although the relevance of this was disputed. Maybe we should really wait for the i18n-Linux folks to sort it all out. I snipped the other ideas, which are quite interesting and I thank you for sharing them. But they would indeed lead me a bit too far away right now. Right now I am playing a bit with libreadline, but mainly to get the other line-editing features. It seems to me to be quite easy to glue it into term/munge.c, we'll see. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org [EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/ _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
