event name and remaining
elements are event-parameter tuples. Thus multiple events of the same kind can
be sent contiguously without repeating the event name.

Example of a typical "redraw" batch in a single RPC notification: >

    ['notification', 'redraw',
      [
	['grid_resize', [2, 77, 36]],
	['grid_line',
	  [2, 0, 0, [[' ' , 0, 77]], false],
	  [2, 1, 0, [['~', 7], [' ', 7, 76]], false],
	  [2, 9, 0, [['~', 7], [' ', 7, 76]], false],
	  ...
	  [2, 35, 0, [['~', 7], [' ', 7, 76]], false],
	  [1, 36, 0, [['[', 9], ['N'], ['o'], [' '], ['N'], ['a'], ['m'], ['e'], [']']], false],
	  [1, 36, 9, [[' ', 9, 50]], false],
	  [1, 36, 59, [['0', 9], [','], ['0'], ['-' ], ['1'], [' ', 9, 10], ['A'], ['l', 9, 2]], false]
	],
	['msg_showmode', [[]]],
	['win_pos', [2, 1000, 0, 0, 77, 36]],
	['grid_cursor_goto', [2, 0, 0]],
	['flush', []]
      ]
    ]

Events must be handled in-order. Nvim sends a "flush" event when it has
completed a redraw of the entire screen (so all windows have a consistent view
of buffer state, options, etc.). Multiple "redraw" batches may be sent before
the entire screen has been redrawn, with "flush" following only the last
batch. The user should only see the final state (when "flush" is sent), not
any intermediate state while processing part of the batch array, nor after
a batch not ending with "flush".

By default, Nvim sends |ui-global| and |ui-grid-old| events (for backwards
compatibility); these suffice to implement a terminal-like interface. However
the new |ui-linegrid| represents text more efficiently (especially highlighted
text), and allows UI capabilities requiring multiple grids. New UIs should
implement |ui-linegrid| instead of |ui-grid-old|.

Nvim optionally sends various screen elements "semantically" as structured
events instead of raw grid-lines, as specified by |ui-ext-options|. The UI
must present such elements itself, Nvim will not draw them on the grid.

Future versions of Nvim may add new update kinds and may append new parameters
to existing update kinds. Clients must be prepared to ignore such extensions,
for forward-compatibility. |api-contract|

==============================================================================
UI startup							   *ui-startup*

UI embedders (clients that start Nvim with |--embed| and later call
|nvim_ui_attach()|) must start Nvim without |--headless|: >bash
    nvim --embed
Nvim will pause before loading startup files and reading buffers, so the UI
has a chance to invoke requests and do early initialization. Startup will
continue when the UI invokes |nvim_ui_attach()|.

A simple UI only needs to do a single |nvim_ui_attach()| request and then
prepare to handle any UI event. A more featureful UI, which might need
additional configuration of the Nvim process, should use the following startup
procedure:

1. Invoke |nvim_get_api_info()|, if needed to setup the client library and/or
   to get the list of supported UI extensions.

2. Do any configuration that should be happen before user config is loaded.
   Buffers and windows are not available at this point, but this could be used
   to set |g:| variables visible to init.vim

3. If the UI wants to do additional setup after user config is loaded,
   register a VimEnter autocmd: >lua
      nvim_command("autocmd VimEnter * call rpcrequest(1, 'vimenter')")

4. Now invoke |nvim_ui_attach()|. The UI must handle user input by now:
   sourcing init.vim and loading buffers might lead to blocking prompts.

5. If step 3 was used, Nvim will send a blocking "vimenter" request to the UI.
   Inside this request handler, the UI can safely do any initialization before
   entering normal mode, for example reading variables set by init.vim.

							   *ui-startup-stdin*
UIs can support reading from stdin (like `command | nvim -`, see |--|) as follows:

1. The embedding process detects that the stdin fd is not a terminal.
2. It then needs to forward this fd to Nvim. Because fd=0 is already is used
   to send RPC data from embedder