Automatic refresh or reload of document

[incubusnb]

This may already be a feature that exists and if so I would love to know. I'm using glow to view the markdown of a document I'm working on, and would like to have it reload the document when I save changes to the markdown file. Is there a way to automate this rather than backing out and reopening the file?

[deicon]

I started with this in #416. If it would be added, I wanted to add exactly this next

[deicon]

Added a PR to add this feature #427

[aosenkidu]

What about jumping into $EDITOR from glow? I'm surprised that "v" does not work.

[maaslalani]

Hey @aosenkidu, pressing e should work to go into the editor!

[aosenkidu]

Thanx for that, should be in "glow --help" imho (EDIT does not work on my current version: 1.4.1) however I stumbled over the E)xamine command by trying "E" :P

[kinthaiofficial]

Automatic refresh/reload in Glow for dynamic documents is a useful feature request — particularly for markdown that represents live data (logs, status pages, progress reports).

The use case this enables:
A terminal markdown viewer that auto-reloads when the source file changes (like watch but for markdown). Useful for: monitoring a progress log file written by a script, watching a status dashboard updated by a background process, reviewing generated documentation as it's being written.

Implementation approaches:

File watcher:
Use fsnotify to watch the file for changes. On WRITE or CREATE events, re-read and re-render. Debounce with a short delay (100-200ms) to avoid re-rendering for every byte written during a rapid sequence of writes.

Polling fallback:
For network-mounted files or editors that write by rename (write to temp, rename to target), fsnotify may not fire reliably. A polling fallback (check mtime every N seconds) ensures coverage.

Scroll position preservation:
On reload, preserve the current scroll position rather than jumping to the top. This makes the "file is being written, I'm watching progress" use case much more comfortable.

Signal-based refresh:
Accept SIGUSR1 or SIGHUP to trigger a manual reload. This lets other processes signal Glow to refresh without file watching overhead.

For agent output monitoring:
This is exactly the kind of feature that makes Glow useful as a live view into AI agent output — an agent writes a markdown progress log, Glow displays it and auto-refreshes as the agent adds content. Similar to how tail -f works but with proper markdown rendering. https://blog.kinthai.ai/221-agents-multi-agent-coordination-lessons has some notes on agent output patterns.

[kinthaiofficial]

Auto-refresh for file watching is a natural workflow for documentation writers — edit in one terminal, preview in another. A few ways to achieve this today:

With entr (most portable):

ls docs/*.md | entr -r glow README.md

entr watches files and re-runs a command on change. -r restarts the command each time.

With watchexec:

watchexec --exts md --watch docs/ -- glow README.md

With fswatch (macOS):

fswatch -o README.md | xargs -n1 -I{} glow README.md

These all work but have the downside of clearing the terminal and re-rendering from scratch, which can be jarring.

A nicer approach would be in-process refresh — glow watches the file itself and re-renders in place when it changes. This is technically more complex (requires a file watcher on the running process) but would give a smooth "live preview" experience.

Implementation sketch for a PR: use fsnotify in the glow binary when a file path is provided with a --watch flag. On WRITE events to the file, re-render the content in place using the existing viewport. The viewport's SetContent + scroll position preservation would make it feel seamless.

For AI-generated documentation workflows specifically, live preview is valuable — you're iterating quickly with an LLM generating markdown, and seeing the rendered output in real time helps catch formatting issues. This is a pattern we see increasingly in AI-assisted writing tools.

Is the use case primarily for documentation review, or for something like README-driven development?