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

[Marcus Brinkmann]

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    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/