You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@AndreasArvidsson pointed this out during the Cursorless session today, but clip.capture() has a default timeout of 500ms. This timeout is hit whenever the selection is empty.
This means that commands like "google that" are normally fast when used normally (with a selection), but if you don't have a selection (such as if they are triggered accidentally), you have to wait for this timeout. 500ms feels relatively high.
We theorized that this is to handle sluggish apps or sluggish computers, so this might be a reasonable default to keep, but we should make it a setting so that power users can lower the timeout (under the assumption that they would notice if they have an application that needs a higher timeout), and thus have a better experience.
Here's an example of setting 100ms, although we would obviously use a setting:
@ctx.action_class("edit")
class EditActions:
def selected_text() -> str:
with clip.capture(timeout=0.1) as s:
actions.edit.copy()
try:
return s.text()
except clip.NoChange:
return ""
The text was updated successfully, but these errors were encountered:
The default time out for `clip.capture()` is 0.5s. You run into this
every time you call `selected_text()` on an empty selection. I've been
running with 0.1 for over a year with no problems. That might be a bit
to aggressive for community, but 0.25 shouldn't be any problems. Just in
case I added a setting so people with slower (or faster) machines can
change this.
Fixestalonhub#1210
@AndreasArvidsson pointed this out during the Cursorless session today, but
clip.capture()
has a default timeout of 500ms. This timeout is hit whenever the selection is empty.This means that commands like "google that" are normally fast when used normally (with a selection), but if you don't have a selection (such as if they are triggered accidentally), you have to wait for this timeout. 500ms feels relatively high.
We theorized that this is to handle sluggish apps or sluggish computers, so this might be a reasonable default to keep, but we should make it a setting so that power users can lower the timeout (under the assumption that they would notice if they have an application that needs a higher timeout), and thus have a better experience.
Here's an example of setting 100ms, although we would obviously use a setting:
The text was updated successfully, but these errors were encountered: