Lumen

We render every glyph on the GPU in Lumen, and it flies for a normal session. But once the scrollback gets into the hundreds of thousands of lines, scrolling starts to stutter and frame time spikes hard. What we've tried Re-uploading the whole glyph atlas on resize (clearly wrong, fixed it) Virtualizing rows so we only build vertices for what's visible Double-buffering the vertex buffer to avoid GPU stalls The remaining jank seems to come from re-tessellating rows on every frame even when nothing changed. Here's roughly the hot path: for row in viewport.rows() { let mesh = tessellate(row); // <- runs every frame, ouch batch.push(mesh); } draw(batch); Is the move to cache tessellated rows and only invalidate dirty ones, or should I be doing something smarter with instancing? Curious how folks shipping editors/terminals handle this. Targeting a smooth 120fps on a 2019-era laptop.

Lumen is getting a plugin system. I want plugins to extend the terminal (commands, panels, themes) without being able to read arbitrary files or exfiltrate env vars. Considering: WASM sandbox with a capability-based API surface A separate process per plugin + IPC QuickJS/V8 isolates with no host bindings by default // plugins only get what we hand them const api = { registerCommand, readClipboard }; // no fs, no net runPlugin(code, api); For anyone who's shipped an extension ecosystem (editors, browsers): what's the realistic threat model, and where did you regret being too permissive early?

Reworked Lumen's command palette: fuzzy search, recent commands pinned to top, inline argument hints. Two reviewers say it's fast, two say it's cluttered. Tie-breaker, please. What's in it Fuzzy match across commands + recent files Right-aligned keybinding hints Inline preview of what the command will do Is the inline preview helpful or noise? And does showing recents-by-default beat a blank slate? Genuinely torn - screenshots attached.