Support for Signals/Events

[maclomhair]

In this patchset I have included support for VTE signals like "contents-changed", much in the same manner also keybindings and mouse events are implemented.

events would be bound by calling bindEvent(eventname, handler_func)

So far only the event for "contents-changed" has been implemented, but any other VTE event should seamlessly integrate into the created infrastructure.

I think one could also think about including a bindTimer function to support timers - e.g. to regularly check the contents of the terminal for some value. This would be some more work, though.

[nonstop]

Hi
Thank you for the patch.
I want to clarify some details.
Several VTE signals are already used by termit implementation. How termit should handle the situation when user adds handler for "bell" or more interesting for "child-exited" event?
I understand that it may be useful sometimes to handle "contents-changed". I don't understand what is the point to handle such signals as "commit", "text-inserted", "text-modified" and so on.
May be it would be better to allow binding a callback exactly for "contents-changed".
onContentsChanged = user-function

Termit uses lua for configuration but it is not supposed to be a lua binding for libvte.

[maclomhair]

Yes, I saw that termit already has some signal handlers in place. Also, I agree that termit is no libvte binding and that not all signals are in any way useful and only a few should be exported to the lua environment.

Just so I get that correctly: you are suggesting we make the bindings work like in setStatusbar in the termit options table?

I think this approach is also slick and nice. Unfortunately, this introduces some inconsistencies with how keyboard and mouse events are handled - which are events as well...

Another feature I would consider useful, is a periodic timer event. The function to be called could be stored in the event infrastructure created with this patch, but overall the effort needed for building this should be rather low. For registering a timer, a bindTimer function would be more elegant than an option in the TermitOptions table, I think, which is why I propose to stick to a bindEvent function.