This would be great for Oni! I'd like to explore some new ways of rendering messages in the UI.

So, this should basically work for early testing. Multiple msg_chunk calls build up a msg line, msg_end tells the line is finished. msg_start_kind(...) tells the kind for some kinds of messages, but clients should be prepared msg_chunk:s come without a msg_start_kind(). msg_showcmd([attrs, text]) works independently of all other events.

Currently these is no concept of "multi-line messages", the API should probably try to recover it where it is possible, for instance single multiline nvim_out/err_write call.

I have only tested ext_messages also with ext_cmdline. I do not plan to test ext_messages without ext_cmdline; we should throw error in this case, or just make the former imply the later.

Rebased. Also changed:

• ext_messages=true now formally implies ext_cmdline=true
• highlights are now specified by id. This makes sense with [RDY] UI grid protocol revision: line based updates and semantic highlights #8221

Some more progress of this (partly because I think I understand a bit more how message.c works, and partly because this will be useful for #8455 and #8707).
Now the event format is

msg_show(kind, [["text", attr], ["more text", other_attr]], keep_batch)

which is probably closer to what UI:s want (rather than to how the msg_ semi-abstraction is constructed internally). The intention behind the "keep_batch" parameter is to signal if the message should continue to build up a batch of messages,(:echo (+ will show two error messages, but they are always displayed together), or if the previous message should be considered "done" and replaced by a new message.

It is not clear however how it should work when you type : att a "press return" prompt, where you now can keep building a batch of scrolled messages, even if they are technically unrelated. We should provide clients with the necessary information to replicate this behaviour if they so want.

Without this feature, 'cmdheight' will control how many message lines nvim will display without invoking a "press RETURN" prompt. Currently this branch works as if cmdheight=∞, but we probably want to give clients more control. Either:

• implement nvim-side heuristic when a message is considered "large". We can count the number of individual messages and (hard) line-breaks and compare with a client supplied number (which still could be ∞ if it so wants)
• when nvim is unsure whether a prompt should be displayed or not, do a synchronous call to the client. Either the client could wait for the user itself, or just return whether the current message batch is "large" and thus nvim should wait for return.

The latter is somewhat of a break of the current external UI design, but there a more situations where synchronous UI calls would be useful, such as client interpreted movement commands in #8707 and potentially first class support of dialogs.

The intention behind the "keep_batch" parameter is to signal if the message should continue to build up a batch of messages,(:echo (+ will show two error messages, but they are always displayed together), or if the previous message should be considered "done" and replaced by a new message.

How about calling this more instead of keep_batch? That's what we use for nvim_buf_lines_event.

Without this feature, 'cmdheight' will control how many message lines nvim will display without invoking a "press RETURN" prompt. Currently this branch works as if cmdheight=∞, but we probably want to give clients more control. Either: ....

I'm hoping for a third approach: remove the blocking nature of "press RETURN" entirely. I've been experimenting with this in a local branch, and it works nicely.

• The most basic approach is that instead of "press RETURN", the wall-of-text goes away as soon as the user hits any key (the pager is opt-in via g> instead of opt-out).
• Another idea: let users specify a maximum height for the wall-of-text, and they can clear it with CTRL-L. And again, they can opt-into the pager via g> .

Messages should be passive and opt-in, instead of constant in-your-face panic.

How about calling this more instead of keep_batch? That's what we use for nvim_buf_lines_event.

Maybe. This is still at the design phase, rather than the name bikeshedding phase :P Also the semantics are currently the reverse of buf_lines.

I've been experimenting with this in a local branch, and it works nicely.

It would be nice to see this branch.

I'm hoping for a third approach: remove the blocking nature of "press RETURN" entirely. [...] Messages should be passive and opt-in, instead of constant in-your-face panic.

I think my post was pretty clear in giving clients control, which implies giving users control (by configuring their UI, or using the UI that fits their use case). Clients being able to reimplement cmdheight=1 is not a consequence of this behavior being objective good (though personally I would like to experiment with behavior similar to something likecmdheight=2...3, where the blocking nature also can depend on the severity of the message), rather just of clients/users actually having full control to implement the behavior they want. The cmdheight=∞ case as I already mentioned would be the passive, avoid blocking as much as possible, strategy.

I think my post was pretty clear in giving clients control, which implies giving users control (by configuring their UI, or using the UI that fits their use case).

Yes but the "somewhat of a break of the current external UI design" would be good to avoid, I guess. And working well by default is preferable.

And working well by default is preferable.

I don't think I have or would argue against this :) My point is that ext_messages shouldn't be needlessly tangled together with a larger "press RETURN" refactor (which it sounds your branch hints at), which has a different purpose and we surely want to work with or without external UI...

The purpose of ext_messages is just to say how messages should displayed when the global grid no longer exists, or at least cannot just overdraw windows which are on separate grid. The concern would rather be to make sure that ext_messages is forward compatible with such a refactor, and I fail to see anything I have suggested or implemented would impede that (I would be happy to actually see your code, if it proves otherwise...)

Yes but the "somewhat of a break of the current external UI design" would be good to avoid, I guess.

As I already mentioned this will be very useful for other stuff. It would be the most straightforward way to implement :wincmd j (which must be synchronous, as it can be invoked as part of a script) when the UI has control over layout, rather than nvim. It would be huge and inconvenient limitation for future external UI work if nvim is forbidden to ever ask the UI a question...

:wincmd j ... It would be huge and inconvenient limitation for future external UI work if nvim is forbidden to ever ask the UI a question...

Hmm. If UI defines the layout, this is circular. What happens for winrestcmd() and getwininfo()?

If UI defines the layout, this is circular.

How is it circular? #8707 prototypes this today: nvim asks the UI for what window is below a specific handle, and it replies with the relevant window handle. Then nvim enters that window, exactly as if it has queried an internal datastructure as it does without ext_windows.

I see nothing in getwininfo() that is affected by this, but perhaps some vim patch will add neighbour info? winrestcmd() seems to only contain size info, it only restores after a resize (or open/close a temp window, so you get back again to where you were), not a complete change of layout?

Thanks for the latest commits and the helpful docs.

Sorry, I didn't realize that showmode was supposed to clear the recording message. I can confirm that it's working as intended now.

I can also verify that :messages sends the msg_history_show event with previous messages.

Multiline messages can now be concretely tested with lua:

:lua error("lol\nmultiline\nmessage")

I think we should merge this, so it doesn't sit around forever. This PR now implements the MVP of letting the UI control the display of the message instead of grid. More fine grained control of the flow will be a follow-up (possibley based on feedback from UI implementers using the MVP).