To discuss: "over" and "then" are the same command

[maxbruening]

I believe "over" and "then" fulfill the same function: they allow users to effectively chain commands. This begs the question: should we drop one in favour of the other?

What this is about:
Currently, then: skip() simplifies chaining commands by making sure talon separates commands within the same utterance correctly. Similarly, "over" can often be used at the end of otherwise arbitrary utterances (e.g. say <user.text> [over]). Thus, it fulfills the same/a similar function of letting users chain commands.

[pokey]

Here are some thoughts

The two commands: "over" vs "then"

"over"

This command appears in two scenarios:

1. Paired with another command that has an anchor ($)

For example:

community/core/text/text.talon

Lines 1 to 7 in 93c9261

	#provide both anchored and unachored commands via 'over'
	phrase <user.text>$:
	user.add_phrase_to_history(text)
	insert(text)
	phrase <user.text> over:
	user.add_phrase_to_history(text)
	insert(text)

In this case, the default "phrase" command is back-anchored, so that you cannot chain after it. That's so that Talon will never try to interpret the last part of "phrase" as a Talon command. Eg "phrase we need air" will type out the literal phrase we need air rather than interpreting the last "air" as a command and typing out we needa (notice the trailing a)

If you want to chain, you can use the unanchored version, which requires you to end with "over", so you can say "phrase we need over air" if for whatever reason you really want to type a after inserting we need

2. As an optional final word of a command

For example:

community/tags/find_and_replace/find_and_replace.talon

Line 85 in 93c9261

select next <user.text> [over]: user.select_next_occurrence(text)

In this case, the command is not anchored, so you can chain it: "select next hello air" will select next instance of hello and then type a. However, you may want to select the next instance of the literal text hello air. In that case you can say "select next hello air over" to force Talon to parse the air as part of the search text

"then"

This command is used to force Talon to pick two smaller commands rather than the bigger command when there is ambiguity. Eg in Cursorless, if you say "take line air", by default Talon will interpret it as one command that selects the line containing the token with a hat over the a. However, if instead you wanted it to be two commands "take line", then "air", so that it would select the current line and then type a, you can say "take line then air"

Can we merge them?

There are implicitly two questions here

Can we remove one of these constructs?

Can we remove "over" because we now have "then"?

This would mean removing the unanchored version of the command, the one that ends with over. Let's revisit our example "phrase we need over air", which should type we need then press a. If we said "phrase we need then air", it would just type out we need then air, because there's no unanchored version, so it will never allow chaining

For our other example with the optional [over] at the end, let's assume we removed that [over]. Then we'd say "select next hello air then". This would not force Talon to parse hello air as the text to search for; it would just interpret it as "select next hello", followed by the commands "air" and "then". If instead we tried "select next hello then air", it would still have the same problem.

Can we remove "then" because we have "over"

Not unless we added an optional "then" to every single command that could have an ambiguous parse, which would balloon the grammar and be hard to do fully

Could we just switch them both to use the same spoken form?

Eg use "then" everywhere we use "over", or vice versa. Without loss of generality assume we change then: skip() to over: skip() (the reverse is conceptually identical)

I think we might be able to get away with it for the "phrase" example.

For the "select next <text> [over]" example, it might work, but would need to test it, as technically the final "over" could now be considered its own command, rather than forcing a parse on Talon. In practice, it might work, as Talon tends to prefer bigger commands, but Talon also prefers commands over free text, so I'm not sure which would win

One problem with merging them is that we want "over" to be slightly longer and harder for Talon to hear, as it's annoying for Talon to accidentally hear it because it can result in weird behaviour. On the other hand, we want "then" to be short, and doesn't matter much if Talon thinks it hears it, because it does nothing. That pushes at least slightly for them being different words

Takeaways

It's possible that we could just use "then" or "over" for all the use cases, but we would need to test it, and there are some caveats