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`.

vim-patch:9.2.0174: diff: inline word-diffs can be fragmented

Problem:  When using 'diffopt=inline:word', lines were excessively
          fragmented with punctuation creating separate highlight
          blocks, making it harder to read the diffs.
Solution: Added 'diff_refine_inline_word_highlight()' to merge
          adjacent diff blocks that are separated by small gaps of
          non-word characters (up to 5 bytes by default) (HarshK97).

When using inline:word diff mode, adjacent changed words separated by
punctuation or whitespace are now merged into a single highlight block
if the gap between them contains fewer than 5 non-word characters.

This creates more readable diffs and closely matches GitHub's own diff
display.

closes: vim/vim#19098

https://github.com/vim/vim/commit/42c6686c78d39843f71dba989a8ea59bc6975132

Problem:  'cursorline' and part of 'statusline' are missing after
          :diffput to an empty buffer.
Solution: Make sure the cursor doesn't go beyond the last line after
          :diffput (zeertzjq)

related: neovim/neovim#37621
closes:  vim/vim#19281

https://github.com/vim/vim/commit/ce1e562fdafa998e577d65a8b0a1b8bc1cbfcf4c

Problem:  Use-after-free in winframe_remove() (henices)
Solution: Set window_layout_locked() inside winframe_remove()
          and check that writing diff files is disallowed when the
          window layout is locked.

It can happen with a custom diff expression when removing a window:

 1. Buffer was removed, so win_frame_remove() is called to remove the
    window.
 2. win_frame_remove() → frame_new_height() → scroll_to_fraction()
    → diff_check_fill() (checks for filler lines)
 3. diff_check_fill() ends up causing a diff_try_update, and because we
    are not using internal diff, it has to first write the file to a
    buffer using buf_write()
 4. buf_write() is called for a buffer that is not contained within a
    window, so it first calls aucmd_prepbuf() to create a new temporary
    window before writing the buffer and then later calls
    aucmd_restbuf(), which restores the previous window layout, calling
    winframe_remove() again, which will free the window/frame structure,
    eventually freeing stuff that will still be accessed at step 2.

closes: vim/vim#19064

https://github.com/vim/vim/commit/ead1dda74a485ef0470e7252d07c1a36b8cde517

Nvim doesn't have this bug as Nvim uses a floating window as autocommand
window, and removing it doesn't need winframe_remove().

Co-authored-by: Christian Brabandt <cb@256bit.org>

Problem:  defaults: 'diffopt' option value can be improved
Solution: Update diffopt defaults to include "indent-heuristic" and
          "inline:char" (Yee Cheng Chin)

The default diff options have not been updated much despite new
functionality having been added to Vim.

- indent-heurstic: This has been enabled by default in Git since
  33de716387 in 2017. Given that Vim uses xdiff from Git, it makes sense
  to track the default configuration from Git.

- inline:char: This turns on character-wise inline highlighting which is
  generally much better than the default inline:simple. It has been
  implemented since vim/vim#16881 and we have not seen reports of any issues
  with it, and it has received good feedbacks.

closes: vim/vim#18255

https://github.com/vim/vim/commit/976b365305c2e9025813ff3c7fe52f8d927fafc3

Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>

Problem:  Crash when using inline diff mode
          (Ilya Grigoriev)
Solution: Set tp_diffbuf to NULL when skipping a diff block
          (Yee Cheng Chin).

Fix an array out of bounds crash when using diffopt+=inline:char when 4
or more buffers are being diff'ed. This happens when one of the blocks
is empty. The inline highlight logic skips using that buffer's block,
but when another buffer is used later and calls diff_read() to merge the
diff blocks together, it could erroneously consider the empty block's
diff info which has not been initialized, leaving to diff numbers that
are invalid. Later on the diff num is used without bounds checking which
leads to the crash.

Fix this by making sure to unset tp_diffbuf to NULL when we skip a
block, so diff_read() will not consider this buffer to be used within
inline diff. Also, add more bounds checking just to be safe.

closes: vim/vim#17805

https://github.com/vim/vim/commit/c8b99e2d139cf72c567892e44939f2719f703fa8

Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>

Problem:  not possible to anchor specific lines in diff mode
Solution: Add support for the anchoring lines in diff mode using the
          'diffanchor' option (Yee Cheng Chin).

Adds support for anchoring specific lines to each other while viewing a
diff. While lines are anchored, they are guaranteed to be aligned to
each other in a diff view, allowing the user to control and inform the
diff algorithm what the desired alignment is. Internally, this is done
by splitting up the buffer at each anchor and run the diff algorithm on
each split section separately, and then merge the results back for a
logically consistent diff result.

To do this, add a new "diffanchors" option that takes a list of
`{address}`, and a new "diffopt" option value "anchor". Each address
specified will be an anchor, and the user can choose to use any type of
address, including marks, line numbers, or pattern search. Anchors are
sorted by line number in each file, and it's possible to have multiple
anchors on the same line (this is useful when doing multi-buffer diff).
Update documentation to provide examples.

This is similar to Git diff's `--anchored` flag. Other diff tools like
Meld/Araxis Merge also have similar features (called "synchronization
points" or "synchronization links"). We are not using Git/Xdiff's
`--anchored` implementation here because it has a very limited API
(it requires usage of the Patience algorithm, and can only anchor
unique lines that are the same across both files).

Because the user could anchor anywhere, diff anchors could result in
adjacent diff blocks (one block is directly touching another without a
gap), if there is a change right above the anchor point. We don't want
to merge these diff blocks because we want to line up the change at the
anchor. Adjacent diff blocks were first allowed when linematch was
added, but the existing code had a lot of branched paths where
line-matched diff blocks were handled differently. As a part of this
change, refactor them to have a more unified code path that is
generalized enough to handle adjacent diff blocks correctly and without
needing to carve in exceptions all over the place.

closes: vim/vim#17615

https://github.com/vim/vim/commit/0d9160e11ce4b921adff1e5621dd989ce96fb0f3

Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>

Related https://github.com/neovim/neovim/commit/267494151bcc6e4fff7b9b8c80b7a5f42e2aa002

Problem:  inline word diff treats multibyte chars as word char
          (after 9.1.1243)
Solution: treat all non-alphanumeric characters as non-word characters
          (Yee Cheng Chin)

Previously inline word diff simply used Vim's definition of keyword to
determine what is a word, which leads to multi-byte character classes
such as emojis and CJK (Chinese/Japanese/Korean) characters all
classifying as word characters, leading to entire sentences being
grouped as a single word which does not provide meaningful information
in a diff highlight.

Fix this by treating all non-alphanumeric characters (with class number
above 2) as non-word characters, as there is usually no benefit in using
word diff on them. These include CJK characters, emojis, and also
subscript/superscript numbers. Meanwhile, multi-byte characters like
Cyrillic and Greek letters will still continue to considered as words.

Note that this is slightly inconsistent with how words are defined
elsewhere, as Vim usually considers any character with class >=2 to be
a "word".

related: vim/vim#16881 (diff inline highlight)
closes: vim/vim#17050

https://github.com/vim/vim/commit/9aa120f7ada592ed03b37f4de8ee413c5385f123

Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>