Re: [gtk-list] Re: New key-binding system

[matt <matt cgibuilder com>]

Owen Taylor wrote:
> 
> Basically, I don't think it is possible to write a VI
> binding without support from the widget. The binding setup

Right, each widget is going to store a little extra data.

> is not a full language - it has no concept of variables or
> conditionals - so it cannot maintain an internal
> state. Without state, you don't have VI.
> 
> So, basically, there would be a action signal like:
> 
>   "toggle_command_mode"

I'm against adding signals just to add new bindings.  the current
bindings don't need this signal so adding bindings shouldn't as
well.

> In insertion mode, the Text widget's key_press mode first
> handles the literal insertion of keys, then activates the
> binding; in command mode, the Text widget first activates
> the binding, and if no bindings matched, it then inserts the
> key literally.
> 
> I'm not a a VI expert (or user), but I think this should
> handle at least the basics. (Obviously, you don't get
> the ':' commands, etc, but I think that is beyond the
> scope of keybindings; just as an emacs mode isn't
> all of Emacs, a VI mode can't be all of VI)

This is what i think should happen.   The user hits a key.
the key sequence is passed a function like  bindkey(entry, keycode).

bindkey determinds if it should insert the character into the
entry and send out a signal.   

bindkey keeps all the state info updated in the entry. 


I don't know if the emacs keybindings send out a signal for motion
commands, but i know that vi bindings' of motion commands MUST NOT
send them out.  

it would confuse the hell out of the programmers and gtk programs.

I guess what i am trying to say is lets not make any more signals for
the programers to worry about.  Lets just keep the ones we have, and
let vi, emacs, windows, mac, and joe binding functions determine 
how text is inserted and signals are sent.

--matt wimer