Re: [ipchat-devel] readline in ipchat

[Daniel Graña]

El Sun, 16 Jan 2005 13:58:25 +0100
Maximiliano Pin <address@hidden> escribió:

> Hello Daniel, and welcome to this list :-)
thanks.

> 
> It seems you're doing a nice job with ipchat, and thanks for that. You
> are so brave messing with the user interface code! hahaha.
really funny 8)=

> 
> When I begun working on the user inferface I thought about readline,
> but I wanted ipchat to have as few dependencies as possible. On the
> other hand, I'm now working on the use of autoconf/automake, and it
> would be nice to use readline when it is available (and still use the
> current code when not). Packages for debian and the like should have
> readline support enabled, since it's easy to resolve the dependencies
> there.
this looks some complex for me at the moment, i don't have experience
with autoconf/automake hacking but if you say it, i believe you :)

debian is the way, i friend of mime is working in packaging ipchat for
debian: Gonzalo, no know him.

> I have one question: can you somehow make compatible the use of
> readline with the "coloring as you write" feature of ipchat? Or this
> feature will be disabled when readline is used?

is compatible because this code use an alternate interface of readline
that can interact with your presentation code. At the moment, this
readline code only process input not output at all.

I use cb_read_key to intercept character (just like it was done) but
pass the char trought readline.

readline mantain the current line in rl_line_buffer variable, so before
return from cb_read_key(), cur->ibuf and related stuff is updated with
readline line status. To ipchat output code is transparent :)

When a new line is detected, readline call another function that do
the nasty thing and call input_enter() just like is was done before.

> 
> What I see most interesting about this is tab-completion. It would be
> somewhat hard to implement it without readline.

agreed, this is the coolest thing of readline.
May be we can add completation to contacts, commands and set variables.

and another ineherent feature is the power of the line editing using
emacs style or if you prefer vi style.

> About the "J" problem, it looks like the high-byte of the keycode is
> being ignored, so 0x0168 is being converted to 0x0068. Are you maybe
> using a char where you should use a short or an int? It's just an
> idea.

readline can not handle keys greater than 255, it can handle sequence of
keys using ESC, so the fix is ugly: key remap before calling readline.

the limitations at the moment  are: 
history works but is common for all contacts. (need some extra code)
F1 - F12 keys doesn't work because binding is not defined and are two 
posible solutions, so this feature is in "thinking..." state

"completation" is the next feature!! that i will be coding.


> Send the patch to this list when you want to. See you!
> Max.
> 

the patch is going just like "sale con fritas!" ;)
Saludos
Daniel,.-


> El domingo 16 de enero, Daniel Graña dijo:
> 
> > hi, I'm working in adding readline support to ipchat
> > 
> > as you may know, readline have a lot of features like line
> > editing, completations and history.
> > 
> > at the moment i'm having troubles with key bindings, this is funny
> > but when i map "end key" to "end-of-line" I get "J" going to end of
> > line too. Same with cursor keys.
> > 
> > J and END have different key code: 104 and 360, that give a 256
> > diference. :) that is a know point and looks like "the problem is
> > there" but in readline source code i dont find where is the code
> > that strip my code to 256 max.
> > 
> > I'm tired of going in circle so o decide to send you my notes and if
> > you are interested in this work i will proceed asking in readline
> > mailing list and supporting the code.
> > 
> > see you later.
> > Daniel,.-

ipchat-readline.patch.gz
Description: Binary data