Showcase

sem-shell: the document, interactive

Some documents want a prompt, not a page. sem-shell is a terminal element preconfigured with two plugins — a POSIX-style command set (ls, cat, grep, pipes, redirects) and the demo commands (semtext, open) — running over a virtual file system. Useful-stuff documents: a browsable snapshot of a repo, a workshop where the reader runs the commands they just read.

The markup

One empty element boots the shell; a bare sem-terminal is the same terminal without the bundled plugins, for hosts that wire their own.

sem-shell example

sem-shell.md · authored SemText

source

      
      <sem-shell></sem-shell>
    
      <!-- a bare terminal, wired by the host page to remote plugin manifests -->
    
      <sem-terminal plugins="https://cdn.example.com/semtext/plugins/manifest.json#sha256-BASE64DIGEST"></sem-terminal>

render — pending bundle

Render view: this block wires to the SemText runtime bundle in the full example viewer (port-reference lane) — the source beside it is the same file, byte for byte.

Plugins and the integrity rule

The two bundled manifests mount locally — no fetch. A remote plugin is opt-in per element via the plugins attribute, and every URL must carry an integrity hash: a plugin from an absolute https URL without one is refused before any network request, the refusal printed as a stderr line and recorded on the terminal's load errors.

Status

The element ships in semtext-js-shell.js (an IIFE exposing the global SemTextShell; the build manifest maps both sem-shell and sem-terminal to it) — a bundle kept out of the core on purpose, since the shell is agent and demo tooling, not document vocabulary. This site does not carry that bundle yet, so the example above stays in source view rather than pretending to render.

The terminal itself — playback, the flashcard TUI, the command set — is built in noizu-labs-ml/npl-enhanced-content .