Vim: Typescript/tsx anybrackets selection is wrong

[thomasheartman]

Summary

In a JSX/TSX component with multiple levels of brackets, anybrackets selects wrong and/or mismatching sets of delimiters. Using the actual brackets in the command (e.g. vi() works as expected.

Steps to trigger the problem:

1. Using the following bit of TSX (only the second component is necessary here, but the first one keeps the language server from complaining:

const SomeComponent: FC<{ attribute: () => void }> = ({ attribute }) => {
    return <div />;
};

const Component = () => {
    return (
        <SomeComponent
            attribute={(): void => {
                throw new Error('Function not implemented.');
            }}
        />
    );
};

2. Place your cursor on the word void or the last curly brace on that line
3. Do vib or vab and notice it does very weird things

Actual Behavior:

From void:

vib:

vab:

From {

vib:

vab (this one is actually correct):

Expected Behavior:

From void

vib (same as vi{):

vab (same as va{):

From {

vib:

vab:

Thoughts/observations

It looks as if the => construct in TS might be confused with a closing angle bracket, so that when going from void, it thinks the delimiters are the start of the component and the fat arrow: =>.

There appears to be a second bug here that I think was introduced recently with the fix for not selecting whitespace in a multi-line {} (this is relevant for the vi{ option). For all other vi selections, the cursor ends up at the end of the selection, but for the multiline vi{, it ends up at the start of the selection.

Zed Version and System Specs

Zed: v0.173.11 (Zed)
OS: macOS 14.6.1
Memory: 16 GiB
Architecture: aarch64

[5brian]

There appears to be a second bug here that I think was introduced recently with the fix for not selecting whitespace in a multi-line {} (this is relevant for the vi{ option). For all other vi selections, the cursor ends up at the end of the selection, but for the multiline vi{, it ends up at the start of the selection.

The cursor at the start of the selection for multi-line {} was actually on purpose to match nvim.

I think any visual bracket operations have the cursor at the start, paragraphs have the cursor at the start of the last line, and words and other motions/objects have it at the end in nvim(treesitter). I could be missing some, thats just from what i tried.

[thomasheartman]

The cursor at the start of the selection for multi-line {} was actually on purpose to match nvim.

Ah, right. I really don't mind it; I was just a little surprised that it was different from all the other cases. That said: I've never known which to expect, so I really don't mind 😅 If it's intentional, we can ignore that one.

[5brian]

Yeah i agree its weird haha, i have no preference i was just using nvim as a reference so i tried to match the functionality as much as possible.

If it's something nobody likes/has a preference maybe we can have it always move to the end, so it is more predictable? 🤷‍♂️

[thomasheartman]

To be honest, I think (heavy emphasis on "think") it makes more sense to me to always have the cursor at the start of the selection, but Vim puts it at the end. I'd assume that's why Zed does the same thing.

I don't have any strong preferences. I had to go check with vim to even make sure that was how it did it. Which probably indicates that I don't use it enough to voice a real opinion 😅 So ... yeah 🤷🏼 For consistency, it might be nice, but if no one complains, then it might not be worth spending time on 💁🏼