phillco
commented
1 year ago I've tested it, but since you mentioned it -- if you wouldn't mind having the repository cloned (even if you don't use the actions normally), I think it would help boost our test coverage and catch problems like this in the future.
(We have a bit of a gap since you don't use axkit, I use it but don't use the VS Code draft editor and/or have its accessibility enabled all the time; Nicholas uses VS Code but not the draft editor (?) or maybe just has accessibility enabled as well).
Since we recommend community + Cursorless + axkit on macOS in the community README, probably somebody should be using all three. Otherwise it's a bad experience for new users like Josh and some issues might be misdiagnosed as Cursorless issues (ie https://github.com/cursorless-dev/cursorless/issues/1517), whereas they would be much more easily caught by experienced hands.
(Although, accessibility on vs. off will always be an annoying variable.)
I can also just try to use the VS Code draft editor a bit more.
I think this action is the main risk point because it's the main place we override a built-in action, but in theory we wanted to have a whole suit of these. We're probably going to have to rethink that strategy or be a lot more cautious about turning things on by default; the risk of hard-to-debug bad behavior because of application implementation seems rather high at the moment.
nriley
pokey
Fixes https://github.com/phillco/talon-axkit/issues/59; see that issue for context. tldr: VS Code has started (when?) to report some partial accessibility information, which unfortunately only includes the selected text sometimes. Sometimes it says it is empty when it isn't.
In the future I could see us having a setting to adjust this behavior that could be turned on for fully native text fields that don't do what VS Code is doing, but in the interim, I think this is reasonable?
Also remove a fallback for <0.3 that's no longer needed.