Draft Window Inconsistently Loses Text On Submit

[cdrch]

When using draft submit to send text from the Draft Window back to another application, sometimes several characters are lost from the start. This is very inconsistent, sometimes dropping 0 characters, and other times dropping 4-5. Occasionally, it will entirely fail to copy over anything.

I tested this by repeatedly doing draft edit all (which worked fine) and then draft submit, which should have simply placed the words back in the original spot, but fails in one of the ways I described about half the time.

Additionally, I tried removing the Draft Editor to ensure the overlapping draft submit commands could not interfere, but this made no difference.

This was brought up in #1695 previously. It is also mentioned in talonvoice/talon#254 (comment), but I'm unclear whether Talon or Draft Window is at fault. However, it seems there is a simple fix that Community can introduce.

I believe the issue is that the Draft Window command begins sending text prior to the other application regaining full focus. The switching time is dependent on computer performance and application responsiveness, and thus seemingly random. This is supported by an app.notify(content) line at the end of draft submit showing the full context, meaning that user.draft_get_text() is not failing. It is also supported by a simple sleep(50ms) just before insert(content) in draft submit being enough to make the program work consistently. I am unsure if this is an ideal solution, however, as the time is likely to be very machine-dependent.

[FireChickenProductivity]

I recommend we add a sleep for this (which I did in my own setup) and define a setting for changing the sleep time.

[nriley]

@cdrch — we discussed this in the community backlog session. A few things:

1. As you mention, adding an arbitrary sleep is not ideal as it is machine dependent. One possible solution might be to use pasting rather than typing to insert. Can you try setting user.paste_to_insert_threshold to 0 either globally or in the apps where you are seeing the issue? We used to use paste for the draft window but there is a very old issue (from 2021) that indicated it didn't work consistently on the Mac. However, I just tested this on the Mac and it seems like it is working.

2. We also have a lot more sophisticated logic in closing the draft editor then we do with the draft window. This does involve a 300ms sleep before pasting into the app (the draft editor does not ever use insert but always uses paste). Putting this in for the draft window would at least be consistent.

3. As you mention, it is not ideal that we have two draft submit commands that can be active simultaneously. We should fix this, probably by declaring this as an action.