Open weartist opened 4 months ago
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 :)
@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 always happy to pair! https://calendly.com/conradirwin/pairing
We recently added support for
it
andat
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
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.
Will started providing a PR for the feature this weekend
@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!
@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 editorpending_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
@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 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 doingproject.perform_rename
so that we can intercept the behavior inConfirmRename
? 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
Check for existing issues
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:
Deleting a HTML Tag
Changing a HTML Tag
<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 optionsThese 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