pure

Would you be open to making the initial newline printed before the prompt optional? The new extension points you've added over the last few months have been fantastic, and this is only the local modification I currently have left. I'm currently making it optional with zstyle: A settable variable would work too, this just seemed simplest and least obtrusive. Figured I'd ask before opening a PR.

Just wondering if theres a way to set it so I can see when command take for instance 0.1 vs 0.4 sec

General information Pure version: master (async.zsh v1.8.6) ZSH version: 5.9 (arm64-apple-darwin) Terminal program & version: Ghostty (inside tmux 3.5a) Operating system: macOS 26.5.1 ZSH framework: none Problem description parses the zpty stream with zsh's subscript to locate the NUL delimiter: https://github.com/sindresorhus/pure/blob/main/async.zsh#L320 zsh implements by attempting the pattern at every position, and each attempt copies the remaining suffix onto the zsh heap ( → → ). That makes a single evaluation O(N²) in both CPU time and cumulative heap allocation, and zsh's arena heap is not returned to the OS until the enclosing expression finishes. The scan also re-runs for every ~1KB zpty chunk while a message's delimiter hasn't arrived yet (line 320, and again at line 337 after each extracted message). Consequences for a large job result (numbers measured on an M-series Mac, zsh 5.9): So a few hundred KB of job output is enough to pin the shell at 99% CPU for minutes-to-hours and balloon it to tens of GB. If the delimiter eventually arrives the shell recovers and the memory is released — which is why this has been so hard to catch in the act. Real-world incident Two idle pure-prompt shells in tmux (both cwd'd inside a git repo) pinned a core each and drove a 128 GB MacBook into swap exhaustion / the macOS "out of application memory" dialog. One shell reached 75 GB RSS, 508 GB VSZ, 16 h 43 m CPU time — 508 GB VSZ matches N²/2 for a ~1 MB buffer almost exactly. of both processes showed the identical stack: A third shell was observed live climbing from a 24 GB peak back down to 5 MB the moment the parse completed (: "Physical footprint: 5328K, peak: 24.0G"), with empty afterwards — confirming the payload was a legitimate, fully-framed message and all the memory was transient scan overhead. This is the root cause of #502 In #502 (open since 2019, closed unresolved), @ixil attached an ltrace of a stuck shell: That is exactly this scan: the decrementing over a ~480 KB buffer of git error output is the per-position suffix walk of . Large/slow git output (fetch errors, status in huge repos) streaming through the worker is the most common trigger. Minimal reproduction Fix computes the same position in linear time with a single allocation, including the "delimiter absent" case (it yields , so , which the existing control flow already handles — no other changes needed): and the same substitution at the second search site (currently line 337). I've verified callback-visible behaviour is byte-for-byte identical to the current code on framed streams (multiple messages, flags, double-NUL separators), and the 100 KB scan drops from ~4 s / ~5 GB to ~1 ms / no measurable allocation. The same code exists in mafredri/zsh-async (also v1.8.6), so the fix applies there too. Happy to open a PR here and/or upstream — let me know which you'd prefer.