kmdr
@kmdrfx • 7,413 subscribers
opentui/opencode @anomalyco Staff Software Chef, Father, husband
Shorts
Videos
This is how Dax joins all important strategic meetings. With CEO POV.
kmdr116,633 просмотров • 16 дней назад
New podcast just leaked! Featuring your favorite talking heads. Disclaimer: uhh... uhm...
kmdr131,266 просмотров • 2 месяцев назад
"Please fix Markdown tables!" Okay: text-only, wrapping, columnar selection, proper border conjunctions, fill full width, in opencode beta now. "What took so long?" Here's a writeup: OpenTUI uses yoga layout and has elements called Renderables. Boxes with borders, plain text, code with tree-sitter backed highlighting and other primitives. Organised in a tree structure resembling somewhat of a DOM. Approaching a table naively, given the primitives are there, one would think to just stack box and text elements the right way in a flex-box layout to visually represent a table. Boxes support borders. Problem solved. This is what an LLM would one-shot in a working state, given OpenTUI's API surface. Ignoring the fact that just using box local borders don't handle border conjunctions properly. Benchmarking something like that quickly shows that instantiating an average table takes >70ms and incremental updates become expensive. Hugely due to yoga-layout via wasm having a painful price on yoga API calls. The whole ordeal becomes memory hungry, because a Text element handles more than just plain text. A simple 4x6 table needs a Box and Text per cell, ending up with 48 heavy nodes that yoga must lay out. "But that's just OpenTUI being slow" - you might say. Yes, but no. Yoga should be integrated in the zig native binary core of OpenTUI. It is on the roadmap to do so, which will speed up render passes by 2-5x. Yoga-layout has an open PR to support CSS Grids, which would greatly ease building something like a table. We will use that for fully laid out tables when it gets there. Below the typescript core level Renderables, there are lower level primitives like TextBuffers and TextBufferViews, bound via FFI and completely handled in Zig. I was stuck expecting a table primitive to handle a full layout like a table in the browser does. For Markdown all we need is a text-only table. So we had to come up with a better idea, something that is feasible now. A table layout is pretty straight forward. No need to have yoga deal with that. Using TextBufferViews for cells directly gives lower level control and eliminates some overhead that Boxes and Text renderables have. A simple native method to draw a grid with proper conjunctions is a nice library method. It will surely be used for other cases, so that's what we added. Using this simplified approach we were able to bring down initial instantiation to <1ms, more than 70x improvement. With a far smaller memory footprint. Given all the low level primitives are known and implementing a text-only table like this is possible, Codex was of great help to carve out the PoC, setup the benchmarks and tests. That's only a fraction of what was needed though. The table needs options to span the full available width, render different border styles, show/hide borders, padding, selection etc. So many iterations later OpenTUI now has a text-only, performant and relatively cheap TextTable that we can leverage to render Markdown tables in a streaming/incremental manner. Efficiently and properly.
kmdr208,295 просмотров • 6 месяцев назад
OpenTUI Keymap is a host agnostic key/cmd engine for DOM like apps. It allows extreme customisation of a generic core, from key stroke syntax parsing to to command resolution and dispatch behaviour. It composes layers of bindings and commands into a single adaptive dispatch model. Demo link in the replies. There are many such systems, most of which stop at the key binding part. Apps often are expected to implement their own command layer on top of these. This disconnects the bindings from the actual command registry. Looking for a proper solution usable in OpenCode I couldn't find anything that fulfilled the need of being extremely extensible to allow plugins to fully control key mapping and command behaviour. I wanted it to always be able to know exactly which keys and commands are reachable at any point in time, no matter from where and how the mappings are manipulated. The main driver was enabling a which-key like plugin and vim like bindings in a mostly declarative way. While any other plugin could extend the keymap even further with a custom config syntax for key strokes for example. So addons for it are mostly composable and it comes with a variety of addons providing common behaviour. It can also power other discovery features directly from live state. Help views, command palettes and graph/debug UIs can all ask the engine what is active, reachable, shadowed, pending, or dispatchable instead of rebuilding that knowledge separately. The core is intentionally very much generic: hosts adapt focus, hierarchy, input events, and lifecycle, while addons extend parsing, tokens, sequence patterns, command metadata, resolvers, interceptors, and event matching. The result is a keymap that plugins can compose with rather than work around. This could all be built directly into OpenCode and just be app specific. Working on OpenTUI though I want applications to have an out-of-the-box solution to build keyboard-first apps easily. Well, at least agents can. It is extremely over-engineered. And I love it. I hope some of you will too.
kmdr91,223 просмотров • 4 месяцев назад
We are re-imagining what OpenCode Desktop really is. Completely. From scratch.
kmdr114,656 просмотров • 5 месяцев назад
What's next for OpenTUI? Here's a technical write-up. Over the last few months OpenTUI gained a lot of stability improvements, new unnecessary but fun features like live audio streaming, and useful features like rendering to the scrollback buffer mixed with a live TUI, called footer mode. Overall the feature set enables building large and complex applications. React and Solid make it super simple and convenient. There is still so much to do though. Three big milestones we have set out to achieve are: - Moving most of the behavioural logic currently living in TypeScript down to the native Zig core - Node compatibility - Optimizing the hell out of primitives like text rendering The render tree mechanisms are currently only usable from TypeScript. Think of the DOM, but controllable like a scene graph. Elements in the render tree are called renderables. They can expose a render method to draw themselves. All renderables are derived from a BaseRenderable. Renderables and the render tree will become native primitives. Building blocks usable from any language bindings. Reducing the TypeScript bindings to a very thin layer, with all the behavioural logic living in the native binary. Moving this down is not just a matter of porting TypeScript classes to Zig. TypeScript currently owns the tree, dirty-state propagation, layout reads, culling, and render ordering. If it still has to walk every node and call into native code for each step, we keep most of the complexity and add FFI overhead. Whole passes and their state need to move together. We took a big step towards this recently by building yoga-layout into the native binary. It exposes part of the official yoga-layout TypeScript package via FFI. Only the API surface that is actually used by OpenTUI. Covered by the test suite of the original yoga-layout package. This already gave a median speedup of ~2.5x, and up to 30x for narrow scenarios. The yoga-layout integration is useful beyond the speedup. Built-in text and editor measurement can now happen entirely in native code during layout instead of calling back into JavaScript. I ran an experiment last month taking this even further, having GPT 5.6 port yoga-layout from C++ to Zig, which gave extremely good results. It would be a burden to maintain right now though, so that's off the table for now. I might come back to it. Simon Klee is working relentlessly on Node compatibility and already has a full Node version of OpenCode running. Node got FFI support in v26.4.0, thanks to help from the Node community, namely Matteo Collina and Paolo Insogna. Behaviour and interfaces seem similar between Node and Bun, but there are some major differences. To get the best performance out of the Node FFI implementation, its usage has to follow some rules. Node has three ways to call native functions: the generic C++/libffi path, the SharedBuffer path, and the V8 Fast API. The generic path converts every argument in Node's C++ layer and then calls the function through libffi. It is flexible, but also the slowest option for frequently called functions. The SharedBuffer path is a middle ground. JavaScript writes scalar values and BigInt pointers into a small per-function buffer, reducing some conversion work. The actual native call still goes through libffi though. Typed arrays used as pointers cannot be packed into this buffer and fall back to the generic path. The path we really want is the V8 Fast API. Node generates a small machine-code trampoline for the exact function signature, allowing optimized JavaScript to call the native function without going through the generic converter or libffi. This only applies to JavaScript-to-native calls. Callbacks from native code into JavaScript still use libffi closures. Getting onto this path is quite strict. A signature can have at most eight arguments and everything must fit into CPU registers. x86-64 Unix systems have room for six GP (general-purpose) and eight FP (floating-point) arguments. AArch64 has room for seven GP and eight FP arguments. Anything that spills onto the stack falls back to a slower path. These are Node fast-path restrictions, not general FFI restrictions. Bun also does not support passing structs by value through its current FFI API. OpenTUI uses bun-ffi-structs to pack ABI-aligned struct data into an ArrayBuffer and passes a pointer instead. Despite the name, the package also works with Node. Pointers need some care too. Typed arrays and ArrayBuffers normally have to be resolved into BigInt addresses first. Eligible functions with exactly one pointer argument get another Fast API entrypoint that can extract the address directly from the buffer. An eligible signature is still not enough. V8 has to optimize a direct call with a fixed number of consistently typed arguments. Wrappers that collect arguments and forward them using spread or Reflect.apply can hide that call shape and keep the function on a slower path. The practical rules are: keep hot signatures within register limits, use direct fixed-arity calls with stable argument types, reuse owned buffers safely, and batch small operations. Then measure the real call site, because eligibility only makes a function fast-capable. We have to design the ABI around these constraints where it makes sense and gives the expected performance improvement. The third big area is text rendering. Today a Text renderable accepts a string, StyledText, or a tree of TextNodes. Before rendering, the TextNode tree is walked and flattened into styled chunks. Those chunks are packed in TypeScript, sent through FFI, copied into a native TextBuffer, and stored in a rope. Styles are represented separately as highlights. A TextBufferView then wraps the rope into visual lines, which are drawn into the visible buffer. This works, but updates are much more expensive than they should be. setStyledText effectively throws away and rebuilds the rope, copies and reparses all text and recreates the style highlights. Changing one TextNode also walks and flattens the complete tree before going through this path again. Text and style segments should instead live directly in the rope and support incremental replacement. Memory ownership is split between retained JavaScript buffers, the native memory registry, rope arenas, wrapping caches, styled-text storage, and highlights. Different operations preserve or reset different parts of that state. This is hard to reason about and can retain memory for much longer than expected. Text storage needs clearer ownership, with fewer lifetimes split across JavaScript and native code. The public API reflects the same split. The t template literal is convenient, but creates another intermediate chunk representation that is mutable, not cached, and not merged. Text also maintains both StyledText content and a special TextNode tree, which do not compose properly. TextNode is only a style scope, not a normal layout primitive, so Text renderables cannot naturally compose inside each other. I think this should become one Text primitive backed directly by rope segments. The template literal API might disappear or become a very thin helper around those native segments. Editing has another temporary layer in TypeScript. Extmarks currently monkey-patch editing operations, scan and adjust all marks after changes, maintain their own undo state, and recreate native highlights. They should become native marks anchored directly in the rope. A proper mark tree, similar to Neovim's marktree, could update marks together with edits, undo, and redo, and provide the foundation for highlights and concealment. Text wrapping has also become too complex. Supporting CJK, emoji, combining characters, ZWJ sequences, tabs, and different terminal width rules currently mixes byte offsets, grapheme indexes, and display-cell columns across several custom algorithms. Dirty views rewrap the complete document. Measurement and drawing can repeat some of the same work. The wrapping implementation needs an overhaul, but the exact shape is still open. The goal is to make Unicode handling easier to maintain, avoid repeated full-document work, and clearly separate byte offsets, graphemes, and terminal display cells. None of this will happen as one big rewrite. We will replace pieces when we understand the problem well enough and when the result is clearly simpler, faster, or more useful. To achieve all of this we might break public interfaces. Thanks to OpenCode and a lot of good models, migration to a new version with breaking changes mostly is not an issue anymore. What do you want to see next for OpenTUI?
kmdr29,430 просмотров • 1 месяц назад
Playing with some post-processing effects in an OpenCode plugin. Turn up the volume! Song: Qwenloclyn - 60fps
kmdr72,175 просмотров • 4 месяцев назад
In the upcoming release of OpenCode you can test the built-in which-key plugin to see what keybinds are active at any time. Command palette (ctrl+p) > "Plugins" > select the "which-key" plugin > toggle. Then hit ctrl+alt+k to show. Config has keybinds if your terminal sucks.
kmdr56,937 просмотров • 3 месяцев назад
Exploring a which-key like plugin for OpenCode while working on integrating the new OpenTUI keymap as sole key/cmd handling engine. OpenTUI keymap is extremely extensible by plugins and will enable a proper vim plugin with motions. Will follow up with details on the keymap.
kmdr35,442 просмотров • 4 месяцев назад
OpenCode now let's you enable sound and desktop notifications for the TUI. Sounds are customisable. You can turn off sound or desktop notifications individually. Desktop notifications use OSC 9/99/777 sequences where available, might not work reliably in all terminals.
kmdr33,101 просмотров • 3 месяцев назад
Here it is! The trailer that nobody expected. ThePrimeagen and teej dv 🔭 Enjoy! 😁🤞
kmdr124,969 просмотров • 2 лет назад
Got flash banged by OpenCode recently? Yeah, that was me. Here's what happened: OpenCode/OpenTUI detects terminal theme mode (light or dark) by querying OSC 10/11 for the terminal’s foreground/background colors and deriving the mode from those values. OpenTUI also enables DEC Private Mode 2031 to receive theme-change notifications. When that mode is enabled, terminals can send CSI 997 when the system theme changes. OpenTUI treated the 997 payload as authoritative and let it override the OSC 10/11-derived result. That turned out to be wrong. In some terminals, the 997 payload is simply unreliable: it can report light while the queried terminal colors clearly indicate a dark theme. That’s what caused the flash bangs. The fix seemed straightforward: stop trusting the 997 payload as the actual theme mode and use it only as a trigger to re-query OSC 10/11, then derive the mode from the returned foreground/background colors. That works great. Except OpenTUI had also started using OSC 11 to set the terminal’s default background color, so the terminal gutter around the drawn TUI matched the app background instead of the terminal’s own default background. This was introduced recently in OpenTUI. That created a new problem: if you use OSC 11 to override the terminal background, then later query OSC 11, you are just reading back your own override instead of the terminal’s real theme background. No problem. Reset the terminal background with OSC 111, query OSC 10/11, derive the mode, then restore the renderer background again. Oh wait. Turns out Ghostty has a bug. Once this background reset/override path is used, later OSC 11 background reporting can get stuck and stop tracking system theme changes correctly. Even though theme-change notifications still fire and OSC 10 foreground updates continue. This would cause further issues where the OSC 10/11 derivation would be wrong again. So for now: no using OSC 11 to set the terminal background color just to fill the gutter. TL;DR: OpenTUI must treat CSI 997 only as a hint that the terminal theme may have changed and rely exclusively on OSC 10/11 color queries for actual theme mode detection, while avoiding terminal background mutation via OSC 11/111 because that breaks correctness in some terminals like Ghostty.
kmdr30,311 просмотров • 4 месяцев назад