The embedded-expression rescan in eval_to_string tries every substring, so
any identifier the evaluator knows is also recognised in the middle of
ordinary text. Because `pi` needs no arguments it resolves anywhere it
appears, and names typed into property or command fields were rewritten:
`ASPIRATORE` came back as `AS3.141592653589793RATORE`.
Require a candidate whose first or last token is an identifier to start,
respectively end, on a word boundary. Leading and trailing numbers stay
unrestricted so mixed input such as `def10*10abc` still evaluates.
Fixes#809
The recursion-depth guard fixes the parser stack overflow, but user input
actually flows through eval_to_string (command line, viewport, dynamic
input — synchronous on the UI thread). Its embedded-expression fallback
re-tokenises every (start, end) window, so cost is ≈O(n³): a few-KB paste
of non-evaluable text or deeply nested parens froze the app for seconds to
minutes even though eval_number fast-returns None in microseconds
(measured: "x"×3200 → 16 s, 4 KB of parens → 51 s).
Cap the fallback scan at MAX_EVAL_SCAN_LEN (256) — whole-string numbers
and expressions of any length still evaluate via the fast paths; only the
mixed free-text scan is bounded, returning long input unchanged. Clarify
that MAX_RECURSION counts parser frames (256 ≈ 41 nested parens, not 256
levels). Add regression tests: the 41/42 nesting boundary, unary-chain and
function-arg-nesting rejection, and an eval_to_string over-cap promptness
test (50k junk + 100k nested parens return instantly).
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Hakan Seven