[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: term, utf-8 and cooked mode, combining characters
From: |
Marcus Brinkmann |
Subject: |
Re: term, utf-8 and cooked mode, combining characters |
Date: |
Tue, 8 Oct 2002 02:11:53 +0200 |
User-agent: |
Mutt/1.4i |
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/
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: term, utf-8 and cooked mode, combining characters,
Marcus Brinkmann <=