event-driven API?

[glyph]

I'd love to be able to have an application spying on a tmux session and waiting for particular things to happen (particularly, subprocesses ending, panes closing). To do this concurrently though the API would have to be non-blocking. Is this a possibility?

[tony]

@glyph, yes, it could be done via:

1. monitoring control mode events (tmux -C), more events get added every version
2. resyncing manually via _list_panes every n ms and checking for differences, this is more complete, but slowest

tmux also has silently added a hook feature which may or may not cover the gaps.

[tony]

how it gets added (concurrently) is interesting and can help with making the api clean. it'd have to be added

the the grunt work is the trade off between control mode and using list- commands to check status of objects and send events w/ the freshest data

[stale]

This issue has been automatically marked as stale because it has not had
recent activity. It will be closed if no further activity occurs. Thank you
for your contributions.

This bot is used to handle issues where the issue hasn't been discussed or
has gone out of date. If an issue isn't resolved and handled in a certain
period of time, it may be closed. If you would like your issue re-opened,
please create a fresh issue with the latest, up to date information and
mention this issue in it.

[glyph]

As far as I know nothing is out of date here?

[stale]

Thank you for updating this issue. It is no longer marked as stale.

[tony]

The bot can't tell that 😄

I'm also fine with the idea of an event-driven API on libtmux.

[stale]

Thank you for updating this issue. It is no longer marked as stale.