Modularize Editor#186
Merged
Merged
Conversation
Phase 3a
foxnne
force-pushed
the
push-nvyuxknzqxmr
branch
13 times, most recently
from
July 6, 2026 19:30
6cba832 to
68cee4d
Compare
foxnne
force-pushed
the
push-nvyuxknzqxmr
branch
2 times, most recently
from
July 8, 2026 18:33
b5cfae1 to
92c3ae3
Compare
foxnne
force-pushed
the
push-nvyuxknzqxmr
branch
5 times, most recently
from
July 15, 2026 15:54
f14e489 to
6a99207
Compare
Allow ABI-version mismatches to reject loading plugin Handle loading config area plugins excersize 3rd party plugin Update build files for sdk simplify creating plugin work on rough edges Remove pixel art specific vtable hooks make pixel art specific hooks commands instead finish removing pixel art specifics in EditorAPI begin refining sdk unify builtin and 3rd party plugins split root refine plugin structure across all fix web build fix tab bar on bottom panel make core.gpa not have to be set by plugin authors Fix sprites panel small visual fixes, refresh api refine build.zig's in plugins begin work towards plugin store chunks 1 + 2 begin chunk 3 chunk 4 chunk 5 chunk 6 chunk 7 separate pixi from fizzy entirely Phase b1 b1b begin store_text_sidebar plan Phase 0 Phase 1-2 Phase 3-4 sdk: key ABI fingerprint lock by (arch, os) The comptime self-check in src/sdk/version.zig compared every native target's live structural fingerprint against a single hardcoded recorded_abi_fingerprint. The fingerprint hashes @offsetOf/@Alignof of the plugin-boundary types, which follows each target's C ABI, so aarch64-macos, x86_64-linux, and x86_64-windows legitimately produce different (but each internally valid) fingerprints for the same boundary. The check only exempted wasm32, so every non-aarch64-macos native build failed at compile time (surfaced as CI failures building the pixi plugin on linux/windows). Replace the single constant with a small per-(arch, os) table, recorded_abi_fingerprints, and look up the entry matching the target being built. Also corrects the aarch64-macos entry itself (0x1bb54eb7506cbd78 -> 0x9f75e41ec2f5c17f): it was already stale even for that one target on the current toolchain resolution, independent of the arch issue above -- caught because plugin_sdk=true only registers modules and never actually compiles them, so it had never been exercised by a real build. Verified via genuinely compiling pixi (a real third-party plugin, not the plugin_sdk export path) for aarch64-macos, x86_64-linux-gnu, and x86_64-windows-gnu, all clean. update fingerprint scheme update dvui refine store design plugin store work phase 5 sqlite update docs Cleanup storefront/fix panel text editor fixes update text editing begin implementing language plugins add plugin icons get ICON.png from plugin repo Add new file selection dialog Fix homepage Remove example, add Image Fix bottom panel and docs per plugin Make bottom panel close when no plugin renders to it sdk: add LanguageSupport hover/gotoDefinition hooks + workbench revealPosition Adds the SDK plumbing for Ctrl/Cmd+click goto-definition and always-on hover tooltips in the text editor, ahead of a real LSP-backed provider: - LanguageSupport.VTable.hover/gotoDefinition + HoverResult/DefinitionLocation - Host.hoverFor/gotoDefinitionFor lookups - Plugin.VTable.revealPosition (external plugins moving the caret in a document they don't own) + text plugin's pending_cursor-based impl - workbench.Api.revealPosition (open-if-needed + jump to a byte offset), with Workbench's pending_reveals polling for the not-yet-open case - TextEntryWidget: addTextHover per tree-sitter token + Ctrl/Cmd-click peek during processEvents, surfaced as hovered_span/definition_click - TextEditor: renders a FloatingTooltipWidget from hoverFor and calls revealPosition on a Ctrl/Cmd+click definition hit sdk: pass path explicitly to hover/gotoDefinition instead of a threadlocal The previewDocumentPath() threadlocal only ever worked for previewPane because text/markdown happen to be statically linked into the same binary and share one copy of it. A genuinely separate plugin dylib (e.g. the third-party zig language plugin) gets its own private compiled copy of every SDK source file, so the host's write into its copy of the threadlocal was invisible from inside the plugin's copy — hover/gotoDefinition silently never fired for any real dylib plugin. Pass path as an explicit parameter instead, same as bytes. Bumps sdk_version to 0.17.0. temp: add diagnostic logging for hover/gotoDefinition debugging text: keep large hover tooltips capped + scrollable, and interactive A hover tooltip with a lot of content (a long doc comment, a big type signature) would grow to cover the very token it's describing. Once the mouse ends up over the tooltip instead of the source token, hover detection loses the span and the tooltip disappears — which un-covers the token, which re-triggers hover, which reopens the tooltip directly under the mouse again. Constant flicker. Cap the tooltip at a fixed max size and put the content in a scrollArea so it scrolls instead of growing unbounded, and mark the FloatingTooltipWidget interactive so moving the mouse onto the tooltip itself (to scroll it) doesn't count as leaving hover and close it. text: style the hover tooltip to match the app's panel/dialog language Background matches the explorer/sidebar panel color (dvui.themeGet().color(.window, .fill), lighter than the tooltip's previous default), standard 8px corner radius, no border, and the same soft drop shadow used by the sidebar's own tooltip (Sidebar.zig:154-171) instead of a hard-edged box. add markdown service Add output log attempt to add autocomplete, broken refine autocomplete Refine completion design update dvui format on save Add info for highlighted completion suggestions update dvui core: finish ReorderWidget dvui corner_radius -> corners migration BoxShadow/Options corner styling moved from a flat Rect to CornerRect (tl/tr/br/bl Corner structs); ReorderWidget's finalSlot() and drag target fill were left half-migrated (called the new cornersGet() accessor but still assigned into the old corner_radius field name). correctly handle menu items, fix formatting on windows performance pass on text editing more accurate cache boundaries Fix editor performance on large zig files turn off diagnostic logs, remove unnecessary code update dvui move generic lsp client to core
foxnne
force-pushed
the
push-nvyuxknzqxmr
branch
from
July 15, 2026 16:29
6a99207 to
dac1525
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR is a large work in progress to discern information about the future of modularizing the editor.
This is the largest change to fizzy since rewriting in DVUI.
As of now, the proof of concept already works, with pending edits to DVUI to add a proxy backend, allowing us to compile individual libraries (plugins) which can be runtime loadable.
Currently, the app is now split into the following:
The editor itself is now often referred to as a shell, as it just reads plugins and renders their contributions to the correct regions.
- Handles rendering tabs and splits
- Basically all the functionality of fizzy originally, but contained to a plugin
- Support image loading and editing, adding supported docs to tabs/splits
- Basic text editing and syntax highlighting
The strategy here is to essentially statically link ALL builtin plugins for the web build. For the native build, we vendor a
pluginsfolder containing the dylibs the editor will read at runtime. We also look for plugins at the config location, so hopefully we can support 3rd party plugins sooner rather than later.Goals