[ahelwer]

I've heard cursorless (https://github.com/cursorless-dev/cursorless-talon) is good but have never tried it. Syntax-aware voice navigation of code, powered by tree-sitter queries!

I also have a friend who is a gifted programmer who lost his ability to type about a decade ago; he has put together an open-source software stack to help: http://www.cs.columbia.edu/~dwk/

Of course this doesn't really answer your question. But it's a hard problem, and you're basically forced to become a power user to reliably interact with your PC.

[pokeyrule]

creator of Cursorless here. Happy to answer any questions

[jiehong]

Seriously cool project!

This reminds me of easy motion for vim or ace-jump for emacs.

Do you think it would be possible to have an on-demand contextual hat decoration?

Like you say “show hats words” and only words get decorated with hats and you pick one. It would allow you to maybe show hats only on square brackets or only on function arguments, etc. I find the number of hats with colors a little bit hard to distinguish; should they were contextual, they would require fewer or no color.

Do you map voice commands to keyboard shortcuts available in vs code, or directly via the apis? (Not sure if there is a difference in the end).

Now I wish for a cursor less plugin on the IntelliJ platform.

[pokeyrule]

Thanks jiehong!

The reason that the hats are always present is that the way to code faster by voice than be keyboard is to speak fluently, minimising pauses, the way we speak regular human languages. If we had to say a command and then wait for the hats to appear, that would break the chain.

Re mapping, we use something called the "Command server", which allows us to use file-based RPC to run commands in VSCode. That way it is easy to send more complex commands, which are required by Cursorless

IntelliJ support is definitely one of the most requested features; once I'm done rewriting some of the core engine I'll probably take a swing at that. Here's the issue that tracks extracting cursorless into a node.js server so that it can be used by other editors: https://github.com/pokey/cursorless-vscode/issues/435

[maxore44]

I am a cursorless user myself. Using dictation software for programming is actually relatively fast when you get used to it, but editing code (which is how most of us spend the majority of our time) can be pretty slow. Cursorless was a huge productivity booster for me. It got me to switch from Emacs to VS Code which is saying something.

[alexhwoods]

Same. Have to disagree though. I've been reintroducing a keyboard here and there, and whenever I have to do something in the VSCode editor, I get frustrated with the speed and end up going back to Cursorless.

I think it's a lot faster than keyboard / mouse, mostly because of how little moving of the cursor you have to do.

Could be I was slow to begin with, not super efficient with vim or emacs.

Also, "editing" is the fastest part for me, due to "bring" and "change". So little movement.

[jbellis]

What distinction are you trying to make between "programming" (fast) and "editing code" (slow) ?

[pokeyrule]

I think the distinction is "programming" refers to just dictating some code from scratch. "editing code" refers to changing code that is already written.

For the former ("programming"), there are many commands that can be used to rapidly output code. For example, a user can say "funky hello world" to get something like

function helloWorld() {

}

But if you're trying to edit code that already exists, it can be a challenge to do so without a mouse and keyboard, in part because you need to do a lot of navigation.

I personally believe Cursorless solves that problem better than a keyboard and mouse, but I have to imagine I'm a bit biased on that point :)

[maxore44]

Yes, exactly right. The vast majority of programming is editing code, and cursorless allows you to A) Navigate code quickly and B) do things using less navigation than you could with Keyboard/Mouse.