As I mentioned in #14715, I have implemented rudimentary extend variants of ma and mi. This resolves #12927.

This required a compromise: instead of ma and mi working based on the selection range, it now works based on the cursor. The benefit of this, however, is that you can compose surround motions together. For example, let's say we had this Rust code:

/// Finds the position of surround pairs of any [`crate::match_brackets::PAIRS`]
/// using tree-sitter when possible.
///
/// # Returns
///
/// Tuple `(anchor, head)`, meaning it is not always ordered.
pub fn find_nth_closest_pairs_pos(
    syntax: Option<&Syntax>,
    text: RopeSlice,
    range: Range,
    skip: usize,
) -> Result<(usize, usize)> {
    match syntax {
        Some(syntax) => find_nth_closest_pairs_ts(syntax, text, range, skip),
        None => find_nth_closest_pairs_plain(text, range, skip),
    }
}

If I wanted to highlight all of this, and assuming my cursor is at the top, I can type macxvmaf.

Additionally, matching can now be done via [ { ( word |) } ]| -> [ { |( word ) } ]| -> [ |{ ( word ) } |] -> |[ { ( word ) } ]| instead of [ { ( word |) } ]| -> |[ { ( word ) } ]|. You essentially gain more granularity, although at the cost of having to repeat surround motions (although giving it a count can minimize this). You also gain the ability to do something like this: ( w|ord ) ( word )| -> |( word ) ( word )|.

I understand that this may not be a worthwhile change since surround motions now no longer work with selection ranges. In my opinion it depends on what is most useful/prioritized; there's several conflicting priorities:

Current: Finding the closest pair based on the selection range (can overlap the selection range).
#8273: Finding the closest pair outside of the selection range (cannot overlap the selection range).
This PR: Finding the closest pair based on the cursor, which allows for extend variants of surround motions.

Another possibility, however, is some form of hybrid: Keep the current functionality (or #8273) for delimiter based matching and add extend functionality for semantic based matching such as maf, map, mac, etc.

Let me know what you think. I'd like to change the proposed code of this PR to fit one of these options.

Also, this PR is definitely not ready yet if we go with this - it has some issues in regards to mam not extending if the selection range is over a pair, even though it should. This is talked more in depth in #10611. I pushed a minimal implementation (with not a lot of testing) so I can hear from one of the maintainers about what should be done, if any of these options at all. In any case, this should close #8273 and close #12927, either because they won't be implemented or because I'll implement them once I have received a second opinion on what should be done.