Neovim messages and vim.notify: where should informational alerts cross the boundary?

Question

Neovim exposes two related but distinct channels: the core message system, including the :messages history, and the Lua notification API, vim.notify. The integration question is where informational output should be routed. A plugin can emit vim.notify(..., vim.log.levels.INFO), while core and plugin messages may also pass through the MsgWrite event; shortmess separately controls which messages are displayed.

This creates a policy decision rather than a single configuration choice: should informational messages remain in the durable message history, be promoted to transient notifications, or be routed to a custom notification provider? A provider could duplicate messages already shown by Neovim, while aggressive suppression could hide useful context.

The target is assumed to be Neovim 0.9 or later. Notification API details and message buffering may differ between 0.9 and 0.10+, so the intended behavior needs verification against the exact release and any notification plugin in use. The unresolved design question is whether one source should have a single authoritative destination or whether channel selection should remain explicit.

Should core informational messages be eligible for automatic notification routing, or should vim.notify remain the explicit boundary for transient alerts? Should promoted messages remain in message history, or expire after a configurable timeout?

Tasadduq Burney · Answer

Informational alerts should be routed through vim.notify, not the core :messages history.
The core message system stores every message in a durable list that persists across sessions and is filtered only by shortmess. It never auto‑dismisses, so informational output remains visible unless manually cleared.
Likely explanation

Transient notifications disappear after a short timeout, keeping the message list clean.
Using vim.log.levels.INFO with vim.notify sends the same text through the notification API while preserving the message history if needed.
Plugins that duplicate messages must explicitly write to :messages because Neovim does not auto‑route informational level messages.

Confirmed facts

Run :version to ensure Neovim ≥ 0.9; later releases may change the default timeout of vim.notify.
Execute :lua vim.notify('test', vim.log.levels.INFO) and verify a brief popup appears, then check that the same text is present in :messages.
If a notification plugin is active, open its settings and confirm it does not override INFO‑level behavior.

Steps for this case

Confirm the Neovim version is 0.9 or newer.
Test the notification with the command above; observe the transient display.
Decide whether the message must stay in the history. If persistence is required, add an explicit :messages write or configure the plugin to duplicate the output.
If you prefer the message to disappear after display, rely solely on vim.notify and leave the core history untouched.

Do you need the informational message to remain in :messages after it is shown, or is a temporary popup sufficient? Your answer will determine whether an extra duplication step is required.

Neovim messages and vim.notify: where should informational alerts cross the boundary?

1 answer

Informational alerts should be routed through `vim.notify`, not the core `:messages` history.

Likely explanation

Confirmed facts

Steps for this case

Your perspective belongs here.

0 question comments