Anton Lindqvist wrote:

> > > Hi,
> > > This patch adds an optional second argument to the bufwinnr function
> > > which if present returns all windows associated with the given buffer
> > > across all tabs. This is useful in order to determine if a buffer is
> > > present in several windows. I'm currently using this patch in order to
> > > get backspace to behave accordingly: if the current buffer is present in
> > > other windows than the current one, close the window, otherwise wipe the
> > > current buffer.
> > > 
> > >   nnoremap <BS> :call BufferClose()<CR>
> > >   func BufferClose()
> > >     if len(bufwinnr('%', 1)) > 1
> > >       wincmd c
> > >     else
> > >       bwipe
> > >     endif
> > >   endfunc
> > > 
> > > I didn't end up using the FOR_ALL_TAB_WINDOWS macro since I needed to
> > > reset winnr and increment tabnr in the outer loop.
> > 
> > Thanks.  Seems useful.
> > 
> > I have been thinking of adding a unique window number.  Some plugins
> > have problems finding the right window after splitting and closing
> > windows.  The current window number changes then, thus it requires
> > looping over windows to find the right window.  Netrw had a bug related
> > to this.
> > 
> >     getwinid()           ID of current winow
> >     getwinnr({id})       window nr of {id} or -1 if not open
> >     gettabnr({id})       tab page nr of {id} or -1 if not open
> >     gotowin({id})
> > 
> > I wonder how this bufwinnr() change fits in.
> 
> With the addition of the unique window IDs the returned tabnr and winnr
> from bufwinnr() can be used to retrieve the window ID using the new
> win_getid() function. Once the window ID is obtain all the new functions
> can be utilized.

Looking at this again, I realize that when adding the argument the
return type changes from a number to a list.  I know that Vim is not
fixing the return type, but changing the return type based on an
argument can cause problems.  I think we should go in the direction of a
predictable return type.  I know, it's already violated by several
existing functions.  But perhaps it's worth going in that direction.
After all, Vim script keeps getting more complicated, we should at least
try to make it a bit simpler when we can.

-- 
hundred-and-one symptoms of being an internet addict:
234. You started college as a chemistry major, and walk out four years
     later as an Internet provider.

 /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Raspunde prin e-mail lui