[vim/vim] ":saveas foo" in a buftype=nofile fails, and with a misleading error (Issue #11171)
James McCoy
Steps to reproduce
- vim --clean
- ":set buftype=nofile"
- ":saveas foo"
- Get "E676: No matching autocommands for acwrite buffer" error, when the buffer is 'nofile', not 'acwrite'
Expected behaviour
It's unclear what should be expected.
“:write foo” is successful in a 'nofile' buffer and that's essentially what “:saveas foo” is doing, from a user perspective. In addition, it also "switches" you to that file. The implementation detail of just renaming the current buffer to the new filename is what seems to lead to this problem.
However, it could also be argued that the command should emit E382 since it's a nofile buffer.
If the use of :saveas is deemed acceptable, it seems like “:saveas foo” should do one of two things:
- Act like “:write foo”, “:earlier 1f” (if buffer is modified), “:edit foo”. This preserves whatever buffer-specific options were set on the original buffer, while giving you the file foo with the modifications that have been made.
- Move the value of 'buftype' (and possibly other options) to the newly created alternate buffer, which now represents the same "file" the original buffer was displaying, sans the unsaved modifications.
However, 1 would has user visible side effects and is a change in behavior.
2 appears at first blush to be easy to implement, but the trouble is that the alternate buffer isn't loaded until the user switches to it.
Any options set on it before then will be wiped out when it actually gets loaded, last I checked.
Version of Vim
9.1.0242
Environment
Debian
Logs and stack traces
No response
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Closed #11171 as completed via 500a1f9.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> ### Steps to reproduce
>
> 1. vim --clean
> 2. ":set buftype=nofile"
> 3. ":saveas foo"
> 4. Get "E676: No matching autocommands for acwrite buffer" error, when the buffer is 'nofile', not 'acwrite'
>
> ### Expected behaviour
>
> It's unclear what _should_ be expected.
>
> “:write foo” is successful in a 'nofile' buffer and that's essentially
> what “:saveas foo” is doing, from a user perspective. In addition, it
> also "switches" you to that file. The implementation detail of just
> renaming the current buffer to the new filename is what seems to lead
> to this problem.
>
> However, it could also be argued that the command should emit E382
> since it's a nofile buffer.
everything. What you are thinking of is ":write foo | edit foo". That
is different, as it creates a new buffer.
> If the use of :saveas is deemed acceptable, it seems like “:saveas
> foo” should do one of two things:
>
> “:edit foo”. This preserves whatever buffer-specific options were set
> on the original buffer, while giving you the file foo with the
> modifications that have been made.
same buffer. When using a different buffer in some cases that gets
confusing.
> 2. Move the value of 'buftype' (and possibly other options) to the
> newly created alternate buffer, which now represents the same "file"
> the original buffer was displaying, sans the unsaved modifications.
>
> However, 1 would has user visible side effects and is a change in
> behavior.
> 2 appears at first blush to be easy to implement, but the trouble is
> that the alternate buffer isn't loaded until the user switches to it.
>
> Any options set on it before then will be wiped out when it actually
> gets loaded, last I checked.
--
Contrary to popular belief, Unix is user friendly.
It just happens to be selective about who it makes friends with.
-- Dave Parnas
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.