Backslash-newline mid-token causes highlight offset

[phy1729]

Idea from zsh-users/zsh@40723b3

# PREBUFFER=$'echo $\\\n'
# BUFFER=$'(echo foo)'
not ok 1 - [1,8] «(echo fo» - expected (1 10 "default"), observed (1 8 "default").
not ok 2 - [1,8] «(echo fo» - expected (1 10 "command-substitution-unquoted"), observed (1 8 "command-substitution-unquoted").
not ok 3 - [1,3] «(ec» - expected (1 1 "command-substitution-delimiter-unquoted"), observed (1 3 "builtin").
not ok 4 - [5,7] «o f» - expected (2 5 "builtin"), observed (5 7 "default").
not ok 5 - [8,8] «o» - expected (7 9 "default"), observed (8 8 "command-substitution-delimiter-unquoted").
not ok 6 - unmatched expectation (10 10 command-substitution-delimiter-unquoted)
not ok 7 - cardinality check - have 6 expectations and 5 region_highlight entries: «expected_region_highlight=( $'1 10 default' $'1 10 command-substitution-unquoted' $'1 1 command-substitution-delimiter-unquoted' $'2 5 builtin' $'7 9 default' $'10 10 command-substitution-delimiter-unquoted' )» «region_highlight=( $'0 8 default' $'0 8 command-substitution-unquoted' $'0 3 builtin' $'4 7 default' $'7 8 command-substitution-delimiter-unquoted' )»
# expected_region_highlight                        region_highlight
# '1 10 default'                                   '0 8 default'
# '1 10 command-substitution-unquoted'             '0 8 command-substitution-unquoted'
# '1 1 command-substitution-delimiter-unquoted'    '0 3 builtin'
# '2 5 builtin'                                    '4 7 default'
# '7 9 default'                                    '7 8 command-substitution-delimiter-unquoted'
# '10 10 command-substitution-delimiter-unquoted'

Adding

      [[ $arg == '$('* && ${proc_buf[offset + 1,offset + 4]} == $'$\\\n(' ]] && { proc_buf=${proc_buf[3,len]}; buf_offset+=2; }

after

zsh-syntax-highlighting/highlighters/main/main-highlighter.zsh

Line 651 in 00c0c76

[[ $arg == ';' && ${match[3]} == $'\n' ]] && arg=$'\n'

fixes the issue, but that's clearly too specific.

[danielshahaf]

Compare #705, which is also about continuation lines. There's a zsh patch attached to #705. With that patch, however, multicharacter tokens with a backslash-newline partway through wouldn't be recognized. Therefore, that patch won't fix this issue by itself. I'm tempted to label this issue resolution:if-and-when-needed, actually. Thoughts?

[phy1729]

I was tempted to add the label too. Applied.