DOCS/man/lua: suggest keep_open for nested mp.input calls

[guidocella]

Before #17251 keep_open was needed to make nested mp.input calls. Even after that change it is still better to pass it to not show console quickly closing and reopening to the user, so recommend it.

Depends on #17251.

[CogentRedTester]

I think that there are some fundamental concepts that have not been explained in the current documentation, namely:

1. That this is an asynchronous API.
2. That only one request can be active at a time (shared between all clients)
3. That if a new request is received while another is active, then usually the old request will be closed and the new one will be shown instead.
4. That input.select uses the same backend as input.get and so they cannot be active at the same time.
5. That input.terminate() and the log methods apply to whichever input happens to be active, even ones created by other scripts.

If we want to leave open the possibility of requests not always overriding each other in the future, then we could add a statement like "a way to prevent a request from being overridden may be added in the future, use opened to guarantee that an input request has been opened".

[guidocella]

Do you just want to take over in a new PR since you already have clear ideas of what to change?

If we want to leave open the possibility of requests not always overriding each other in the future, then we could add a statement like "a way to prevent a request from being overridden may be added in the future, use opened to guarantee that an input request has been opened".

Not sure what the use case for this would be though, it would just be reverting to the previous behavior.

[CogentRedTester]

Could probably do it as part of #17256 if there's interest in any of the changes suggested in there. We'd then be able to update the documentation with guarantees about when things run.

Not sure what the use case for this would be though, it would just be reverting to the previous behavior.

I just thought there might theoretically be a desire to specify an input request that cannot be overridden by new ones (if its for something theoretically important like a password prompt for a network file). If we explicitly guarantee in the documentation that all new requests will override old ones, then something like that isn't really possible in the future without breaking things. But, if we didn't guarantee that, and instead state that the opened callback is the only way to be 100% sure that the input is open, then the possibility remains open to us.

To be clear I'm not advocating for adding that kind of "high-priority" prompt, I just thought it might be worth keeping the option open since it's just a matter of wording in the documentation.

[kasper93]

Blocked by #17251.

[CogentRedTester]

I forgot about updating the documentation as part of the other PR. I may make a new PR to do so in the future, but for the time being we may as well merge this change.

[kasper93]

LGTM, thanks!