That looks right to me, but we also need to prevent dune from printing messages while such an action is running. This should be done globally via the Console module in src/stdune/console.mli.

That looks right to me, but we also need to prevent dune from printing messages while such an action is running. This should be done globally via the Console module in src/stdune/console.mli.

I'm unsure of what the behavior in this case should be. Should we silently eat anything sent to the console during such an action, or capture them to be output later?

Should we silently eat anything sent to the console during such an action, or capture them to be output later?

The latter seems much more reasonable to me.

Quoting Jeremie from the original issue:

Only one such action can run at a time, and while such an action is running messages emitted by dune would be put in a queue and rendered once the action has finished.

Adjust dune/context.ml to possibly take into account the selective terminal usage?

What needs to be adjust in context.ml?

Adjust dune/context.ml to possibly take into account the selective terminal usage?

What needs to be adjust in context.ml?

This was an idea I had when I was far less familiar with how the codebase functioned; I'm no longer sure what I really meant. I'll remove it from the PR description.

I'd really like to make Console.lock and Console.unlock idempotent (or, even better, expose only a safe interface for buffering, but I suspect that this would require pulling in Fiber), but I'm not really sure how a buffered console should interact with console composition (for that matter, I'm not sure that it currently does that correctly, either).

Wait, for that matter, what is terminal composition currently useful for? Neither grepping over the codebase or using github search seems to come up with any uses of it.

Please re-open if this is still relevant