Increasing the pause length to be compatible with slower systems

[mostlyjason]

I noticed with Atom that any rule using the command palette would open the about webpage showing release notes, which is the first item in the list. When I increased the pause it had enough time to add and filter the text before hitting enter. I tried various increments like 10, 20, and finally 30 was the safest number that worked every time. I guess my computer is slower than yours? I hate to make everyone's rules slower but it seems like it's better if it works out of the box on most computers, especially for new users who don't know how to adjust these settings. If you can think of a better solution feel to suggest one. I could also just keep this in my fork if you prefer.

[chilimangoes]

I don't currently use Atom (too sluggish) but 0.3 seconds is definitely a noticeable delay. I think you're right that it might be better to default to a safe value, especially considering how slow Atom is. However it might be better to make it user configurable. I would recommend replacing the hard-coded Pause ("40") values with a variable, eg Pause (atom_palate_delay). Then you can read a user setting into the variable at the top of the atom.py file. You can search the source code for references to settings.SETTINGS to see how to read in configuration values, and you'll need to add a default setting value by modifying caster/lib/settings.py.

[synkarius]

Adding a setting to the settings file is the way to go, yeah. Default it to 10.

[ghost]

Adding a higher value helps but there's not really a "truly safe" setting within my experience creating Atom.py. It's one of three fundamental issues that can only be solved through the creation of a Atom plug-in that bridges communication between Caster and Atom.

1. Contextually Aware Commands. Certain command should be only available based on which Pane is active. For instance using the 'find' command or issuing commands in Treeview.
2. Eliminating shortcuts and calling functions directly within Atom. There's only so many keyboard shortcuts. In addition shortcuts becomes a problem when using third-party plug-ins as often they're not assigned shortcuts therefore one is forced to use the command palette.
3. The command palette is an unreliable method. The utilizing command palette was always something that was troublesome. I've used it over a variety of hardware like tablets, laptops, and desktops. There are too many variables between PC specs, microphone, and the differences between WSR and DNS. Additionally Atom speed has slowed when indexing available commands with recent releases compounding the issue you've described.

I've done quite a bit of research into the feasibility of creating a bridge plug-in and it is definitely possible. Although as a programmer it's beyond my skill and I got burned out trying. I had a full plate learning python utilizing voice to text. With the addition of learning JavaScript/coffee script to create an Atom plug-in it was too much. If anyone was were willing to attempt roughing out a Atom Castor bridge plug I definitely could contribute.

[synkarius]

@zone22 I completely agree with your points, and that IDE plugins would be far more powerful / stable than purely Dragonfly-based methods. (Extending Dragonfly's Context object to interact with some kind of RPC interface would be awesome.) But as you've discovered, creating them is nontrivial. (I haven't even created one for my preferred IDE, Eclipse. I'm just too busy.) The settings route is a partial solution which though imperfect, is good enough for some cases.

[mostlyjason]

Closing because I opened a new pull request to implement the suggestion of @chilimangoes and @synkarius. Btw I love the plugin idea I just don't know how to make one either!

[synkarius]

Incidentally, these change more than the "curse" command. They affect the direction key commands, ctrl/shift + direction keys, etc. See /lib/ccr/core/nav.py.

Anyway, if you don't like any of the specs for the commands, beyond just changing them in your local copy of Caster, there is an update-proof mechanism for changing specs or actions in a given command without modifying anything which is tracked by git.

You are able to create "filter functions" in the user/ folder (which git ignores). When Caster boots and when you speak the commands to switch programming languages (or otherwise modify the active command set), Caster looks to see if any of these filter functions are present, and if so, modifies the command set however you specify before reactivating it. See user/filters/examples/scen4.py for some examples. Let me know if you have any questions.

[mostlyjason]

Oops sorry you can ignore that change since I was intending to keep it on local. I accidentally submitted this one from the develop branch instead of creating a feature branch. On the plus side, I didn't know about filter functions and they sound useful, so I'll definitely check them out!

[synkarius]

They're a newer feature, not in the docs yet.