Proposal: integrate OmegaEdit with Apache Daffodil VS Code at the extension level

[scholarsmate]

Proposal

I propose that Apache Daffodil VS Code integrate OmegaEdit at the VS Code extension level instead of carrying a library-level/editor-UI integration inside apache/daffodil-vscode.

The short version:

• OmegaEdit should own the generic byte editor extension: opening data files, viewport management, byte navigation, editing, save/undo/redo, search/replace, transforms, checkpoints, change logs, profiling, and generic byte-range annotations.
• Apache Daffodil VS Code should own DFDL/debugger behavior: launch configuration, Daffodil debug session state, parser events, schema-aware mapping, diagnostics, breakpoints, infoset display/diff, and Daffodil terminology.
• Daffodil should consume OmegaEdit by declaring a VS Code extensionDependencies entry and activating the typed API exported by ctc-oss.omega-edit-data-editor.

This would replace the current model where Daffodil depends directly on @omega-edit/client and @omega-edit/server, owns src/dataEditor, bundles its own Svelte Data Editor UI, and manages the OmegaEdit server lifecycle itself.

Why change the boundary?

The current Daffodil integration works, but it couples three things that are easier to evolve separately:

1. A general-purpose byte editor.
2. The OmegaEdit server/client lifecycle.
3. Daffodil-specific parser/debugger behavior.

Moving the integration up to the VS Code extension boundary gives each project a clearer job.

OmegaEdit can ship and test its editor as a reusable extension. Daffodil can treat the editor as another VS Code capability, similar to how extensions commonly compose with language tools, debuggers, and custom editors. The Daffodil repo no longer needs to carry a forked editor UI or keep low-level OmegaEdit client/server wiring in sync with OmegaEdit releases.

What the OmegaEdit extension already provides

The OmegaEdit Data Editor extension currently provides a VS Code custom editor backed by OmegaEdit, with:

• hex and text panes with local byte selection
• command palette and Explorer open commands
• offset navigation and bytes-per-row controls
• text/hex search, large-result navigation, replace, and replace-all
• insert, delete, overwrite, clipboard, save, save-as, undo, and redo
• binary inspector values with endian-aware display/editing
• analysis/profile side pane with byte frequency and structure hints
• transform plugin discovery and application
• checkpoint, rollback, restore, and JSON change-log export/apply commands
• server health/status-bar integration
• a typed activation API for downstream parser/debugger integrations

Feature screenshots from the current OmegaEdit VS Code extension are being added to the extension README in #1482.

Editor overview

Search and replace with synchronized hex/text highlighting

External highlights for parser/debugger integrations

Transform plugins with inspectable content sources

Proposed Daffodil consumption model

Daffodil would declare the OmegaEdit extension dependency:

{
  "extensionDependencies": ["ctc-oss.omega-edit-data-editor"]
}

Then Daffodil would activate the extension and call the versioned API:

import type { OmegaEditExtensionApi } from 'omega-edit-data-editor'

const extension = vscode.extensions.getExtension<OmegaEditExtensionApi>(
  'ctc-oss.omega-edit-data-editor'
)

const omegaEdit = await extension?.activate()

if (omegaEdit?.version !== 3) {
  throw new Error('Unsupported OmegaEdit Data Editor API version')
}

await omegaEdit.open(document.uri, { offset: parserOffset })
await omegaEdit.setExternalHighlights({
  uri: document.uri,
  reveal: true,
  highlights: [
    {
      id: 'daffodil.parser.current',
      offset: parserOffset,
      length: parserLength,
      kind: 'current',
      label: 'Current parse point',
      source: 'Apache Daffodil',
    },
  ],
})

The important part is that Daffodil would interact with a VS Code extension API, not the OmegaEdit server/client internals or the editor webview implementation.

Mapping from the current Daffodil behavior

Current Daffodil behavior maps cleanly onto the extension-level API:

• openDataEditor on debug start opens the configured data file through omegaEdit.open(uri, { offset }).
• daffodil.data events carrying bytePos1b become zero-based byte highlights through omegaEdit.setExternalHighlights({ reveal: true, ... }).
• Debug-session termination clears Daffodil-owned annotations through omegaEdit.clearExternalHighlights(uri).
• Parse errors and leftover-data messages can remain in Daffodil's existing surfaces today, and could become inline byte annotations later if Daffodil can provide stable offsets/lengths.
• Infoset display and infoset diff remain Daffodil-owned and intentionally outside the editor boundary.
• Search, replace, save, undo, redo, profiling, viewport state, and server lifecycle move out of Daffodil and remain owned by OmegaEdit.

There is already an Apache-side proof of this direction in apache/daffodil-vscode#1726, which replaces the embedded editor path with extensionDependencies plus activation/API calls.

Benefits

• Smaller Daffodil extension surface: less webview/editor/server lifecycle code in the Apache repo.
• Clear ownership: OmegaEdit owns generic byte editing; Daffodil owns DFDL/debugger semantics.
• Reusable editor: the same OmegaEdit extension API can serve Daffodil, DFDL-adjacent tools, and other byte-level parser/debugger integrations.
• More direct release path for editor work: UI improvements, transforms, checkpointing, profiling, and performance work can ship with OmegaEdit without requiring Daffodil to vendor or rework the editor.
• Better API contract: downstream integrations can target a versioned activation API rather than private client/server details.

Risks and tradeoffs

• The OmegaEdit extension must be packaged and published under the stable id ctc-oss.omega-edit-data-editor.
• Daffodil's release/test flow needs to install the real OmegaEdit VSIX or marketplace extension during integration testing.
• The activation API becomes a compatibility contract, so breaking changes need an explicit version bump and migration story.
• The VS Code engine-version floor needs coordination. Daffodil currently supports an older VS Code range than the OmegaEdit extension currently declares.
• If future Daffodil features need richer byte annotations, the generic highlight model may need grouping, priorities, lifetimes, or richer tooltip payloads.

Proposed next steps

1. Package the OmegaEdit Data Editor extension as a real VSIX under ctc-oss.omega-edit-data-editor.
2. Validate Daffodil's dependency path with the real VSIX installed alongside Apache Daffodil VS Code.
3. Run a Daffodil debug session with openDataEditor enabled and verify:
   • the configured data file opens in OmegaEdit
   • parser steps reveal the current byte
   • debug termination clears Daffodil-owned highlights
4. Decide whether Daffodil needs editor-originated cursor/selection events beyond the current editor-state event.
5. Decide whether parse errors and leftover-data events should become inline byte annotations when offsets/lengths are available.
6. If validation holds, keep Daffodil's integration at the extension API boundary and avoid reintroducing direct OmegaEdit server/client ownership in the Apache repo.

Ask

Does this extension-level dependency boundary look like the right long-term shape for the Apache Daffodil VS Code integration?

In particular, feedback would be helpful on:

• whether the open plus external-highlight API covers the debugger handoff cleanly
• whether any Daffodil behavior still truly needs library-level access
• whether the proposed ownership split matches how Daffodil maintainers want to maintain the extension
• what compatibility expectations should exist for the OmegaEdit activation API