Re: New key-binding system

[Owen Taylor <otaylor redhat com>]

Tom Tromey <tromey@cygnus.com> writes:

> >> Can you have multi-key bindings?
> 
> Owen> As of right now, it is not. It wouldn't be impossible to add
> Owen> (and is present, for instance, in Tk, and I think also in Xt),
> 
> FYI, Tk gets it wrong.  In Tk, if you have a binding for a sequence
> like "abc" and a binding for "bc", both will fire when you type in
> "abc".  I think this is hardly ever what you want, but then I'm
> partial to the Emacs keymap model.

Going to something like the emacs keymap model might actually
be a pretty nice way of doing it.

binding "control_x" {
  bind "<control>c" { "activate-menu" ( "File/Quit") }

  # bind-after bindings are effectively appended to each binding
  # in the binding set
  bind-after "remove-binding-set" (class, "GtkWindow", "control_x")
}

binding "commands" {
  bind "<control>x" { 
    "install-binding-set" (class, "GtkWindow", "control_x")
  }
}

class "GtkWindow" binding "commands"

I think this could handle also VI bindings pretty nicely. With
a little extra state in the widget, you could probably even
get numeric arguments. 

(The mind reels with interesting and scary ideas for making the
binding system more flexible - for instance you could have a syntax
for substituting widget arguments into the binding actions. Of course,
that goes towards making the binding system an esoteric interpreted
language)

> Owen> [ There are some slighlty sticky issues to worry about - on the
> Owen> matching side - for instance, we do have key-release bindings as
> Owen> well (or I think we decided to add them), so you need to make
> 
> Another approach would be to have the keybinding code gloss over this
> by removing low-level events it doesn't care about.  I don't know what
> the real goal is, though, so I don't know if this is a good idea.

Currently, the binding code is not meant to be nearly as general
as the binding in Xt or GTK. Event signals provide a flexible
way of binding events, and I think that is enough for mouse clicks,
etc. So the patterns do not match arbitrary sequences of X events,
but currently just single key presses or releases. Perhaps key
releases and key presses of modifier keys should just be ignored
when binding a sequence of more than one event. (Tk does something
like this, though slightly different)

> Owen> I suppose it would help with pseudo-vi bindings as well as
> Owen> pseudo-emacs bindings, though. You could get things like 'dd' to
> Owen> work, though not 'y4w'.
> 
> Yeah, vi requires more state than just a keymap.  So does Emacs if you
> want to handle prefix arguments.

Yes. My original goal with this binding thing was certainly not
to create a full VI or a full emacs, but just a big enough
subset that a user would feel comfortable. 

> Owen>  bind "xyz" { "activate-menu" ("File/Quit") }
> 
> Hmm.  I hope this doesn't work by looking at the actual menu labels.
> That will fail if the program uses gettext.

Well, as you've seen, the details of gettext and menus are
still to be worked out, but what I was thinking of above (which
is, as of yet, unimplemented) is that "File/Quit" is an ItemFactory
menu-path (they already exist), and they wouldn't be translated,
just the item names.

Regards,
                                        Owen