Wait until `<condition>` to send command (blocking send command)

[thomasballinger]

I'd find blocking send command functionality useful. So far I've tried waiting for the window title to change back to the shell, waiting for the shell prompt to appear, and waiting for the cursor to move to a new position / the size of the scrollback buffer to increase by a certain amount. Any thoughts on how this could be implemented?

[tony]

@thomasballinger : Are you doing this via Python API (I assume) or config file?

Do you have any report on your progress with these approaches?

[thomasballinger]

I've been using the Python api, here's the helper I'm currently using:
https://github.com/thomasballinger/rlundo/blob/master/test/tmux.py#L58

Waiting for the prompt to appear (when it can be predicted) is the approach I'm using now. Checking the window title doesn't seem helpful because we can only poll it and might miss it changing (if it's even guaranteed that it will change).

[tony]

@thomasballinger : Would it be helpful to you if tmuxp would return the process tree of what's underneath a server / session / window / pane?

PID / process name being ready would give you something solid to poll against.

To give you an idea of the data that could be exposed, do pstree -p -a -A | less and search (/ key) for tmux.

[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.

[tony]

@thomasballinger 1.10 has experimental sleep/skip support: https://tmuxp.git-pull.com/history.html#tmuxp-1-10-0-2022-03-19

Not the same as scanning contents and waiting for shell commands to finish, but those can sometimes achieve equivalent outcomes

[thomasballinger]

🎉

[categulario]

I just looked at the implementation of wait_for_condition and it mostly overlaps to my proposal in tmux-python/libtmux#372 .

There are some key differences though:

• retry() requires as only argument a polling function, which has no connection whatsoever with a pane, window or any other libtmux object.
• wait_for_condition pauses queries with an interval, which I think is a good idea to prevent the processor to going crazy polling if the response is going to take a few milliseconds anyways.