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

[James McCoy]

On Sat, Dec 05, 2015 at 09:57:27AM +0000, Daniel Shahaf wrote:
> James McCoy wrote on Fri, Dec 04, 2015 at 23:33:22 -0500:
> > On Tue, Aug 25, 2015 at 08:57:27AM +0000, Daniel Shahaf wrote:
> > >    * What was the outcome of this action?
> > > 
> > > "E676: No matching autocommands for acwrite buffer"
> > > 
> > >    * What outcome did you expect instead?
> > > 
> > > "E382: Cannot write, 'buftype' option is set"
> > 
> > Hmm.  I think :saveas should be successful here, but the 'nofile'
> > setting should be transfered to the alternate buffer that gets created.
> > “:saveas foo” should really act like a short-cut for “:w foo” and “:e
> > foo”.

Hmm, that's not the mail I meant to send out ... Oh, I was messing
around with :saveas in Vim while composing the mail and continued
editing in the wrong buffer.

> I neglected to mention that ":w foobar" at that point gives E382; that's
> why I named that particular error as "what I expected to see".  So, more
> explicitly, what I "expected" was that :saveas would fail the same way
> :w fails at that point.

Yeah, my intended mail mentioned that.  I'll just include that below for
my final thoughts:

“: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.

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.

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.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jamessan at debian.org>