From f7e3441698a4621bec0d7c14eb45303753ffbead Mon Sep 17 00:00:00 2001 From: Gabriel Schneider Date: Tue, 29 Sep 2026 08:09:08 -0300 Subject: A rename alone does not make a pane dirty Any rename marked the pane dirty (saved revision one back), while the guards ask only whether its text was ever edited: /index said dirty for a pane Exit let go without asking. The name is no edit now, so /index, the guards and Restore agree; Save writes under the new name all the same. Co-Authored-By: Claude Opus 5.5 --- docs/fs.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'docs/fs.md') diff --git a/docs/fs.md b/docs/fs.md index bcf5dd5b..df1b128c 100644 --- a/docs/fs.md +++ b/docs/fs.md @@ -504,7 +504,10 @@ selection, and leaves `look` reading back empty. `/pane//name` reads the pane's file name (a terminal's directory) and writing it renames the buffer; a relative name resolves against the pane's -directory. The write is the name and its newline, nothing trimmed: a blank +directory. A name alone is no edit: the pane's `dirty` stays what its text made it +(a renamed clean file is still 0, and nothing asks about it at Exit, +Restore or Del, which ask only about text edited), and `Save` writes it +under the new name all the same. The write is the name and its newline, nothing trimmed: a blank inside a name is taken (`two words.zig`), but one at either end, or a control character, is refused, `bad character in file name` (EINVAL), as acme refuses a blank (xfid.c:650), rather than quietly cut off. `body` appends on write and replaces on truncating open. A -- cgit v1.3