When a word contains angle brackets (e.x <path> or <...> as a placeholder in documents), the closing > is parsed as a new redirection operator. This creates a MISSING word node for the expected destination, which breaks syntax highlighting for following lines.
For example, parse the following bash code:
tree-sitter generates following nodes:
program [0, 0] - [2, 0]
redirected_statement [0, 0] - [0, 12]
body: command [0, 0] - [0, 5]
name: command_name [0, 0] - [0, 2]
word [0, 0] - [0, 2]
argument: word [0, 3] - [0, 5]
redirect: file_redirect [0, 6] - [0, 11]
destination: word [0, 7] - [0, 11]
redirect: file_redirect [0, 11] - [0, 12]
destination: MISSING word [0, 12] - [0, 12] // <- problem here
However when escaping the > character, tree-sitter builds node without problem:
program [0, 0] - [2, 0]
redirected_statement [0, 0] - [0, 13]
body: command [0, 0] - [0, 5]
name: command_name [0, 0] - [0, 2]
word [0, 0] - [0, 2]
argument: word [0, 3] - [0, 5]
redirect: file_redirect [0, 6] - [0, 13]
destination: word [0, 7] - [0, 13]
I think the parser should either:
- Better recover from the
MISSING node without affecting subsequent lines, or
- Recognize
<...> patterns in certain context as literal text rather than redirections
Environment
- tree-sitter-bash version: latest
- Observed in: Zed editor (via markdown language injection)
seems related with #275
When a word contains angle brackets (e.x
<path>or<...>as a placeholder in documents), the closing>is parsed as a new redirection operator. This creates aMISSING wordnode for the expected destination, which breaks syntax highlighting for following lines.For example, parse the following bash code:
tree-sitter generates following nodes:
However when escaping the
>character, tree-sitter builds node without problem:I think the parser should either:
MISSINGnode without affecting subsequent lines, or<...>patterns in certain context as literal text rather than redirectionsEnvironment
seems related with #275