What
runtime/doc/news.txt (nightly/unreleased section) now documents that when the experimental ui2 message pager is enabled, <CR> no longer pages/dismisses long messages by default:
ui2 messages pager no longer uses <CR> by default; use g< or configure 'messagesopt'
cfg.pager_char and cfg.msg.timeout replaced by 'messagesopt' items "pager" and "timeout"
Where
lua/config/plugin_config.lua:508-522:
local noice_ok, noice = pcall(require, "noice")
if not vim.g.vscode then
local ui2_ok, ui2 = pcall(require, "vim._core.ui2")
if not noice_ok then
if ui2_ok then
-- {} required: calling enable() without args is a documented Neovim bug (neovim/neovim#38594)
pcall(ui2.enable, {})
vim.notify("nvim ui2 enabled", vim.log.levels.INFO)
else
vim.notify("nvim ui2 disabled (could be old nvim or api shift)", vim.log.levels.WARN)
end
else
vim.notify("use noice/nui ui layer", vim.log.levels.INFO)
end
end
This repo deliberately falls back to nightly's native ui2 whenever noice.nvim fails to load — and noice.nvim itself is already flagged in #327 as maintenance-stalled, so this fallback path is only going to get exercised more over time, not less.
Why it matters
Anyone hitting a long :messages / multi-line notification on this fallback path will press <CR> out of muscle memory (the behavior every prior Nvim version and noice.nvim itself both trained) and nothing will happen — the message just sits there until they discover g< or configure 'messagesopt'. Since ui2 is still unreleased/experimental, the exact 'messagesopt' value syntax could still change before it stabilizes, so this isn't a safe one-line mechanical fix yet.
Recommended action
- When the
ui2.enable({}) branch is taken, also set vim.o.messagesopt to restore pager-style <CR> behavior once the exact item syntax is confirmed against the nightly build this repo tracks (check :h 'messagesopt' on each nightly bump, since this is still in the "UNRELEASED BREAKING CHANGES" section of news.txt as of 2026-10-05 and could shift again before release).
- Alternatively/additionally, surface a one-line
vim.notify hint (e.g. "ui2 pager: use g< to scroll long messages") alongside the existing "nvim ui2 enabled" notification, so the behavior change doesn't surprise users silently.
- Re-check this once
ui2 graduates out of the unreleased section — the final default may differ from what's documented today.
What
runtime/doc/news.txt(nightly/unreleased section) now documents that when the experimentalui2message pager is enabled,<CR>no longer pages/dismisses long messages by default:Where
lua/config/plugin_config.lua:508-522:This repo deliberately falls back to nightly's native
ui2whenevernoice.nvimfails to load — andnoice.nvimitself is already flagged in #327 as maintenance-stalled, so this fallback path is only going to get exercised more over time, not less.Why it matters
Anyone hitting a long
:messages/ multi-line notification on this fallback path will press<CR>out of muscle memory (the behavior every prior Nvim version andnoice.nvimitself both trained) and nothing will happen — the message just sits there until they discoverg<or configure'messagesopt'. Sinceui2is still unreleased/experimental, the exact'messagesopt'value syntax could still change before it stabilizes, so this isn't a safe one-line mechanical fix yet.Recommended action
ui2.enable({})branch is taken, also setvim.o.messagesoptto restore pager-style<CR>behavior once the exact item syntax is confirmed against the nightly build this repo tracks (check:h 'messagesopt'on each nightly bump, since this is still in the "UNRELEASED BREAKING CHANGES" section ofnews.txtas of 2026-10-05 and could shift again before release).vim.notifyhint (e.g. "ui2 pager: use g< to scroll long messages") alongside the existing "nvim ui2 enabled" notification, so the behavior change doesn't surprise users silently.ui2graduates out of the unreleased section — the final default may differ from what's documented today.