Syntax does not understand antiquotations inside paths

[lilyball]

Nix 2.4 introduced the ability to put antiquotations inside path literals (release notes):

Languages changes: the only new language feature is that you can now have antiquotations in paths, e.g. ./${foo} instead of ./. + foo.

The Nix syntax definition doesn't understand this. If I write /${foo} it marks the / as either invalid.illegal or as an operator depending on context. If I write foo/bar/${baz}/wat it highlights this just like it does foo/bar / ${baz} /wat.

[jnoortheen]

Thanks for reporting @lilyball . I'd be happy to accept a PR fixing this.

[wmertens]

It's been quite a while but it looks like I didn't make a separate thing for paths, instead mashing it into the operators:

vscode-nix-ide/syntaxes/nix.YAML-tmLanguage

Line 76 in 8e89986

match: (\bor\b|\.|==|!=|!|\<\=|\<|\>\=|\>|&&|\|\||-\>|//|\?|\+\+|-|\*|/(?=([^*]|$))|\+)

So the thing to do would be to make ./ start a path and allow interpolations inside it, a lot like the string pattern. Frankly I completely forgot how I developed and debugged it 😓

[lilyball]

@wmertens Paths aren't done as the operators, they're done as part of strings:

vscode-nix-ide/syntaxes/nix.YAML-tmLanguage

Lines 460 to 464 in 8e89986

	- begin: (~?[a-zA-Z0-9\.\_\-\+]*(\/[a-zA-Z0-9\.\_\-\+]+)+)
	beginCaptures: { "0": { name: string.unquoted.path.nix } }
	end: (?=([\])};,]|\b(else|then)\b))
	patterns:
	- include: "#expression-cont"

The way expressions are done in general is weird though, it looks like each expression is actually a capture group that either names the beginCaptures, or else does a lookahead and then includes a rule that starts with that lookahead, and either way it includes #expression-cont and only ends at various syntax or else/then? Which means if you have an expression like foo 1 2 bar "baz" 3 it's actually matching more like (foo (1 (2 (bar ("baz" (3)))))). This is very confusing.

In any case, my guess here is that a way to fix this would be to change string.unquoted.path.nix to include a nested pattern prior to #expression-cont. The nested pattern would include #interpolation and another match pattern which would match anything valid to continue a path. Or something like that, it might have to be a separate recursive rule in order to get string.unquoted.path.nix to apply to the whole thing, I'm not sure. It's been a very long time since I've done TM language grammar development.

[jnoortheen]

perhaps adding bits from this-better-nix-syntax project can work ?