_zsh_highlight_main_highlighter_highlight_double_quote:47: bad math expression

[CharlesGueunet]

How to reproduce

Trying to commit with the result of a date command as the message:

1. Typing: git commit -m "$(d

Current failure:

Each letter I type is followed by the message:

sed: -e expression #1, char 1: missing command

I think missing the color in the nested shell would be ok, but the current warning on each letter is quite inconvenient.

Thanks for this project BTW :)

[danielshahaf]

What's the output of typeset -p ZSH_HIGHLIGHT_VERSION ZSH_HIGHLIGHT_REVISION ZSH_VERSION ZSH_PATCHLEVEL on your system?

zsh-syntax-highlighting doesn't run sed(1), so the root cause of this lies elsewhere. You should bisect your configuration to find out where the sed(1) is from and report a bug to the appropriate place.

As to the "bad math expression" error. If @CharlesGueunet runs latest HEAD, then the line number refers to this line. Presumably $REPLY contains a string. It's declared local by _zsh_highlight, so perhaps _zsh_highlight_main_highlighter_highlight_list leaves REPLY set to a string, contrary to its docstring promise?

ENOTIME to investigate further at the moment.

[CharlesGueunet]

What's the output of typeset -p ZSH_HIGHLIGHT_VERSION ZSH_HIGHLIGHT_REVISION ZSH_VERSION ZSH_PATCHLEVEL on your system?

typeset -p ZSH_HIGHLIGHT_VERSION ZSH_HIGHLIGHT_REVISION ZSH_VERSION ZSH_PATCHLEVEL
typeset ZSH_HIGHLIGHT_VERSION=0.8.0-alpha2-dev
typeset ZSH_HIGHLIGHT_REVISION=HEAD
typeset ZSH_VERSION=5.9
typeset ZSH_PATCHLEVEL=zsh-5.9-0-g73d3173

zsh-syntax-highlighting doesn't run sed(1), so the root cause of this lies elsewhere. You should bisect your configuration to find out where the sed(1) is from and report a bug to the appropriate place.

Thanks, this one is indeed unrelated then.

As to the "bad math expression" error. If @CharlesGueunet runs latest HEAD, then the line number refers to this line. Presumably $REPLY contains a string. It's declared local by _zsh_highlight, so perhaps _zsh_highlight_main_highlighter_highlight_list leaves REPLY set to a string, contrary to its docstring promise?

ENOTIME to investigate further at the moment.

Thanks for this info,
the following patch saved my issue:

diff --git a/highlighters/main/main-highlighter.zsh b/highlighters/main/main-highlighter.zsh
index 7ec6249..a845a4d 100644
--- a/highlighters/main/main-highlighter.zsh
+++ b/highlighters/main/main-highlighter.zsh
@@ -1537,7 +1537,7 @@ _zsh_highlight_main_highlighter_highlight_double_quote()
               (( i += 2 ))
               _zsh_highlight_main_highlighter_highlight_list $(( start_pos + i - 1 )) S $has_end $arg[i,-1]
               ret=$?
-              (( i += REPLY ))
+              (( i += $REPLY ))
               last_break=$(( start_pos + i ))
               reply=(
                 $saved_reply

Can I do a merge request ?

[danielshahaf]

the following patch saved my issue:
Can I do a merge request ?

Of course. I've reviewed your #908 now.

I'm curious why that patch makes a difference. Could you drop a set -x and print -r - ${(t)REPLY} ${(t)reply} at the top of _zsh_highlight and post the output (attachment to the issue is fine)? In the output we should look for —

1. what the value of $REPLY is just before that line;
2. what $PREBUFFER / $BUFFER / $CURSOR are (to try and reproduce the issue).

[CharlesGueunet]

Can the issue be related to a bad cache ? I am not sure to understand but during my tests I reverted my changes and I do not have the issue anymore...

On the other side, I had several devices impacted by this issue.

[danielshahaf]

There are two layers of command word cache in play, and _zsh_highlight_main__type() does use $REPLY (as a string return value), so it's not impossible that this be related to the problem.

However, I think at this point it'd be more useful to identify a reliable reproducer for the issue.

[CharlesGueunet]

Totaly agree, I will try to see if I can find a reliable way to reproduce, otherwise I will close the issue.