Problem:
For an incomplete sequence at the end of the string, utf_ptr2len_len()
reports more bytes than are there, and mb_utf_index_to_bytes() returns
that position unclamped:

    vim.str_byteindex('ab\xf0\x9f', 'utf-16', 3, false)  --> 6

on a 4 byte string. LSP callers use the result as a column, so
nvim_buf_set_extmark() then fails with "Invalid 'col': out of range".

Solution:
Clamp the returned byte index to the length of the string.

AI-assisted

Problem:
`vim.on_key()` callbacks are invoked for keys that `getchar()` consumes,
which never reach the main loop, and there is no way to tell such a key
apart.  With ui2 the `on_key` handler activated after interactive
cmdline, handles it as `pager_char` (thus enters the ui2 pager).

Solution:
Skip `vim.on_key()` callbacks during `getchar()`/`getcharstr()`.

Problem:
The magic globals `it`, `describe`, etc., are more trouble than they are
worth.

- Hooking into `after_each` requires `getfenv()` hacks.
- They confuse luals/emmylua, because the top-level `.luarc.json` isn't
  merged with `test/.luarc.json` (apparently a luals limitation?)
- They totally defeat discoverability because the user just has to
  "know" about the various magic symbols.

So they harm DX, which means they serve no purpose at all.

Solution:
- Expose the test API from `testutil`, so tests can call `t.it()`,
  `t.describe()`, etc., in the conventional way.
- Drop `getfenv()` hacks.
- Drop the `setfenv()` injection in `load_chunk`.
- Drop `test/_meta.lua`.

fix(iconv): conversion to utf-16be using iconv is inconsistent

vim-patch:9.2.0769

Problem:  enc_canonize function changes utf-16be to utf-16 but in linux
          type utf-16 defaults to utf-16le.

Solution: Creating a separate entry for utf-16be in enc_canon_table.
          Note: the effect is only visible on iconv implementations that
          treat "utf-16" and "utf-16be" differently, so the test does
          not necessarily fail on an unpatched Vim. But the bug is
          visible in vim.iconv. (Manoj Panda)

from: vim/vim@2a63f74
closes: neovim#40262

Signed-off-by: Manoj Panda <manojpandawork@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>

Problem:
It is repetitive to map multiple keymaps to do the same thing. Here are some
cases where being able to do this would be useful:

    -- Visual movement for both j/k and down/up:
    vim.keymap.set({ 'n', 'x' }, { 'j', '<Down>' }, 'v:count == 0 ? "gj" : "j"', { expr = true })
    vim.keymap.set({ 'n', 'x' }, { 'k', '<Up>' }, 'v:count == 0 ? "gk" : "k"', { expr = true })
    -- Map multiple keys to `<Nop>` concisely:
    vim.keymap.set({ 'n', 'x' }, { '<Leader>', '<Localleader>', '<CR>' }, '<Nop>')
    -- Remove multiple keymaps at once:
    vim.keymap.del('n', { 'gri', 'grn', 'grr' })

Solution:
Support the `lhs` of `vim.keymap.set()` and `vim.keymap.del()` being a table, in
the same way that `modes` can be.