alias including a newline is not highlighted anymore

[itchyny]

With the config

alias foobar='echo foo;
  echo bar'

foobar at the head of the prompt should be highlighted like a command but not highlighted. This used to work before the commit 9cc0060.

[phy1729]

Note that

alias foobar='echo foo
  echo bar'

will result in foobar being highlighted in green again.

The issue is that

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

Lines 694 to 700 in e2e97dd

	elif [[ $this_word == *':regular:'* ]]; then
	# This highlights empty commands (semicolon follows nothing) as an error.
	# Zsh accepts them, though.
	style=commandseparator
	else
	style=unknown-token
	fi

doesn't distinguish between ; ; (which is likely a typo) and ; followed by a newline (which while unnecessary doesn't indicate a likely typo).

[itchyny]

For reference, another failure case

alias foobar='git status ||
  echo failure'

[danielshahaf]

Thanks for the report and the diagnosis.

Triage: This is not a recent regression, there's an easy workaround (two, actually: you could also add a : after the semicolon (unless the thing before the semicolon is the start of a SHORT_LOOPS syntax loop)), and 0.7.0 is overdue; therefore I'm leaning towards not holding the release for this. (We could always do a 0.7.1.)

#651 adds code to distinguish between semicolons and newlines, which we could use here. I'll see what I can do about that. I guess the order of business is:

• release 0.7.0
• merge 'main': Highlight pipes inside array assignments as errors #651
• factor out the detection of $'\n' if possible
• fix this issue

Does this sound good?

@itchyny Naturally, if you'd like to look into a fix, you'd be welcome to.

[danielshahaf]

Documented in changelog as a known issue.

[danielshahaf]

Isn't this the same issue as #616?

[danielshahaf]

Isn't this the same issue as #616?

It's related but not the same. Compare these two tests:

zsh-syntax-highlighting/highlighters/main/test-data/alias-comment1.zsh

Lines 30 to 37 in 54e1828

	# see alias-comment2.zsh
	setopt interactivecomments
	alias x=$'# foo\npwd'
	BUFFER='x'
	expected_region_highlight=(
	'1 1 alias "issue #616"' # x
	)

zsh-syntax-highlighting/highlighters/main/test-data/comment-followed.zsh

Lines 31 to 38 in 54e1828

	setopt interactivecomments
	BUFFER=$'# foo\ntrue'
	expected_region_highlight=(
	'1 5 comment' # # foo
	'6 6 commandseparator "issue #501"' # \n
	'7 10 builtin' # true
	)

With #651 having been merged, the second test sees arg=$'\n' but the first test does not, because the alias parsing codepath runs ${(z)} separately.

To complicate things, there's another test that calls itself #616:

zsh-syntax-highlighting/highlighters/main/test-data/empty-command-newline.zsh

Lines 31 to 39 in 54e1828

	# Newline after semicolon isn't unknown-token
	BUFFER=$':;\n:'
	expected_region_highlight=(
	'1 1 builtin' # :
	'2 2 commandseparator' # ;
	'3 3 commandseparator "issue #616"' # \n
	'4 4 builtin' # :
	)

So:

• Update alias-comment1.zsh to refer to this issue. Keep empty-command-newline.zsh referring to Empty command check false positives #616.
  Status: done in e94dc89
• Ask zsh upstream to add a ${(Z)} mode that preserves newlines as newlines, so we don't have to re-implement the a4525a0 dance everywhere we use ${(z)}, such as in the aliases code.
  Status: opened Ask zsh upstream to have a ${(Z)} subflag that doesn't map newlines to semicolons #693
• Fix Empty command check false positives #616 and Newline after comment should be commandseparator #501 using main: Highlight closing brackets #561.
  Status: done in 9134cdf.
• To fix this issue, we'll need to re-apply a4525a0 to the ${(z)} use in the alias-parsing code, or to implement the ${(Z)} subflag and wait for a zsh release that includes it. (As of this writing, the latest zsh release is 5.8.)

[danielshahaf]

A third workaround is to convert the alias to a function. In the given example that's probably a good idea anyway, since functions can't misfire when used in SHORT_LOOPS loop bodies. (alias x='date; pwd'; repeat 2 x)