Ben Fritz wrote:
> On Jun 26, 4:02=A0pm, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > Ben Fritz wrote: > > > See this thread for a full discussion and examples: > > >http://groups.google.com/group/vim_use/browse_thread/thread/1178b1878... > > > > > Summary: > > > > > :split with no arguments does not fire a BufWinEnter event > > > :split with _any_ argument _does_ fire a BufWinEnter event > > > (even :split %) > > > > Because the buffer is loaded with the file specified by the argument. > > > > > :split with no arguments on a window with a modified buffer works fine > > > :split % in a modified buffer gives E37 > > > > Because you are trying to reload while there are changes. > > > > > :split file.b in a modified buffer (file.b is unmodified) works fine > > > :split file.a in an unmodified buffer (file.a is modified) works fine > > > > Because this uses the existing buffer. > > > > > I think that the behavior of :split should be fixed to be consistent > > > with and without arguments, but at the very least the help docs should > > > mention/explain this strange behavior. > > > > It works the way it works. =A0What documentation should be updated? > > I think that the documentation should note that :split with no > arguments does not load a buffer, and therefore will not fire any > events. BufWinEnter's help text should be updated, because it states > that it will fire when "a buffer already visible in a window is also > displayed in another window," which is exactly what :split does. That > will do for the BufWinEnter inconsistency, I suppose, although it is > quite annoying to need to work around. What I have now: BufWinEnter After a buffer is displayed in a window. This can be when the buffer is loaded (after processing the modelines) or when a hidden buffer is displayed in a window (and is no longer hidden). Does not happen for |:split| without arguments, since you keep editing the same buffer, or ":split" with a file that's already open in a window, because it re-uses an existing buffer. But it does happen for a ":split" with the name of the current buffer, since it reloads that buffer. > As for the errors, I do not understand at all why :split would ever > cause E37. I am not trying to reload, as evidenced by this: > > gvim -N -u NONE file1 > (edit file 1) > :split file2 > (edit file 2) > :split file1 > (This does not cause an error, even though both the file you are > opening a new window for and the file you are opening the new window > from are modified. Vim successfully re-uses the modified buffer in the > new window, and has no problem trying to "reload" any modified > buffers.) > :split file1 > (This causes an error, even though there are already two windows open > with file1, each of which is looking at the same (modified) buffer. > Why can't :split with an argument re-use a buffer when it is called > from within that buffer? It can re-use a buffer if it is called from a > different buffer!) When using ":split" it simply splits. If you add "%" or the current file name you apparently wanted something else, so it reloads the buffer. > :help E37 says: > > You are trying to |abandon| a file that has changes. Vim protects you > from > losing your work. You can either write the changed file with ":w", > or, if you > are sure, |abandon| it anyway, and lose all the changes. > > Using :split to open a new window, containing the _same_ modified > buffer, is certainly not abandoning a file that has changes. If it > were, you should also get an E37 if you :split to another file, but > you do not. You only get E37 when you :split with and argument that > opens the same buffer you are already in. > > This, I am fairly certain, is a bug. Nope. Bit unexpected maybe. -- A meeting is an event at which the minutes are kept and the hours are lost. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ download, build and distribute -- http://www.A-A-P.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
