On 11/08/12 18:15, Andrew Pimlott wrote:
Excerpts from Tony Mechelynck's message of Sat Aug 11 08:32:04 -0700 2012:
Well, your ":new" command does change to a new buffer, something which
is explicitly documented as forbidden because "it will cause problems".
So you were taking advantage of a bug (the bug, which still exists,
being that issuing :new in a BufUnload autocommand doesn't give an
error). At some point the unsupported behaviour of the command you were
abusing changed. Well, you will just have to find something else.
Yes, that's what I'm looking for. :-) I don't want to depend on
undefined behavior. On the other hand, maybe it is not that hard to
change vim to allow this....
By the way, even this crashes when I run my example:
set nohidden
au! BufUnload * call Unload()
function Unload()
bunload 2
endfunction
Note it neither changes buffers nor changes the current buffer, so it is
not doing anything explicitly forbidden. But this crashed in older
versions of vim too, which is why I came up with the "new ... q"
approach. I would be just as happy if the above worked!
It changes buffers if you happen to execute it while buffer 2 is current.
Maybe (untested) set a variable to 0 in your vimrc, set it to the buffer
number in the BufUnload autocommand, test it in, let's say, an
autocommand for CursorHold, CursorHoldI, CursorMoved and CursorMovedI,
and if found in the correct range, unload all _other_ buffers in your
buffer set.
Interesting idea.... I think that before going that route, I would just
map all of the quitting or buffer closing commands.
Andrew
Best regards,
Tony.
--
A pretty young maiden from France
Decided she'd "just take a chance."
She let herself go
For an hour or so
And now all her sisters are aunts.
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
