v1.8.0-preview.3

Preview build for Windows testing — not a stable release. Isolated from stable users: herdr plugin install (no --ref) still serves v1.7.0, and the in-app update check ignores pre-release tags.

v1.8.0-preview.3 — reworks the Windows launcher based on live real-hardware testing (thanks @anirudhsk-official 🙏). The viewer itself was proven to render correctly on Windows; the earlier previews just couldn't launch it automatically.

What changed since preview.2 (GH #58)

The real root cause: herdr on Windows can't spawn a plugin's relative command — it passes the relative program name to CreateProcessW, which resolves it against herdr's own directory (not any --cwd), so it always failed ERROR_PATH_NOT_FOUND. So the Windows launcher now spawns the viewer by absolute path (pane split / tab create + pane run), rooted at your focused pane's directory, and the actions locate their launcher script by asking herdr for its own plugin folder. Proven working end-to-end on real hardware.

Prerequisites (Windows)

• herdr on its preview channel (Windows binaries ship only there).
• Git for Windows on PATH — herdr uses it to install the plugin, and the viewer uses it for the tree's git status + diffs.
• Windows Terminal.
• Optional renderers for pretty output (without them, files show as plain text — that's the intended fallback, not a bug):

  winget install charmbracelet.glow
  winget install sharkdp.bat
  winget install dandavison.delta
  

  Install these before starting herdr (or restart herdr afterward) so it picks them up on PATH.

Install

herdr plugin install smarzban/herdr-file-viewer --ref v1.8.0-preview.3

Pulls a SHA-256-verified prebuilt .exe — no Rust toolchain needed.

Try it

Bind a key (in ~/.config/herdr/config.toml), or invoke the action directly:

herdr plugin action invoke open-file-viewer-windows --plugin herdr-file-viewer

The viewer should open in a split on the right, rooted at your current pane's directory. Press again to focus/close it. Tab variant: open-file-viewer-tab-windows.

Known limitation

The type = "shell" keybinding spawn appears to be a herdr-side issue on Windows (the identical action invoke works when typed) — being tracked upstream. Mouse clicks inside the pane also depend on herdr forwarding mouse events; the viewer is fully keyboard-driven regardless (? shows all keys).