Vix.cpp v2.7.7

Vix.cpp v2.7.7 introduces the first package-based extension architecture for Vix Note.

The release allows Note to discover new cell types and runtimes from ordinary Vix packages rather than requiring every integration to be implemented directly inside the Note module. It also adds the registry, command-line, and interface workflows needed to install and manage those extensions.

Alongside the Note work, this release modernizes the Vix Reply interactive terminal. Native C++ snippet mode now behaves more like a real code editor, with syntax highlighting, automatic indentation, cursor-aware editing, additional keyboard shortcuts, and an initial optional Vi keymap.

The release also fixes global installation for header-only packages that build command-line executables without declaring CMake runtime installation rules.

Release focus

Vix Note already supported Markdown, HTML, C++, and Reply cells, but those cell types were part of the application itself. Adding another language or specialized runtime required modifying the Note codebase, rebuilding the application, and maintaining the integration as part of the main project.

Vix.cpp v2.7.7 changes that boundary.

A Note extension can now be published as a standard package through the Vix Registry. The package declares its Note contribution in its manifest, provides the required runtime when execution is needed, and becomes discoverable after installation. This gives extension authors a path to add languages, visualization tools, development utilities, and domain-specific cells without placing every integration inside Vix Note.

The goal of the initial system is not to define every possible extension mechanism at once. It establishes the package format, discovery rules, execution protocol, management workflow, and compatibility model that later releases can extend.

Package-based Vix Note extensions

Vix packages can now declare a Note extension through the extensions.note manifest section.

The extension metadata describes how the package participates in Vix Note. It can declare an extension API version, capabilities, contributed cell types, runtime configuration, aliases, and required permissions. This information remains part of the package when it is published, installed, and recorded in the global package registry.

Using the existing package system is an important part of the design. Extension authors do not need a separate distribution service or an unrelated installation format. A Note extension follows the same namespace, versioning, registry, publication, and installation model as other Vix packages.

This also means the extension lifecycle fits into an existing Vix workflow: developers can search for packages, inspect their metadata, install them globally, and remove them using familiar commands.

Extension discovery

Vix Note now discovers extensions from three sources:

  • built-in extensions shipped with Vix Note;
  • project-local extensions;
  • globally installed Vix packages.

Project-local extensions take precedence over global extensions with the same contribution. This makes it possible for a project to select or develop a specific integration without changing the global environment used by other projects.

Built-in cell types remain protected. An installed package cannot silently replace the standard Markdown, HTML, C++, or Reply behavior by declaring the same type. This keeps the default Note environment predictable while still allowing external packages to add new cell types and capabilities.

The existing built-in cells now pass through the same extension system used by external integrations. This avoids maintaining two unrelated execution paths and ensures that the extension architecture is exercised by the standard Note workflow itself.

To inspect the extensions currently visible to Vix Note, use:

vix note --list-extensions

The command includes built-in, project-local, and globally installed extensions after applying the normal discovery and precedence rules.

Custom cell types

The .vixnote document model can now preserve cell types that are not built into the application.

For example, a document containing a python cell can be loaded, saved, and exported without Vix Note rewriting the cell as an unknown built-in type or discarding its original contribution metadata. The cell remains part of the document even when its extension runtime is not currently available.

This distinction matters for portable notebooks. Opening a document on a machine without one of its extensions should not damage the document. Execution may be unavailable until the required package is installed, but the notebook structure and source content remain intact.

Preserving external cell types also allows documents to move between projects and machines while retaining the information needed to restore their original execution environment.

External runtime protocol

Executable Note extensions can communicate with Vix Note through the vix-note-extension-1 JSON protocol.

The initial implementation uses a generic external runtime. Vix Note starts the configured extension process, sends a structured execution request, and reads the structured response produced by that process. The request can include information such as the cell identifier, cell type, source code, execution count, working directory, document path, extension identity, and extension version.

Keeping the protocol language-independent allows an extension runtime to be implemented with the language or toolchain that fits its purpose. The package remains a Vix package, while the process behind the extension can execute Python, invoke a compiler, communicate with another runtime, or transform the cell content.

The current runtime model is intentionally simple: each execution starts a one-shot process. This provides a clear isolation boundary and is sufficient for the first external integrations. Persistent kernels and long-running extension sessions require additional lifecycle and protocol work and are not part of this release.

Dynamic cell discovery

Vix Note now exposes discovered extensions through:

GET /api/extensions

The Note frontend uses this endpoint to determine which cell types are currently available. New cell types no longer need to be duplicated in a static frontend list before they can appear in the interface.

The endpoint provides the contribution metadata required by the editor, including the available types and their associated extension information. The frontend can therefore adapt to the current environment after an extension is installed, enabled, disabled, or removed.

This is also the foundation for future extension-aware editor behavior. A later extension may need more than a name in the cell selector, but dynamic discovery must exist before richer contributions can be introduced cleanly.

Extension management in Vix Note

Vix Note now includes an extension management interface.

The interface separates built-in, installed, recommended, and registry extensions so developers can understand where a contribution comes from and whether it is already available in the current environment. An extension can be installed, uninstalled, enabled, or disabled without leaving Note.

Each extension also has a details page containing its runtime information and contribution metadata. This provides a place to inspect the cell types, capabilities, aliases, and execution configuration associated with a package before using it in a document.

Disabling an extension keeps the package installed while removing its contributions from the active Note environment. Uninstalling removes the installed package and its registered extension metadata. These are intentionally separate operations because temporarily disabling an integration should not require downloading it again later.

Registry and package commands

The package publication workflow now understands Note extension metadata.

When vix publish processes a package containing an extensions.note section, it validates the extension declaration and preserves the metadata in the published package entry. Invalid extension declarations are rejected before they become part of the registry.

vix search also supports extension-specific filters:

vix search --extension note --json

Available options include:

--extension
--capability
--type
--json

Extension searches do not require a text query. A developer can search by contribution type or capability when the package name is not known.

Ordinary text search continues to work:

vix search json --json

Global package installation now preserves extension metadata in the global installation registry. This allows Vix Note to discover an installed extension without needing to inspect or reinterpret every package directory on each startup.

Together, these changes connect the complete workflow: publication records the contribution, search exposes it, installation preserves it, and Vix Note discovers it.

Vix Reply editor

Vix Reply receives a substantial interactive terminal update in v2.7.7.

The terminal now opens with a Vix-branded banner that identifies the Reply version, compiler, platform, exit shortcut, clear shortcut, and help command. Native C++ snippet mode has its own prompt so it is visually distinct from the regular Reply session.

The most significant changes are inside the C++ editor. Earlier versions were primarily designed for appending text to the end of a line. The updated editor maintains an active cursor position and can insert or delete content in the middle of existing code.

Left and right arrow keys now move across the complete input line. Home and End move to the beginning or end, while Delete removes the character at the cursor. Common terminal editing shortcuts are also supported:

Ctrl+A  move to the beginning
Ctrl+E  move to the end
Ctrl+U  remove content before the cursor
Ctrl+K  remove content after the cursor

These operations continue to work while syntax highlighting is active.

C++ syntax highlighting

Native C++ snippet mode now applies real-time lexical highlighting while code is entered.

The highlighter recognizes common C++ structures including preprocessor directives, included headers, keywords, built-in types, strings, numeric literals, comments, namespaces, macros, and function calls.

The highlighting is lexical rather than compiler-backed. It improves readability and gives immediate visual structure to a snippet, but it does not attempt full semantic analysis, type resolution, or language-server diagnostics.

Compiler errors still come from the real compilation step. Vix Reply continues to present structured compiler diagnostics after execution rather than treating terminal highlighting as a replacement for the compiler.

Color output follows terminal capabilities. NO_COLOR is respected, and highlighting is disabled when Reply is running in a non-interactive environment where terminal color sequences would be inappropriate.

Indentation and code editing

C++ mode now tracks block depth and applies automatic indentation when a new line is created inside braces.

Entering a closing brace automatically dedents the current line to the appropriate level. Tab and Shift+Tab can also indent or unindent the active code line manually.

The Tab key has different behavior inside native C++ mode than in the regular Reply prompt. It edits code indentation instead of opening command completion. This prevents the normal Reply completion menu from interrupting snippet editing.

Backspace understands indentation levels at the beginning of a line and can remove one level cleanly rather than deleting whitespace one character at a time.

The editor also preserves the source as it was entered. Indentation is no longer removed before a snippet is stored or executed, and empty lines inside a snippet remain part of the source without being converted into indentation-only lines.

Continuation prompts now align with the first C++ input line, making multi-line functions and blocks easier to read in the terminal.

Optional Vi keymap

Vix Reply now includes an initial Vi-style editing mode.

It can be enabled with:

VIX_REPLY_KEYMAP=vi vix

The first version focuses on a small set of navigation and editing commands:

h  move left
l  move right
0  move to the beginning
$  move to the end
w  move to the next word
b  move to the previous word
i  enter insert mode
a  insert after the cursor
I  insert at the beginning
A  insert at the end
x  delete the current character

This is not intended to provide complete Vim compatibility. It establishes the editor state model and the most useful navigation commands without making the initial implementation difficult to understand or maintain.

The regular terminal keymap remains the default.

Global installation of CLI packages

This release fixes an installation problem affecting some header-only packages that also build a command-line executable.

A package may be header-only as a library while still defining an executable target for a developer tool. Some of these packages do not provide an explicit CMake rule such as:

install(
  TARGETS my_command
  RUNTIME DESTINATION bin
)

Previous versions of vix install -g could build the executable successfully but fail to place it in the Vix global binary directory because the CMake install step had no runtime target to install.

Vix now detects the generated executable in this case and copies it into:

~/.vix/global/bin

When that directory is present on PATH, the command becomes available immediately.

Packages that already provide correct install(TARGETS ...) rules continue to use the standard CMake installation process. The fallback is used only when the package produces an executable but does not install it itself.

Vix Note asset resolution

The vix note launcher now prefers installed frontend assets over stale assets left in a build directory.

This fixes cases where the executable had been updated but Note opened an older frontend from a previous local build. Installed deployments now resolve the assets associated with the installed version before considering development build-tree locations.

The change keeps the application code and interface version aligned when Vix is installed or upgraded.

Validation

The extension system was validated across discovery, package management, document storage, frontend integration, and external execution.

The Vix Note module and Vix CLI were built successfully with the new extension infrastructure. Built-in extensions were discovered through vix note --list-extensions, and the install, enable, disable, and removal workflows were exercised through the extension manager.

Custom cell preservation was tested with Python cells by loading, saving, and reopening .vixnote documents. The /api/extensions endpoint was verified against the active extension registry, and execution was tested through a temporary external runtime implementing the vix-note-extension-1 protocol.

Registry search behavior was verified with both extension-aware and normal queries:

vix search --extension note --json
vix search json --json

The global installation fallback was tested with:

vix install -g gaspardkirira/cli_test
command -v cli_test
cli_test chain 5

A regression test now covers global installation of a header-only package that produces a CLI executable without CMake runtime installation rules.

The complete Vix project was also built with the updated Reply module. Interactive verification covered syntax highlighting, automatic indentation, closing-brace dedentation, Tab, Shift+Tab, Backspace, arrow-key navigation, Home, End, Delete, and insertion in the middle of an existing line.

Native C++ snippet execution and structured compiler diagnostics were tested after the editor changes. The optional Vi keymap was verified with VIX_REPLY_KEYMAP=vi, and the updated Reply code builds without unused-function warnings.

Compatibility

Existing Markdown, HTML, C++, and Reply cells remain available. Their implementation now passes through the extension architecture, but the normal notebook workflow does not require users to install separate packages for these built-in types.

Existing .vixnote documents remain compatible. Documents can also contain external cell types without losing them when the corresponding extension is missing.

Registry packages that do not declare Note extensions continue to use the normal package workflow. Packages with valid extensions.note metadata gain the additional search, discovery, and management behavior introduced in this release.

The global installation fix does not replace standard CMake installation rules. Packages with an explicit runtime installation target continue to follow their existing install process.

Known limitations

External extension runtimes currently use one-shot processes. A new process is created for each execution, so the system does not yet provide persistent language kernels or reusable interactive sessions.

External process execution is currently available on POSIX platforms. On Windows, Vix Note reports an explicit unsupported runtime error rather than attempting an incomplete execution path.

Interactive permission prompts are not yet implemented. The manifest can describe permissions, but a complete user approval and permission persistence workflow will require additional work.

Extensions cannot yet provide frontend JavaScript, load through a native C ABI, or request an automatic local runtime build. These areas require stricter isolation, compatibility, and lifecycle rules before they can be supported safely.

Additional end-to-end CTest coverage is also planned for the complete extension lifecycle.

Vix Reply highlighting remains lexical and does not replace compiler-backed semantic tooling. The optional Vi keymap provides an initial focused command set rather than full Vim behavior.

Release summary

Vix.cpp v2.7.7 gives Vix Note an extension boundary that fits the rest of the Vix ecosystem.

Extensions are ordinary packages. They can be published through the Vix Registry, discovered from local or global installations, managed from the Note interface, and executed through a language-independent protocol. Custom cell types remain part of the document even when their runtime is unavailable.

The Reply update improves a different part of the workflow: writing and testing native C++ directly in the terminal. Cursor-aware editing, highlighting, indentation, keyboard shortcuts, and the initial Vi mode make snippet entry more practical without changing the underlying compile-and-run model.

Together with the global CLI installation and Note asset fixes, the release makes Vix more extensible while improving the reliability of the tools developers already use.