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

[matt <matt cgibuilder com>]

Owen Taylor wrote:
> 
> matt <matt@cgibuilder.com> writes:
> 
> > That is kind of what i was thinking except there needs to be a way to
> > handle
> > when the user hits the <esc> key.    in this case if the user is in
> > insertmode
> > then they drop to command mode.  BUT, if they are in command mode the
> > <esc>
> > is sent to the handler.    NOTICE  this is differnt then the example
> > above, which
> > is why i think i have problems with the proposed methodology.
> 
> This is more tricky; but what does escape do in command mode
> for VI? Nothing, right? At least my approach to VI is
> compulsively hit escape to make sure I'm in the right mode,
> and it never seems to do harm...
>

Well it won't do any "harm" as long as the ket_press_event handler
doesn't
do anything evil.  I can see how that would be a problem at times, but
if the handler is "looking" for <esc> then im pretty certain that the 
worst that can happen in current action is terminated.  whatever 
the current action is.  

i have a text widget i popup in its own window.  if the user
hits <esc> then i just close the window.  not really bad thing.

> [ This does show that it needs to be "set-command-mode" not
>   "toggle-command-mode" ]
> 
> If you really need state-dependent processing, you can
> have action-signals that are ignored in one state, and activated
> in another, but I think trying to do that in the bindings is heading
> towards making the bindings a scripting language, which is
> not where we want to go. [ Inventing a new scripting language
> is, nowdays, _never_ the right thing to do, IMO ]
> 
> Though, one example I used when I first proposed this to
> Tim Janik was for an application with an embedded Perl
> interpreter:
> 
>  bind "<Alt>:" {
>   "execute-script" ("$e = shift; $e->set_text (eval $e->get_text)")
>  }
> 
> [ For an Entry ]

Hmm, well i would think that this binding subsystem would be one of many
binding types.    so the user would have the choice of:  emacs, vi,
regular,
and finally "custom."<- the one where the user can customize every key
to their
hearts content(well to the extent the "custom" binding type lets them.)

i don't see think the custom binding type will be powerful enough to
handle
all the strange and funky things a vi mode would need.

I just want to see that we can insert as many 
key binding subsystems in as users feel we need.

--matt wimer