Vim mode surrounds for HTML tag

[weartist]

Check for existing issues

• [X] Completed

Describe the feature

At present, we have only improved the parentheses in the surrounds support, and there is no HTML support part, and we need to add HTML support as well

The required features are as follows:

• Adding a HTML Tag:

  • ys[motion]t : When triggering the add function, we need to allow the user to enter an HTML logo, which may be one, or just em, or div id='a', we need to parse it as much as possible into a pair of open and closed parentheses, and add them in the appropriate places, maybe also involve formatting issues such as automatic indentation, in short, the more convenient it is, the better

• Deleting a HTML Tag

  • dst: When triggered, this removes the nearest html tag of the current cursor, and we can look it up directly forward and backward, maybe we can also use tree-sitter to find it, or use vim's text-object to find tag

• Changing a HTML Tag

  • cst: change is a bit like the combination of add and delete, we need to match the specified tag entered by the user first, and then we need to receive the tag content entered by the user separately (of course, it may be in a variety of formats), and replace it, here is a question whether we need to directly replace the original full tag, for example:
  • <div id='a'>b</div> At this point, if we type CST and enter simple EM, should we replace the tag with b, there may be two options
  • 1. We only deal with the tag itself in the substitution mode, and do not make any changes to its properties
  • 2. We replace the whole

These features may need to prioritize support for normal mode for the time being, and as with the parentheses, visual mode will be placed in the next issue

If applicable, add mockups / screenshots to help present your vision of the feature

No response

[weartist]

I'm going to take a look at the code and see which one is more suitable, direct find, text object, or tree-sitter, I'm probably not going to be fast, so if someone is willing to put in, we can be together :)

[ConradIrwin]

@weartist always happy to pair! https://calendly.com/conradirwin/pairing

We recently added support for it and at as motions using tree-sitter, so we should reuse that logic for finding the tag.

For creating a new tag, I suggest we put you in insert mode in the opening tag, and when you hit escape, we copy the tag name over to the closing tag, but open to other ideas here.

We could potentially use multi-cursor, but I don't think that would work that well with attributes.

[weartist]

@weartist always happy to pair! https://calendly.com/conradirwin/pairing

We recently added support for it and at as motions using tree-sitter, so we should reuse that logic for finding the tag.

For creating a new tag, I suggest we put you in insert mode in the opening tag, and when you hit escape, we copy the tag name over to the closing tag, but open to other ideas here.

We could potentially use multi-cursor, but I don't think that would work that well with attributes.

Yes, it and at may make the implementation much easier, I can try the logic of delete right away. For add and change, can we use a pop-up input box to replace the insert mode, I thought of a point, if you use the insert mode to operate, when people leave or cancel halfway through the input, this will leave some half-finished content, maybe not good

[ConradIrwin]

Makes sense. We may be able to reuse/copy the rename editor https://github.com/zed-industries/zed/blob/af920a224b2facd2e7234bb2768d88e0c8ebf963/crates/editor/src/editor.rs#L8007 for this.

[weartist]

Will started providing a PR for the feature this weekend

[weartist]

@ConradIrwin Hi Conrad, Need to ask you with some minor questions, I read the code related to rename, and it seems that it is okay to use this control to surrounds tag display, but I have a little doubt, and the behavior of listening to rename is currently through editor pending_rename property, and some events are already registered inside editor, if we need to use it in vim, I'm not sure if we should add a similar property to vim as well, or if it would be better to continue to provide a further encapsulated component through editor, do you have any suggestions? I guess adding it to vim would make it easier to write, but it might make the code a little less good. Thanks！

[weartist]

@ConradIrwin Hi Conrad, Need to ask you with some minor questions, I read the code related to rename, and it seems that it is okay to use this control to surrounds tag display, but I have a little doubt, and the behavior of listening to rename is currently through editor pending_rename property, and some events are already registered inside editor, if we need to use it in vim, I'm not sure if we should add a similar property to vim as well, or if it would be better to continue to provide a further encapsulated component through editor, do you have any suggestions? I guess adding it to vim would make it easier to write, but it might make the code a little less good. Thanks！

For example, provides a function to create effects like rename UI, and uses a closure to easily perform subsequent operations

[ConradIrwin]

@weartist Sorry for the slow response here, I've been out for a few days.

The real answer is "I'm not sure".

I think it makes sense to re-use the pending_rename state (though maybe changing the name of the field) because we already do a bunch of stuff that you'll need in that case (intercepting keystrokes, disabling autocompletes, etc.). I also think the UX is a bit better than popping over a modal for this because the box will appear at the right place in the document.

That said, I'm not sure how much stuff is done by the rename state that you don't need... It seems like maybe the RenameState would need a callback to call instead of always doing project.perform_rename so that we can intercept the behavior in ConfirmRename? Not sure what else would be broken.

[weartist]

@weartist Sorry for the slow response here, I've been out for a few days.

The real answer is "I'm not sure".

I think it makes sense to re-use the pending_rename state (though maybe changing the name of the field) because we already do a bunch of stuff that you'll need in that case (intercepting keystrokes, disabling autocompletes, etc.). I also think the UX is a bit better than popping over a modal for this because the box will appear at the right place in the document.

That said, I'm not sure how much stuff is done by the rename state that you don't need... It seems like maybe the RenameState would need a callback to call instead of always doing project.perform_rename so that we can intercept the behavior in ConfirmRename? Not sure what else would be broken.

Yes, pending_rename could save a lot of effort, but it may be necessary to change the name for him, I'll take another hard look at reuse to see if there's anything unexpected wrong with it and start writing code, thank you very much