From 689a149b089095a29ef2fcfbf31137a230f28d07 Mon Sep 17 00:00:00 2001
From: Willaaaaaaa <1091220123@qq.com>
Date: Thu, 12 Mar 2026 02:16:35 +0800
Subject: fix(prompt): don't implicitly set 'modified' #38118
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Problem:
In aec3d7915c55fc0b7dc73f6186cf0ae45d416d33 Vim changed prompt-buffers
to respect 'modified' so the termdebug plugin can "control closing the
window". But for most use-cases  (REPL, shell, AI "chat", …),
prompt-buffers are in practice always "modified", and no way to "save"
them, so *implicitly* setting 'modified' is noisy and annoying.

Solution:
Don't implicitly set 'modified' when a prompt-buffer is updated.
Plugins/users can still explicitly set 'modified', which will then
trigger the "E37: No write since last change" warning.
---
 runtime/lua/vim/_meta/options.lua | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

(limited to 'runtime/lua/vim/_meta/options.lua')

diff --git a/runtime/lua/vim/_meta/options.lua b/runtime/lua/vim/_meta/options.lua
index 4b532cf34e..2ae4fbc7ec 100644
--- a/runtime/lua/vim/_meta/options.lua
+++ b/runtime/lua/vim/_meta/options.lua
@@ -4565,8 +4565,11 @@ vim.bo.ma = vim.bo.modifiable
 --- result of a BufNewFile, BufRead/BufReadPost, BufWritePost,
 --- FileAppendPost or VimLeave autocommand event.  See `gzip-example` for
 --- an explanation.
---- When 'buftype' is "nowrite" or "nofile" this option may be set, but
---- will be ignored.
+--- When 'buftype' is "nowrite" or "nofile", this option may be set, but
+--- it is ignored and will not block closing the window. For "prompt"
+--- buffers, changes made to the buffer do not make it count as modified,
+--- but an explicit ":set modified" is respected and will block closing the
+--- window.
 --- Note that the text may actually be the same, e.g. 'modified' is set
 --- when using "rA" on an "A".
 ---
-- 
cgit