# TidalCycles editor landscape 2026 — web research report

*Produced 2026-07-18 by a Claude (Sonnet) web-research agent; sources cited inline, fetched
July 2026 except where issue/forum dates note otherwise. Companion to
`2026-07-18-pulsar-lag-investigation.md`.*

---

## (a) TL;DR verdict

**Pulsar is still the community's documented default and is actively maintained, but it is not a fast editor, and the two symptoms described (typing/cursor latency, multi-second stalls on error-stack rendering, low overall CPU) match documented, still-open architectural weak points rather than a config typo.** The tidalcycles org is *still investing in* the Pulsar package as recently as August 2025 (new issues, active maintainer `thgrund`), so "actively maintained" ≠ "fast" here — the maintainer's own issue tracker treats the exact symptom class (highlighting/rendering perf) as an open, multi-PR body of work, not a solved problem. Meanwhile the Vim/Neovim/Emacs plugin path is thin-and-terminal-based (no Electron rendering layer at all) and is what performance-conscious livecoders in the forum gravitate to, though not framed there as an explicit "Pulsar is too slow" migration — it's framed as "predictable, doesn't change." Building a fully custom IDE has no known prior art in this specific niche; the community's actual "purpose-built" answer to slow desktop editors has instead been to go *browser-native* (Strudel/Estuary/Flok), which is a different animal (JS port, not GHC/Tidal-Haskell).

Also worth flagging up front: the whole ecosystem rebranded in 2025 — `tidalcycles/Tidal` was archived on GitHub June 13 2025 and development moved to Codeberg under a new "Uzu" umbrella (`codeberg.org/uzu/tidal`, forum moved `club.tidalcycles.org` → `uzu.lurk.org`) covering Tidal + Strudel + other "uzulangs." ([Site rename announcement](https://uzu.lurk.org/t/site-rename-apologies-for-spurious-emails/6085), [uzu/tidal on Codeberg](https://codeberg.org/uzu/tidal)) Anything you search for going forward should account for this — old tidalcycles.org/GitHub links now often 301 to Uzu.

## (b) Concrete known perf issues matching the symptoms

**1. Event-highlighting/decoration rendering perf — open, unresolved, exactly this symptom shape.**
`tidalcycles/pulsar-tidalcycles` issue [#229 "Event Highlighting: Optimize performance"](https://github.com/tidalcycles/pulsar-tidalcycles/issues/229), opened 2025-08-14 by maintainer `thgrund`, explicitly says it exists "mainly to stabilize the editing of big files" and lists planned fixes still pending: honoring OSC bundle timestamps to avoid backlog, clearing state on `hush`, **moving calculation to a web worker** (i.e., today it runs synchronously on the main/render thread), and avoiding duplicate token/marker churn on line rewrite. Companion issues: [#228](https://github.com/tidalcycles/pulsar-tidalcycles/issues/228) (CSS override via OSC) and [#227](https://github.com/tidalcycles/pulsar-tidalcycles/issues/227) (custom CSS gets clobbered on restart) — same subsystem, all opened the same week, all still open.

**2. Root architectural cause — Atom's (inherited by Pulsar) marker/decoration system doesn't scale.**
Upstream `atom/atom` issues (pre-Pulsar-fork, but the code Pulsar runs): [#6692 "Find remaining performance bottlenecks for large files"](https://github.com/atom/atom/issues/6692) documents ~2900ms for creating/subscribing to thousands of decorations; [#9208 "Proposal: Marker layers"](https://github.com/atom/atom/issues/9208) proposes batching to avoid per-marker overhead; [#14592 "Bad Overlay Decoration performance on 1.19"](https://github.com/atom/atom/issues/14592) shows decoration regressions after a TextEditor rendering rewrite. This is the best mechanistic explanation available: rendering per-event highlight decorations, or re-tokenizing/re-decorating a big freshly-appended block of text (a GHC error stack dumped into the eval console counts as exactly that), is synchronous main-thread JS work in Atom/Pulsar's architecture — it blocks the renderer while leaving *aggregate* CPU (across all cores) looking low, because it's single-threaded blocking, not multi-core saturation.

**3. Electron main-process/renderer blocking is a known Electron-wide gotcha that produces "stalls with low CPU."**
`electron/electron` issues [#3363](https://github.com/electron/electron/issues/3363), [#5775](https://github.com/electron/electron/issues/5775), [#12098](https://github.com/electron/electron/issues/12098) and the write-up ["The Horror of Blocking Electron's Main Process"](https://medium.com/actualbudget/the-horror-of-blocking-electrons-main-process-351bf11a763c) all describe the same shape: a synchronous IPC call or heavy main-thread JS work freezes the UI while the OS scheduler shows the process mostly idle/waiting. This generalizes the "GHC error stack renders → multi-second stall, CPU stays low" report even without a Pulsar-specific issue naming it directly — no GitHub issue names "large GHC error output in console" verbatim; the closest documented precedent is the 2017-era, since-closed [#19 "multiline eval at end of buffer causes Atom to hang"](https://github.com/tidalcycles/pulsar-tidalcycles/issues/19), showing this class of eval-triggered hang has existed since the plugin's early days.

**4. Autocomplete is a separately-documented, already-solved typing-latency cause** (distinct from the error-stall symptom, but likely compounding it): the [official Pulsar setup docs](https://tidalcycles.org/docs/getting-started/editor/Pulsar/) and a confirmed forum fix ([Pulsar being slow](https://uzu.lurk.org/t/pulsar-being-slow/4566), Feb 2023 — user `Liimxa` confirms "changing the delay before suggestions are shown sorted it") both point to `autocomplete-plus`'s default suggestion-delay as a common typing-lag source, fixable by raising "Delay Before Suggestions are Shown" to 100–1000ms or disabling the package. Cheap, orthogonal, do it regardless.

**5. Electron-on-Wayland GPU fallback is real and separately documented**, though no Pulsar-specific report was found. `electron/electron` [#36633 "Zero GPU Acceleration on Wayland"](https://github.com/electron/electron/issues/36633) and [#45862 "Electron 34 apps fail to use GPU with Wayland backend on Linux 6.12+"](https://github.com/electron/electron/issues/45862) describe Chromium/Electron silently falling back to SwiftShader (CPU-based software Vulkan) under native Wayland, which would show up as a compositor/renderer-side cost (animated GIF background repaints, scrolling, decoration redraws) without necessarily spiking the "CPU%" figure people usually glance at (varies by how it's measured — single-core-pegged vs whole-system). The Hyprland/EndeavourOS thread on `--ozone-platform-hint`/`--disable-gpu` ([forum.endeavouros.com](https://forum.endeavouros.com/t/hyprland-vscode-always-starts-with-editing-ozone-platform-hint-wayland-and-disable-gpu/54345)) shows these flags are commonly auto-injected by distro dotfiles and can be silently misapplied (treated as file arguments instead of flags), which is worth checking in a Pulsar launch wrapper/`.desktop` file if one exists. *(Local check 2026-07-18: our Pulsar GPU process holds `/dev/dri` fds — hardware accel confirmed active, so this failure mode is not currently in play.)*

**6. KWin/Plasma 6 compositor is being actively tuned but not Electron-specific.** Plasma 6.1 added dynamic triple buffering and explicit sync (reduces missed-frame stutter generally); further KWin Wayland latency patches landed June 2026. No Electron-specific KWin interaction bug was found beyond generic "stuttering with Electron apps on Plasma 6 Wayland" chatter — thin evidence here, flagged rather than padded.

## (c) Ranked remediation options (cheap → drastic)

1. **Raise/disable `autocomplete-plus` suggestion delay** (100–1000ms, or disable the package) — documented, forum-confirmed fix for typing lag specifically. [uzu.lurk.org thread](https://uzu.lurk.org/t/pulsar-being-slow/4566)
2. **Disable `editor-background` (or swap the animated GIF for a static image) as a diagnostic** — animated backgrounds force continuous repaint of the whole window; if SwiftShader software rendering is active (see #5), this compounds every other stall. Test with it off before touching anything else.
3. **Verify GPU acceleration is actually active**, not silently on SwiftShader: check `pulsar://gpu` equivalent (Electron apps expose `chrome://gpu`-style info) or launch from a terminal and watch for Ozone/Wayland warnings; try forcing `--ozone-platform-hint=auto` (not hardcoded `wayland`) and confirm no stray `--disable-gpu` is being injected by a wrapper/launcher script.
4. **Cap or truncate eval-console output** — if the tidalcycles package or a console-view package has any "max lines"/"scrollback" setting, use it; this directly targets the marker/decoration-scaling root cause (#6692, #14592) that a long GHC stack trace triggers.
5. **Track/subscribe to `pulsar-tidalcycles` issue #229** — the maintainer is actively working the exact bug class (worker-thread offload for highlighting) as of Aug 2025; a future release may fix this without you doing anything. Worth commenting with the reproduction (large GHC error → stall) since it's not explicitly logged there yet.
6. **Try disabling event-highlighting entirely** (if BootTidal.hs's `cFrameTimespan`/highlight OSC target can be turned off) to isolate whether it's the highlighter or the console renderer causing stalls — the docs note animation fps should be ≤ ~20–30fps and tied to `cFrameTimespan`; a mismatch here is also a plausible independent stutter source. [Pulsar TidalCycles docs](https://tidalcycles.org/docs/getting-started/editor/Pulsar/)
7. **Migrate to vim-tidal or tidal.nvim (Neovim) + tmux**, keeping ghci/tidal-listener output in a terminal pane instead of an Electron webview. This is the documented "recommended plugin" path ([tidalcycles.org Vim docs](https://tidalcycles.org/docs/getting-started/editor/Vim/), [tidalcycles/vim-tidal](https://github.com/tidalcycles/vim-tidal)) and structurally sidesteps every issue above (no Electron, no DOM markers, terminal scrollback handles large error dumps natively). Cost: you lose Pulsar's `editor-background`/custom HUD integration entirely unless rebuilt as terminal statusline/tmux-status equivalents.
8. **Full custom/forked IDE** — last resort; see (d), no prior art found to build on, meaning you'd be re-solving Atom's decoration-scaling problem yourself rather than inheriting a fix.

## (d) Prior art on custom/forked livecoding IDEs

- **No evidence found of anyone forking Pulsar/Atom into a trimmed, livecoding-dedicated build.** Targeted searches for "minimal build," "performance mode," disabling minimap/tree-sitter for livecoding, or a custom Electron trim turned up nothing — either it doesn't exist publicly or isn't indexed. Treat this as a real gap, not a "just didn't look hard enough."
- **The community's actual "purpose-built editor" answer has been to go browser-native rather than trim a desktop IDE**: [Strudel](https://strudel.cc/) (JS port of Tidal's pattern engine, runs in-browser, no GHC/ghci involved at all so this entire class of stall structurally can't occur), [Estuary](https://tidalcycles.org/docs/resource/Friends_and_relations/) (browser-hosted Tidal-like parser + other languages), and [Flok](https://github.com/munshkr/flok) (P2P collaborative browser editor supporting Tidal, Strudel, SuperCollider, FoxDot, Sardine, Mercury). These are ground-up new implementations, not IDE forks — worth knowing as the template for "a browser tab as the performance surface" instead of an Electron app.
- **The lightweight-editor-plugin pattern (vim-tidal/tidal.nvim/tidal.el) is the closer analogue**, just inverted: instead of forking a heavy IDE and stripping it down, the community built a thin plugin on top of an already-minimal, mature terminal editor. Multiple independent Neovim ports exist (`grddavies/tidal.nvim`, `robbielyman/tidal.nvim`), suggesting this is where people who cared enough to build custom tooling actually put their effort — thin integration layers, not IDE forks.
- **tidal.el (Emacs) is confirmed actively maintained** (2025 copyright, moved to Codeberg with the rest of the ecosystem) — [emacsmirror/tidal](https://github.com/emacsmirror/tidal/blob/master/tidal.el), [tidalcycles.org Emacs docs](https://tidalcycles.org/docs/getting-started/editor/Emacs/).
- **VS Code extension was recently overhauled** (test coverage added, scope trimmed, automated releases) with the stated goal of reaching parity with the Pulsar plugin — implies it was behind, but is a live target for a GPU-accelerated-but-more-mature-than-Pulsar Electron option; no explicit performance benchmarking found. ([tidalcycles/vscode-tidalcycles](https://github.com/tidalcycles/vscode-tidalcycles))
- **No Zed support found** — absence of evidence, not evidence of absence; nothing indexed either way.
- System-level "protect the editor UI from real-time audio priority" is **thin territory**: Arch/Linux pro-audio guides ([ArchProAudio](https://github.com/chmaha/ArchProAudio), [Arch wiki Professional audio](https://wiki.archlinux.org/title/Professional_audio), [wiki.linuxaudio.org](https://wiki.linuxaudio.org/wiki/system_configuration)) cover JACK/PipeWire `rtprio`, `rtirq` IRQ-thread priority, realtime kernels, and killing unneeded daemons — all aimed at protecting the *audio* thread from xruns. No source explicitly addresses the inverse (keeping the editor UI thread responsive *despite* SuperCollider holding elevated realtime priority) — an under-documented niche with no external prior art to lean on.
