Tracking ticket for dynamic lists, where a list or capture in the grammar gets resolved at action time, instead of being having to be provided ahead of time.
This would be necessary to perfectly implement functionality like "select and say" in input fields (which allows you to select or correct text in the current input buffer). Dragon's implementation lets you correct or select anything that exists in the field at the moment that you issue the command -- with static lists, we can only gather this information ahead of time, which can involve increasingly aggressive and performance risky methods (like input taps) if we want to do it perfectly, or less aggressive but risking missing words added by the keyboard.
But in general, this will also lead to much better outcomes, because we avoid having harvest data ahead of time, which could lead to freezes without invoking a command at all.
For example, today community indexes the contents of the current file manager directory by responding to title changes, but that means that if you're browsing a very slow folder (like a network share), it can freeze Talon as it tries to build the list, and the user won't know what's going on. If they don't have the log open, they may not even notice it until they try to issue a command later.
(And if getting the directory itself is slow for whatever reason -- as I've seen with iCloud Drive with AppleScript -- it could freeze the file manager itself, which is much worse, because the only symptom the user has to go by is "finder freezes when I have Talon running sometimes; quitting Talon fixes it")
With a dynamic list, the freezing could still happen, of course, but it would be easily attributable to the action, so the user could debug it more easily. And because we wouldn't be harvesting as much data ahead of time, it would greatly reduce the number of times these freezes happen (since if you weren't using a directory navigation command in that network folder, it would never try to enumerate it.)
Tracking ticket for dynamic lists, where a list or capture in the grammar gets resolved at action time, instead of being having to be provided ahead of time.
This would be necessary to perfectly implement functionality like "select and say" in input fields (which allows you to select or correct text in the current input buffer). Dragon's implementation lets you correct or select anything that exists in the field at the moment that you issue the command -- with static lists, we can only gather this information ahead of time, which can involve increasingly aggressive and performance risky methods (like input taps) if we want to do it perfectly, or less aggressive but risking missing words added by the keyboard.
But in general, this will also lead to much better outcomes, because we avoid having harvest data ahead of time, which could lead to freezes without invoking a command at all.
For example, today
community
indexes the contents of the current file manager directory by responding to title changes, but that means that if you're browsing a very slow folder (like a network share), it can freeze Talon as it tries to build the list, and the user won't know what's going on. If they don't have the log open, they may not even notice it until they try to issue a command later.(And if getting the directory itself is slow for whatever reason -- as I've seen with iCloud Drive with AppleScript -- it could freeze the file manager itself, which is much worse, because the only symptom the user has to go by is "finder freezes when I have Talon running sometimes; quitting Talon fixes it")
With a dynamic list, the freezing could still happen, of course, but it would be easily attributable to the action, so the user could debug it more easily. And because we wouldn't be harvesting as much data ahead of time, it would greatly reduce the number of times these freezes happen (since if you weren't using a directory navigation command in that network folder, it would never try to enumerate it.)