You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was wondering about the tag text object in Vim and how best it could be brought over to Helix.
I saw that #3282 went nowhere and its scope is also quite limited, so if there is interest I could perhaps take a stab at implementing a more general approach.
My idea would be a combination is surround support and match-inside/around support for tags, and would work like this:
Surround add tag (mst)
Take all current regions, save them temporarily similar to mr".
Surround every range with <_> and </_>, place a cursor inside them (_) and enter insert mode.
Place the tags on new lines for regions where only entire lines are selected, indenting said regions.
User starts typing the tag name.
Hitting <space> removes the cursors from the closing tags, allowing the user to enter attributes.
Hitting <esc> ends the operation and restores the saved regions.
Surround replace tag (mrt)
Take all current regions, save them temporarily.
Find the closest surrounding tag, ignoring siblings, strings and escaped characters (see poll).
Select the tag_name part of the surrounding tags, and call change_selection on them.
Hitting <space> removes the cursors from the closing tags, allowing the user to edit attributes.
Hitting <esc> ends the operation and restores the saved regions.
Surround delete tag (mdt)
For each region, find the closest surrounding tag (see poll).
Remove tags.
If a tag was on its own lines, unindent its children.
Match around tag (maT)
Repeatedly apply expand_selection until the selection is a complete element
Match inside tag (miT)
Similar to maT, but new tree-sitter queries are required because currently "children of a tag" is not a node.
The issue is I'm not sure where this would be best implemented. It can be argued that implementing a whole new tokenizer for this is stupid when tree-sitter is already supported but then tags cannot be edited in strings, for example. A tree-sitter-based implementation would be more in line with how Helix operates, plus it would allow for supporting languages what have different syntax but similar closing tags (e.g. XY / endXY), but it would have a limited scope (basically xml, php, and html files or injections only).
Or perhaps this would be best served by a plugin?
Opinion on surround and match support for XML tags?
Not needed at all
0%
Should be handled by language servers
14%
Should be handled by a plugin
0%
Should be handled in core, utilizing tree-sitter
71%
Should be handled in core, independent of tree-sitter (with custom tokenizer)
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Tags
I was wondering about the tag text object in Vim and how best it could be brought over to Helix.
I saw that #3282 went nowhere and its scope is also quite limited, so if there is interest I could perhaps take a stab at implementing a more general approach.
My idea would be a combination is surround support and match-inside/around support for tags, and would work like this:
Surround add tag (
mst
)mr"
.<_>
and</_>
, place a cursor inside them (_
) and enter insert mode.<space>
removes the cursors from the closing tags, allowing the user to enter attributes.<esc>
ends the operation and restores the saved regions.Surround replace tag (
mrt
)tag_name
part of the surrounding tags, and callchange_selection
on them.<space>
removes the cursors from the closing tags, allowing the user to edit attributes.<esc>
ends the operation and restores the saved regions.Surround delete tag (
mdt
)Match around tag (
maT
)expand_selection
until the selection is a completeelement
Match inside tag (
miT
)maT
, but new tree-sitter queries are required because currently "children of a tag" is not a node.The issue is I'm not sure where this would be best implemented. It can be argued that implementing a whole new tokenizer for this is stupid when tree-sitter is already supported but then tags cannot be edited in strings, for example. A tree-sitter-based implementation would be more in line with how Helix operates, plus it would allow for supporting languages what have different syntax but similar closing tags (e.g.
XY / endXY
), but it would have a limited scope (basically xml, php, and html files or injections only).Or perhaps this would be best served by a plugin?
7 votes ·
Beta Was this translation helpful? Give feedback.
All reactions