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!
> 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
--
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
