support no space between spoken form and parens?

[pokey]

Talon supports hello(world): bar to map a spoken form equivalent to hello world: bar. Do we want to support this?

[wenkokke]

No, because that would clash with the special syntax key(...): and such, and would make parsing a mess.

[pokey]

I don't think it actually clashes with that syntax, and it appears you have special cases for all the functions anyway, so I'm not sure I see a problem

Fwiw, note that on the converse, key (a): foo is treated by Talon as equivalent to key a: foo (ie it matches someone saying the literal phrase "key a"). Not arguing we want to support that either, but we are introducing inconsistencies with the Talon parser

[wenkokke]

Inconsistencies are unfortunately difficult to avoid because the Talon syntax is ambiguous.

[wenkokke]

In my experience, using higher precedence for key(..) as a key binding over a command makes the error correcting behavior of the tree sitter parser act up.

Therefore this is probably best solved with lookahead in the lexer.

[pokey]

Ok so just to make sure we're on the same page, how do you want to parse the following:

hello(world): bar
key (a): bar

And does today's parsing of this program match your desired parsing? If the answer to that last question is "yes", then we can close this issue, but just wanted to make it all explicit

To be clear, Talon parses it as equivalent to the following:

hello world: bar
key a: bar

If we do parse them the same way Talon does, I'd argue the autoformatter should transform them to the second form above, but that's obv out of scope for this repo

[wenkokke]

I agree with these parsings. The cases I'm unsure about are:

key(not-a-valid-key-name): bar

Do you know what Talon parses these as?

[AndreasArvidsson]

Pretty sure the parser doesn't care about valid key names. The content inside the parentheses is just a string. That would probably generate a unknown key error when Talon tries to utilize the key value.

[wenkokke]

Closing in favour of meta issue #33