Giter VIP home page Giter VIP logo

Comments (1)

pokey avatar pokey commented on July 28, 2024 2

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:

#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:

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

from community.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.