fix(prompt): don't implicitly set 'modified' #38118

Problem:
In aec3d7915c 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.
This commit is contained in:
Willaaaaaaa
2026-03-12 02:16:35 +08:00
committed by GitHub
parent f168d215cf
commit 689a149b08
6 changed files with 85 additions and 46 deletions

View File

@@ -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".
---