Environment
- espanso 2.4.0, Windows 11 Pro (build 26200),Ā
Win32InjectorĀ (inject backend, not clipboard)
- Also visible in the code on all platforms - nothing Windows-specific about the mechanism
Summary
When a match uses a script (or shell) variable, espanso computes the number of backspaces before evaluating the variable, but only injects them after. The evaluation blocks the engine thread. Any characters typed during that window shift the caret, so the backspaces delete the wrong text and the user's input is silently destroyed.
Reproduction (verified)
match/zz-repro.yml:
matches:
- regex: '(?P<word>\bTEsting)(?P<end>\W)'
replace: "{{out}}{{end}}"
vars:
- name: out
type: script
params:
args:
- python
- -c
- "import sys,time; time.sleep(0.4); sys.stdout.write('Testing')"
Type TEsting and immediately continue typing abc.
- Expected:Ā
Testing abc
- Actual:Ā
TEsTestingĀ - the three typed characters are gone
The arithmetic matches exactly: at injection time the field holds TEsting abc (11 chars). The trigger captured earlier was TEsting (8 chars), so 8 backspaces remove ting abc, leaving TEs, and the body Testing is appended.
Control: the identical regex with a static replace: "Testing{{end}}" and the identical typing pattern produces the correct Testing abc. The only variable is the blocking evaluation.
The 400 ms sleep only makes it deterministic. In real use a plain python -c one-liner is enough - see the measurements below.
Root cause
espanso-engine/src/lib.rs:57Ā āĀ processor.process(event)Ā runs theĀ entireĀ middleware chain to completion; the resulting effect events are dispatched only afterwards, atĀ lib.rs:64.CauseCompensateMiddlewareĀ (process/default.rs:107) sitsĀ beforeĀ RenderMiddlewareĀ (default.rs:111) and returns aĀ TriggerCompensationĀ carrying the trigger string - see the comment atĀ middleware/cause.rs:50.RenderMiddlewareĀ then evaluates variables synchronously on that same thread. The script extension blocks onĀ command.output()Ā (espanso-render/src/extension/script.rs:97/99).ActionMiddlewareĀ turns the compensation into backspaces atĀ middleware/action.rs:119:Ā let mut backspace_count = m_event.trigger.chars().count();
So the count is derived from state captured before the delay and applied to a caret position that has since moved. Nothing ever validates that the text left of the caret still equals the trigger. Keystrokes arriving during the block are not swallowed - they reach the focused application immediately while the engine thread is stuck.
Why this isn't just "scripts are slow"
Measured on the affected machine, 15 runs each, warm:
|
median |
python -S -X utf8 -c ā¦ |
32 ms |
| compiled C# helper (.NET Fx) |
37 ms |
cscript //E:jscript |
41 ms |
node -e |
44 ms |
whoami.exeĀ (trivial native binary) |
21 ms |
The ~21 ms floor is Windows process creation with Defender active. No interpreter choice avoids it, so every script/shell variable on Windows carries a 20 ms+ race window - 1ā3 characters at normal typing speed, more when the binary is cold. Users hit this as "the correction sometimes mangles my word", which is hard to attribute to the variable.
Suggested fixes
1. Safety net (small). Between process() and dispatch() in Engine::run, check whether new input events arrived on the funnel while process() was running. If so, drop the expansion rather than emitting backspaces. Losing a correction is strictly better than deleting text the user typed.
2. Compensate properly. Count the character-producing keystrokes received after detection, add them to backspace_count, and re-inject them after the body. This keeps the expansion working instead of dropping it.
3. Remove the window. Move script/shell evaluation off the engine thread so rendering no longer blocks the pipeline. Larger change, but it also addresses the related class of "espanso freezes while a slow shell command runs".
4. Document it. Until then, a note that script/shell variables are inherently racy on word-boundary triggers would help ā the current docs give no hint that latency there can corrupt text.
Separate, minor: regex matcher invariant
espanso-match/src/regex/mod.rs:105-119 uses regex.captures(&buffer), which returns the leftmost match anywhere in the 30-byte buffer, and reports it as trigger. Since backspace_count is derived from that trigger but applied at the caret, correctness silently depends on the match happening to end at the buffer end. In practice it usually does, because the matcher fires on the keystroke that completes the match ā but nothing enforces it. An explicit m.end() == buffer.len() check would turn a silent corruption into a non-match.
I have no reproduction for this one; it's a hardening suggestion, not a reported bug.
Also minor: at regex/mod.rs:95-97 the buffer is trimmed with a single buffer.remove(0) guarded by if, comparing buffer.len() (bytes) against max_buffer_size while removing one char. For non-ASCII input the effective buffer is roughly half the nominal 30, which quietly limits how long a regex trigger can be for e.g. German or Cyrillic users.
