Bug#796872: vim: E676 saving a buftype=nofile buffer

[Daniel Shahaf]

James McCoy wrote on Sat, Dec 05, 2015 at 13:08:50 -0500:
> “:write foobar” is successful in a 'nofile' buffer and that's
> essentially what “:saveas foobar” is doing, except it's also "switching"
> 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.
> 

Note that in
.
    % rm /tmp/bar
    % vim -Nu NONE /tmp/foo
    :saveas /tmp/bar
    :w /tmp/bar
.
the :w doesn't succeed; it returns E382.  However, ":w /tmp/baz" at that
point succeeds.  I suppose E382 would only happen if the filename
argument to :w is the same as the buffer's name (which the :saveas
— despite raising E676 — did set).  Therefore, this might be simply
fallout from the original bug: the failed :saveas left the buffer named
but with 'nofile' set, which is presumably a broken invariant?

> It seems like “:saveas foobar” should do one of two things:
> 
> 1.  Act like “:write foobar”, “:earlier 1f” (if buffer is modified),
>     “:edit foobar”.  This preserves whatever buffer-specific options
>     were set on the original buffer, while giving you the file foobar
>     with the modifications that had been made.
> 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.
> 

And then there are buffer-local variables, or references to the buffer
by its buffer number, both of which are preserved through :saveas in
a buftype="" buffer; it would be preferable not to break them for
'nofile' buffers if they aren't broken for regular buffers.

So that's an argument for choosing (1) over (2).  In (1), I'm not sure
whether the buffer should have 'nofile' set after the :saveas.

> It's trivial to get E382 reported, but that just doesn't seem right to
> me. :)
> 
> And in further experimentation, that also breaks other behavior.
> 

For future reference, which behaviour does it break?

Cheers,

Daniel

> Cheers,