No highlighting for aliases containing function

[jtyr]

If I define an alias:

alias xxx='ls -la'

and then type xxx, it highlights it just fine. But if I define alias containing a function:

alias xxx='f(){ ls -la; }; f'

and then type xxx, it doesn't highlight it as a known command.

[phy1729]

That's because when highlighting f(){ ls -la; }; f the second f is not recognised as a function (as it isn't defined yet). More or less a dup of #223.

For this case in particular, I'd move the function definition out of the alias.

[jtyr]

Not sure if I understand correctly, but are you saying that you are analyzing the value of the alias somehow? Wouldn't be better to highlight any alias regardless its value?

[danielshahaf]

Yes, we do, in order to highlight alias foo=not-installed in red.

[danielshahaf]

I strongly recommend to change the alias's definition (or convert it to a function) as it'd DTWT in a SHORT_LOOPS context.

[danielshahaf]

@jtyr alias foo='bar; baz' followed by repeat 2 foo will execute baz once, not twice. That's similar to the need for parentheses and do { … } while (0) guards in C preprocessor macros.

[danielshahaf]

As to the issue, I don't think it's a duplicate of #223 as that issue doesn't involve function calls, only function definitions.

Cases such as repeat 'RANDOM % 2' f(){}; f mean we can't just highlight the call in green, either.

Perhaps we could highlight the call as indeterminate; compare #695.

[jtyr]

I think it would be really useful to have a switch to enable/disable the validation of alias values. I would personally prefer to have any defined alias green even if the value would lead to non-existing command. Something like this:

ZSH_HIGHLIGHT_STYLES[validate_alias_value]='no'

[phy1729]

That's not really an option as the words after an alias may not be arguments.

alias foo='echo Hello &&'
foo echo World

or

alias foo='sudo -u foo'
foo echo bar

In both cases echo should be recognized as a command, but to do so we have to look into the alias. It's possible to ignore unknown-token highlights encountered when expanding an alias by adding another condition to

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

Line 80 in e851724

[[ $1 == unknown-token ]] && alias_style=unknown-token

(though the configuration option shouldn't live in ZSH_HIGHLIGHT_STYLES).

I second the strong recommendation to at least move the function definition out of the alias. It seems odd to redefine a function each time an alias is run aside from the other issues @danielshahaf pointed out.

Regarding highlighting function use after definition in one line, we could handle the usual case of not being in a loop or behind a conditional (including && or ||) and keep track of functions which we know will exist.

[jtyr]

It would be really great if this behavior would be configurable in any way. I think it's more important to highlight perfectly valid alias as green than invalid alias as red.

[danielshahaf]

@jtyr Please distinguish the desired behaviour from the proposed way to obtain it. Both @phy1729's and my ideas about changing the highlighting of function definitions would cause the alias not to be highlighted in red, without adding configuration knobs (which, if necessary, may depend on #362).

In any case, since consensus is that your alias should be changed, I'm not sure I'd accept that particular alias as a use-case/justification for any functional change. Hard cases make bad law.

Note: two distinct, but related, topics are being discussed: 1. Highlighting aliases as green iff they exist (as older zsh-syntax-highlighting did); 2. Highlighting function define-and-call.

[jtyr]

I understand that if I externalize the function it would work just fine. But there is a reason why I have the function definition inside the alias and from shell point of view that's absolutely valid alias definition. I believe it would make sense to have an option to highlight every defined alias as green regardless the validity of its value.