Don't highlight backslash-escaped brackets

[rolandwalker]

I've looked at #532, #533, #455, and am not entirely sure of your current thinking on this.

This PR addresses only backslash escaping. Current highlighting:

with patch:

Let me know if this is agreeable, and if so I will figure out how to add a test. Nice setup — tests/generate.zsh is easy.

This coding choice is idiosyncratic:

if (( escaped_state )); then
  :

but if this PR is accepted it will make a cleaner diff with my next one.

[phy1729]

I'm curious what the real world use case is that motivated this PR. A difference between '[' and \[ feels wrong, but I'm not a user of the brackets highlighter and only special casing backslash seems like a potentially reasonable middle ground to those who prefer brackets in quotes be highlighted.

On the PR itself just a few nits. L50 the variables are sorted alphabetically; please keep them in order. For the test I know the script uses $' quoting for BUFFER, but I think due to the number of backslashes and lack of single quotes, simple single quoting would be easier to read. Finally please sort the expectations; the unsorted=1 line will skip the in-order check and sorted is easier for humans to parse.

Other than those minor points the PR looks technically good. The question is should backslash escaped brackets be ignored.

[danielshahaf]

but if this PR is accepted it will make a cleaner diff with my next one.

What would your next PR do?

[rolandwalker]

@phy1729 Thank you for the review! The motivation was that I have been writing a lot of Lisp at the command-line, using tools like babashka, simple example

ls | bb -i '(filter #(-> % io/file .isDirectory) *input*)'

That is why it started to make sense to me to balance brackets within strings, though I think it would be better if each string was isolated and treated independently.

@danielshahaf I would like to add another bracket-highlighting style which highlights the balanced pair of containing brackets for any point the cursor may be on.