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.

[danielshahaf]

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.

Yes, it's syntactically valid. That hasn't been questioned. As to the reason, I don't see what it is.

I believe it would make sense to have an option to highlight every defined alias as green regardless the validity of its value.

You have already said so and been replied to.

[baldricni]

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.

so in the roadmap, zsh-syntax-highlighting will not deliver this feature at all, i.e. support alias correct-highlight include function definition?

[danielshahaf]

> 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. so in the roadmap, zsh-syntax-highlighting will not deliver this feature at all, i.e. support alias correct-highlight include function definition?

The whole reason this ticket remains open is in order to track changing the behaviour of this case. However, see above (#803 (comment)): the use-case given is the moral equivalent of `#define f() foo(); bar();` in C: it's syntactically valid but liable to DTWT in certain contexts. As such, it's not high priority for us. This may be an instance of "hard cases make bad law". If anyone has a use-case for `f(){}; f` that /doesn't/ have the aforementioned drawbacks, it would be useful to know that.