Next features or improvements?

[xavierog]

As these lines are being written (2024-06-03), Moulti has reached version 1.10.0 and already brings more features than initially envisioned.

[huyz]

Man this project is great. I've been thinking about this for years too—like you, especially because I use Ansible.
Thanks for making this. I'll vote once I've used moulti for a bit

[MartyLake]

Great project, thanks for creating it!

[MartyLake]

Another direction moulti could take, is move to the ad-hoc IDE. For example, instead of receiving logs, moulti could receive steps to execute, and have buttons/shortcuts to

1. re-run
2. watch conditions to trigger the re-run

Example step I would find very useful: make configure build test

Another possibility, is to have a one-line terminal at the bottom of moulti, so one can type the next command to run, here that would be either make build or make test because I know I don’t need to configure everytime.

Another possibility, is to have this one-line terminal support readline, so that "re-run" is effectively " " when moulti is focused.

[xavierog]

As a first reflex, I would check existing tools.

Existing tools

Steps to execute

The first use case you describe reminds me of these tools:

• procmux
• mprocs
• mintaka -- able to focus on the first error
• mk -- focused on Makefiles

Have a look, maybe one of those is a closer match to your requirements? I am not sure they "watch conditions to trigger the re-run" though.

One-line terminal at the bottom

I had thought of it but did not jump to implementation for various reasons:

• there is a library to add terminals to Textual applications (thus providing all your usual comfort: your usual shell, aliases, functions, readline configuration, fzf and whatnot) but, if I remember correctly, it is not resize-friendly and that can be a problem

• at the end of the day, this is easily achieved using tmux (and possibly tmuxp):

  

  (possible alternatives: screen, zellij)

Back to Moulti

Of course, considering Moulti's design (an empty shell that just sits there until an external process fills it with contents), it remains possible to cover your use cases. I invite you to explore the tools above to get a better idea of your ideal setup. If Moulti remains the best candidate, then we can determine:

• what extra core feature would be required to implement your use case
• whether your use case should become a non-core feature (like ansible / diff / manpage), an example or a separate tool.