Fun with buffer renaming

1

Renaming the debug buffer

I just learned (in #3243) that the :rename-buffer command will actually switch which file on disk a buffer represents. So of course, I immediately tried:

kak -n ~/.bashrc
:buffer *debug*
:rename-buffer *blorp*
:buffer .bashrc
:rename-buffer *debug*
:echo -debug hello debug buffer

And sure enough, I get a message appended to the end of my bashrc and the file is marked modified. However, If I hit u to undo the change, I get an error “buffer is read-only” (which is also appended to the buffer). Also, because the buffer is marked modified, I can’t quit without writing it (or using :q!).

Bonus fun: Kakoune will not let you edit a file named *debug*, but you can edit a file named ./*debug*. Once you switch away from it, though, you can’t switch back to it with :buffer unless you delete the regular *debug* buffer first. :buffer-next works fine, luckily.

Renaming to a new file

The next thing I tried was renaming a buffer to a wholly new name:

cd $(mktemp -d)
kak -n foo

(this is a new file, so “new file” appears in the status line)

:w

(this is no longer a new file, so “new file” disappears from the status line)

:rename-buffer bar

(this is now a new file again, but “new file” does not reappear - filed as #3244)

Renaming to an existing file

The last thing I tried was renaming a buffer to a file that already exists:

echo "foo" > foo
echo "bar" > bar
kak -n foo
:rename-buffer bar

From my previous experiment I assumed Kakoune did not check the new path when renaming a buffer, so I assumed this would just change the name in the status bar and nothing else. However, the contents of the buffer are different from the corresponding file on disk as a result of my changes, so I hoped that Kakoune would light up the “modified file” indicator in the status line.

Instead, Kakoune displays the “reload ‘bar’? ‘bar’ was modified externally” dialog, which surprised me greatly. “bar” has not been modified by something outside of Kakoune, this change is purely Kakoune-internal. But I’ve never hit this behaviour “in the wild”, so maybe if my workflow actually included this scenario, this is exactly what I’d want? I’m not sure, so I haven’t filed an issue.

2 Likes