Module code_editor 

CodeEditor — the batteries-included editor tier.

Editor is a controlled widget: it borrows a Document immutably to draw and emits semantic Actions the host applies. That gives maximum control at the cost of a large amount of plumbing — driving highlighting, find, focus, and the intel controllers is all on the host. CodeEditor is the other end of that trade: it owns a Document, runs the plumbing internally, and reduces integration to three wires — update, view, subscription — plus registering required_fonts at startup.

Mechanism vs policy

The split that keeps this honest: mechanism (the highlight pump, find rescan, focus rings, autoscroll, the intel drive loops) is owned here, hidden, and always-correct — a host cannot forget a step it never had to take. Policy (grammar, theme, providers, sizing) is a builder override with a sensible default. The one genuine fork is ownership: CodeEditor owns the Document and exposes reads plus blessed mutations that run the post-edit tail — there is deliberately no raw &mut Document, because that is the trapdoor that lets a caller mutate behind the tail’s back (the exact shape of the cold-load highlight bug this tier exists to prevent). A host that must own the buffer itself drops to the Editor power tier.

This module is built up across milestones; M1 is the synchronous core loop (owned document, the three wires, and the cold-load highlight fix). Find, the intel drive loops, the large-document parallel sweep, and the async intel round-trip land on top in later milestones.

Structs

CodeEditor

A batteries-included code editor: owns a Document, renders the Editor widget, and runs the editing/highlighting plumbing internally. See the module docs for the mechanism-vs-policy split and the ownership fork.

CompletionRequest

A request for completions the host fulfills asynchronously (off-thread or via a language server). The editor emits one where it would call a synchronous provider but none is set; the host pulls it with CodeEditor::take_completion_request, runs its query, and returns the result through CodeEditor::set_completions stamped with revision.

HoverRequest

A request for hover documentation the host fulfills asynchronously. Emitted where the editor would call a synchronous Hover provider but none is set; the host pulls it with CodeEditor::take_hover_request, queries, and returns the card (or None) through CodeEditor::set_hover. Diagnostics at the point are shown synchronously regardless; a host that wants them in the async card can read them from CodeEditor::document and include them.

SignatureRequest

A request for signature help the host fulfills asynchronously. Emitted where the editor would call a synchronous SignatureHelp provider but none is set; the host pulls it with CodeEditor::take_signature_request, queries, and returns the result (or None to close the box) through CodeEditor::set_signature.

Enums

Event

The opaque message a CodeEditor emits and consumes. The host never matches on it — it only maps it through the three wires (self.editor.update(e).map(Message::Editor) and the same for view / subscription). It is deliberately opaque: the internal set churns with every refactor, so host-relevant signals come through the curated read accessors and builder callbacks instead. A host that genuinely needs the raw semantic vocabulary drops to the Editor power tier, where Action is the stable, match-on-me enum.