Sniprun for partial code execution in Neovim

Sniprun's partial evaluation scope

Sniprun addresses a specific friction point in editor-based development: a useful piece of code may sit inside a file that is incomplete, contains unrelated errors or does not run cleanly as a whole program. The plugin lets a Neovim user send a current line or visual selection to a runner while leaving the surrounding file untouched. The README positions this workflow between saving and running an entire file, using a notebook and interacting with a REPL.

The intended users are people learning a language, experimenting with an isolated function or class fragment, and building short pipelines in a single file. Sniprun also supports literate programming in Markdown, Orgmode and Neorg, so the selected region can be part of a larger document rather than a conventional source file. This makes the plugin useful when a complete application build would be slower or impossible than evaluating the selected lines.

This is not a general replacement for running a complete project. The selected fragment still needs enough imports, declarations and runtime context to be meaningful. The README says that Sniprun can automatically fetch some required imports, but it does not claim that this works for every language or every fragment. The distinction is important: partial execution changes where a program starts, not the rules of the language itself.

Sniprun also offers multiple result destinations, including classic output, virtual text or virtual lines, a temporary floating window, a terminal, notifications and an API. The documentation says these modes can be enabled at the same time, with different output statuses treated separately. That flexibility is useful for comparing output with nearby code, but it also means configuration can become less simple than the default `:SnipRun` workflow.

The Lua and Rust execution path

The repository contains both Lua code under `lua/`, plugin files under `plugin/`, and Rust source under `src/`. The README identifies the project as a Neovim plugin written in Lua and Rust. Its Neovim-facing commands collect the requested region, while the Rust implementation handles the execution infrastructure and language-specific runners. The repository layout includes interpreter-related code and an `API.md`, indicating that execution is exposed through a defined interface rather than only through terminal commands typed into a buffer.

The basic request starts with `:SnipRun`, which the README associates with the current lines, and `:'<,'>SnipRun`, which sends a visual selection. Results can then be presented through one of several documented display mechanisms. The README also lists `:SnipInfo` as a core command.

For some languages, Sniprun uses REPL-like behavior. The documented list includes Python, Julia, Lua, JavaScript and TypeScript through Deno, Clojure, R, Mathematica, Sage, PHP, Swift, OCaml and Rust through `evcxr`. In this mode, later code can depend on previously executed code. The implementation therefore is not limited to compiling each visual selection as an entirely independent unit for those languages.

The project documentation also describes an API for running code and displaying results. The exact API call syntax is in `API.md`, which is part of the repository. The README does not claim that every language has the same execution semantics, so an adopter should distinguish the shared Neovim interface from the language-specific interpreters underneath it.

Neovim setup and first partial run

The README gives a compact installation declaration using a `michaelb/sniprun` entry with a `build = "sh install.sh"` setting. The command shown for building the project is the following:

sh install.sh

The README does not include a complete plugin-manager setup in the available text. Its installation link points to the project's documentation, and the repository contains `install.sh`, `Cargo.toml`, `plugin/` and `lua/` entries. The first documented execution commands are:

:SnipRun
:'<,'>SnipRun
:SnipInfo

A first use would involve opening a supported source file in Neovim, placing the cursor on the lines to evaluate, and invoking `:SnipRun`. For a selected range, enter visual mode, select the code, and invoke `:'<,'>SnipRun`. The expected result is the selected code being sent to Sniprun and its result appearing in the configured display mode. The default behavior requires no configuration according to the README.

Neovim users can also create mappings for these commands. The README links to mapping recommendations but does not show a complete mapping snippet.

Supported languages and execution contexts

Sniprun covers interpreted and compiled languages, but the supported set is not equivalent to an arbitrary executable environment. The README explicitly lists languages with REPL-like behavior and separately points to an official support table and community examples for languages without official support. This distinction matters because an unofficial community runner may depend on locally installed tools that are not bundled with the plugin.

The project is written around the idea that a selected fragment can run independently of the rest of the file. It can also run incomplete or error-containing regions, which is useful during experimentation. However, the README does not document automatic restoration of a fragment's complete project state, environment variables, build system or compiled artifacts. A fragment that succeeds in isolation may behave differently when inserted into the full program.

The plugin's stated use cases include GUI plots, network requests and Ansible playbooks. Those examples show that the runner is not limited to pure functions, but they do not remove the ordinary operating-system and project-context requirements of those workloads. In particular, a network request may depend on the user's network environment, and an Ansible playbook may require files, credentials and paths that are not available from the plugin's execution location.

Sniprun cache paths and documented failure cases

The most consequential limitation is the execution working directory. The README states that Sniprun runs from a location somewhere under `~/.cache/sniprun`. Code that accesses files may still reach the filesystem, but relative paths can fail because the selected fragment is not running from the directory where the user placed the original file. Relative imports are called out as a possible consequence of the same problem.

Programs that read from standard input are also unsuitable. The README lists programs that need stdin among the cases with which Sniprun may have trouble. The same limitation applies to programs that manipulate standard output or standard error: a runner needs predictable streams to send selected code, capture output and present it in the editor. The project documentation does not explain an interactive terminal mode that would make these programs equivalent to running them directly from a shell.

Windows is explicitly unsupported. The README says NixOS and macOS users must compile Sniprun locally, and it states that other Unix systems besides Linux have not been tested. Those are platform boundaries rather than minor setup differences. A Linux user can still face language-specific requirements if the relevant compiler, interpreter, `deno`, `evcxr` or other tool is absent.

These limits are direct consequences of partial execution. Sniprun can reduce the amount of code that needs to run, but it does not recreate every condition provided by a complete application or shell session.

Sniprun release and license considerations

The repository uses the MIT license. That permits use, modification and redistribution under the license's stated conditions, but users who need compliance guidance for a particular organization must review the license and dependency obligations themselves. The repository includes a `LICENSE` file and a Rust package manifest with package version `1.3.22` and Rust version `1.65`.

The listed recent releases are `v1.3.22` on 2026-02-26, `v1.3.21` on 2025-12-30 and `v1.3.20` on 2025-10-11. The last push was on 2026-07-29. The repository is not archived. These facts indicate that the project has received recent repository activity, but they do not establish that every language runner or platform combination receives equal maintenance.

The upgrade cost is tied to three areas: the Neovim plugin, the compiled Rust binary and the external language tools required by the selected runners. The README does not provide a compatibility matrix for every external tool, nor does it document a general rollback procedure. Users should check the project's installation documentation, release notes and language-specific support entries before changing versions, especially when a workflow depends on REPL state or cached files.

Sniprun versus running the complete program

The practical alternative is the normal Neovim or shell workflow: save the file, invoke the language's compiler, interpreter, package runner or project-specific command, and inspect the complete program output. That approach has different priorities. It preserves the project's working directory and dependency graph, but it also requires enough of the program to compile or run. It is the better fit when the code needs stdin, project-relative files, coordinated standard output or the initialization state of an entire application.

Sniprun is better when the goal is immediate feedback on a small region, especially one that is not yet valid as a whole file. Its visual-selection command makes the execution boundary explicit, and its multiple display modes place results near the code. The tradeoff is that the selected region may lack context. The plugin can fetch some imports and can retain state for some REPL-like sessions, but neither capability is documented as a substitute for the full project environment.

There is also a workflow alternative within Neovim: use a language-specific REPL, notebook kernel or debugging session. Sniprun's API and display modes make it more than a terminal wrapper, but they also create a project-specific integration layer. A team already invested in language-specific tooling may prefer those tools when project fidelity matters more than running an incomplete fragment.

Editorial conclusion

Sniprun is appropriate for Neovim users who routinely test incomplete snippets, especially on Linux with supported interpreters or compilers. It is unsuitable for programs that depend on standard input, carefully managed standard output, the whole project context or Windows. Before adopting it, verify that the required language toolchain exists and that the cache working directory does not invalidate relative paths or imports.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. michaelb/sniprun on GitHub
4. README
5. Releases