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
> I am kinda excited about the possibility to get all applications
> transparently use libreadline if they use cooked mode. I might be
> pipe-dreaming...
That has been a stock pipe-dream from the beginning of the Hurd. But
that's different from saying it's the right solution just to handle
the
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
[I'm quoting this list for reference ]
> > A1. Chop the unicode stream up into graphemes.
> > A2. Convert each grapheme into the local encoding, resulting in one or
> > more bytes each. (I think you can do this with iconv).
> > A3. Pass each graph
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> What happens if I log into the Hurd machine remotely, from an UTF-8
> capable terminal (either hooked on a serial line or via telnet/ssh)?
> Doesn't the term need to be multibyte aware then just as well?
If anybody has a clear picture of the involve
On Wed, Sep 18, 2002 at 01:46:15AM -0400, Roland McGrath wrote:
> 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.
What happens if I log into the Hurd
On Wed, Sep 18, 2002 at 04:19:15PM +0200, Niels Möller wrote:
> The unicode support I'm talking about is the ability to take the input
> stream and chop it up into units that are passed on to libtermserver
> input handling. That is support that is needed either in console or
> term, depending on h
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> I have no idea what you are talking about. It seems to be related to the
> thread, but you have to be much more precise. What is this Unicode support
> you are talking about, that my second half seems to be missing?
Sorry. I'll try again...
I was
On Wed, Sep 18, 2002 at 03:25:41PM +0200, Niels Möller wrote:
>
> > Nobody will use UTF-32 as their local encoding for the foreseeable
> > future, right?
>
> I really don't know. Right now, utf8 seeems almost as impractical as
> utf-32 to me, and I don't know how that will change when more progr
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Nobody will use UTF-32 as their local encoding for the foreseeable
> future, right?
I really don't know. Right now, utf8 seeems almost as impractical as
utf-32 to me, and I don't know how that will change when more programs
pick up support for large
On Wed, Sep 18, 2002 at 02:46:07PM +0200, Niels Möller wrote:
> Marcus Brinkmann <[EMAIL PROTECTED]> writes:
>
> > > 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 l
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> > 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 console does not know about single chara
Hi,
please apologize if I try to defend the libreadline idea a bit more. I am kinda
excited about the possibility to get all applications transparently use
libreadline if they use cooked mode. I might be pipe-dreaming...
On Wed, Sep 18, 2002 at 01:46:15AM -0400, Roland McGrath wrote:
> readlin
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 readli
13 matches
Mail list logo
