feat: wrap selection in <tag>, change surrounding <tag> and delete surrounding <tag>

[nik-rev]

NOTE: 1 feature from this PR I've moved to #12254 due to this one becoming too big in scope

---

Asciinema recording showcase of this feature: https://asciinema.org/a/EVuPLsPJnpPVclGH7dJjhvnrq

---

This PR was inspired by #11158 which adds text objects for XML, HTML and JSX tags allowing us to:

• select inside of a tag
• select the entire tag

A popular request is to add the ability to rename tags: #966
It would also be useful to delete surrounding tag, and add a tag around a selection

This PR adds those capabilities by adding x under the surround operations, since #11158 also uses x.

---

Change surrounding tag

1. mrx opens a prompt prefilled with the name tag surrounding the current selection (e.g. span).
2. When the user presses enter, the value of the prompt replaces the type of the tag surrounding the selection (if the user writes div, it'll replace span -> div)

Delete surrounding tag

1. mdx deletes the closest opening and closest tag to the cursor

Add surrounding tag

1. msx opens a prompt
2. When the user presses enter, the value of the prompt creates a tag around each selection of the same type (if the user writes div, it'll add a <div></div> around each selection)

Related to #966 and #6682

[kirawi]

I don't think the maintainers would accept this in core because it's language-specific. Not 100% sure though. They might make an exception since XML (in particular, HTML) is so ubiquitous. On the other hand, I also see them preferring to work on a snippet manager within Helix building upon #9801.

[gyreas]

I think a generalised one will be more practical, asin mic<tag>,</tag> like in Kakoune, which extends the single character mode

[nik-rev]

I don't think the maintainers would accept this in core because it's language-specific. Not 100% sure though. They might make an exception since XML (in particular, HTML) is so ubiquitous. On the other hand, I also see them preferring to work on a snippet manager within Helix building upon #9801.

I feel like it's still worth to add because, as you said - HTML is ubiquitous and it's extremely handy to have such useful tools embedded into the editor like surround selection with tag and delete it

For example we have text object support for functions, types etc right in the editor. These are also language agnostic, not all languages have types

So I think such generic utilities for working in tags in general will be fitting, but of course it's the maintainers' choice

[nik-rev]

I think a generalised one will be more practical, asin mic<tag>,</tag> like in Kakoune, which extends the single character mode

what do you mean by generalised? This PR doesn't depend on any sort of parser/language. I haven't used Kakoune

[nik-rev]

sidenote: The logic to delete surrounding tag and change surrounding tag ended up being significantly harder than I initially anticipated

I managed to get it working though! It took me quite a long time. I'll publish my changes tomorrow

It's super fun for me to learn Rust by implementing new features for a project which I love. I'll be happy if it gets merged, because I genuinely think this feature is really useful. but if it doesn't I'll also be happy :). I'm just doing this for fun!

Also I learned so much from this, I really fell in love with Rust. I started learning it about a week ago specifically because I wanted to add some features to this project which I myself wish it had: https://github.com/helix-editor/helix/pulls/nikitarevenco

[nik-rev]

Ok, so I just pushed all the changes and now all 3 functionalities work as expected!

[kacperwyczawski]

Good job, thanks!

[nik-rev]

Drafted since I realised there are several edge cases that the current implementation won't be able to cover, and there is some additional work that needs to be done

[nik-rev]

I'm going to close this since

1. you can rename tag with space + h
2. you can wrap selection with tag, see this comment
3. it's too dependent on HTML and i dont really think this should be in core
4. if it was added to core, the implementation would be completely different. In this PR I am brute searching text forward and backward. A better PR would use tree sitter queries