I had the idea of creating a command that would "link" two windows together so that whatever buffer is loaded in window 1 would be in the window 5 on tab 2. The problem with this idea is that there is not a unique ID for each window, So I came up with the proof of concept unique number patch below.
But first a few question: Is this something that is implemented and I just missed the code? Is this the correct way to implement a unique window ID? Would the VIM community be open to accepting a patch if I brought this code up to standards?
Brandon
diff -r 61a7c3f01088 -r b0c51aaf018c src/eval.c --- a/src/eval.c Wed Oct 03 21:48:44 2012 +0200 +++ b/src/eval.c Thu Oct 04 14:30:52 2012 -0500 @@ -409,6 +409,9 @@ static void item_lock __ARGS((typval_T *tv, int deep, int lock)); static int tv_islocked __ARGS((typval_T *tv));
On Thursday, October 4, 2012 7:06:22 PM UTC-5, Brandon Coleman wrote:
> I had the idea of creating a command that would "link" two windows together so that whatever buffer is loaded in window 1 would be in the window 5 on tab 2. The problem with this idea is that there is not a unique ID for each window, So I came up with the proof of concept unique number patch below.
> But first a few question:
> Is this something that is implemented and I just missed the code?
> Is this the correct way to implement a unique window ID?
> Would the VIM community be open to accepting a patch if I brought this code up to standards?
Can you tell us why you think you need unique window IDs? This seems like something that could be done with a mixture of buffer-local, window-local, and/or tab-local variables or options.
At the very least, you should certainly not REPLACE the existing window number. The window number is set in a predictable way and can be used to switch to specific windows with <C-W><C-W>. Making the window number unique and static would make this impossible without first calling a function to figure out what the window number is.
On Thursday, October 4, 2012 8:35:40 PM UTC-5, Ben Fritz wrote: > On Thursday, October 4, 2012 7:06:22 PM UTC-5, Brandon Coleman wrote:
> > I had the idea of creating a command that would "link" two windows together so that whatever buffer is loaded in window 1 would be in the window 5 on tab 2. The problem with this idea is that there is not a unique ID for each window, So I came up with the proof of concept unique number patch below.
> > But first a few question:
> > Is this something that is implemented and I just missed the code?
> > Is this the correct way to implement a unique window ID?
> > Would the VIM community be open to accepting a patch if I brought this code up to standards?
> Can you tell us why you think you need unique window IDs? This seems like something that could be done with a mixture of buffer-local, window-local, and/or tab-local variables or options.
1. bufnr() is unique, but winnr() and tabpagenr() are not.. I feel that this is confusing and unexpected from the point of view of someone creating a vim script.
2. The real problem for me is that find_win_by_winnr(4,null) returns the fourth window in the current page. I can't find and work with a specific window.
> At the very least, you should certainly not REPLACE the existing window number. The window number is set in a predictable way and can be used to switch to specific windows with <C-W><C-W>. Making the window number unique and static would make this impossible without first calling a function to figure out what the window number is.
This patch should create the function uwinnr(), leaving winnr() alone.
> On Thursday, October 4, 2012 8:35:40 PM UTC-5, Ben Fritz wrote:
>> On Thursday, October 4, 2012 7:06:22 PM UTC-5, Brandon Coleman wrote:
>>> I had the idea of creating a command that would "link" two windows
>>> together so that whatever buffer is loaded in window 1 would be in
>>> the window 5 on tab 2. The problem with this idea is that there is
>>> not a unique ID for each window, So I came up with the proof of
>>> concept unique number patch below.
>>> But first a few question:
>>> Is this something that is implemented and I just missed the code?
>>> Is this the correct way to implement a unique window ID?
>>> Would the VIM community be open to accepting a patch if I brought
>>> this code up to standards?
>> Can you tell us why you think you need unique window IDs? This seems
>> like something that could be done with a mixture of buffer-local,
>> window-local, and/or tab-local variables or options.
> 1. bufnr() is unique, but winnr() and tabpagenr() are not.. I feel
> that this is confusing and unexpected from the point of view of
> someone creating a vim script.
> 2. The real problem for me is that find_win_by_winnr(4,null) returns
> the fourth window in the current page. I can't find and work with a
> specific window.
>> At the very least, you should certainly not REPLACE the existing
>> window number. The window number is set in a predictable way and can
>> be used to switch to specific windows with <C-W><C-W>. Making the
>> window number unique and static would make this impossible without
>> first calling a function to figure out what the window number is.
> This patch should create the function uwinnr(), leaving winnr() alone.
As Ben said ...
You can "tag" a window by creating a window-local variable and you can
"tag" a tab page by creating a tab-page-local variable. Both combined
result in "unique" window ID.
To find the window with this ID again, you have to go through all
windows in all tab pages (is this what you are worried about?) -- but
this is only the worst case, when the layout has changed. Of course you
will check the last remembered tabpagenr+winnr first, then all windows
in the last remembered tab page, and after that all windows in all tab
pages. It's something that a vimscript can do.
-- Andy
I'd like to know why everybody wants to further bloat Vim's core.
On Friday, October 5, 2012 3:51:49 AM UTC-5, Andy Wokula wrote: > Am 05.10.2012 10:26, schrieb Brandon Coleman:
> > On Thursday, October 4, 2012 8:35:40 PM UTC-5, Ben Fritz wrote:
> >> On Thursday, October 4, 2012 7:06:22 PM UTC-5, Brandon Coleman wrote:
> >>> I had the idea of creating a command that would "link" two windows
> >>> together so that whatever buffer is loaded in window 1 would be in
> >>> the window 5 on tab 2. The problem with this idea is that there is
> >>> not a unique ID for each window, So I came up with the proof of
> >>> concept unique number patch below.
> >>> But first a few question:
> >>> Is this something that is implemented and I just missed the code?
> >>> Is this the correct way to implement a unique window ID?
> >>> Would the VIM community be open to accepting a patch if I brought
> >>> this code up to standards?
> >> Can you tell us why you think you need unique window IDs? This seems
> >> like something that could be done with a mixture of buffer-local,
> >> window-local, and/or tab-local variables or options.
> > 1. bufnr() is unique, but winnr() and tabpagenr() are not.. I feel
> > that this is confusing and unexpected from the point of view of
> > someone creating a vim script.
> > 2. The real problem for me is that find_win_by_winnr(4,null) returns
> > the fourth window in the current page. I can't find and work with a
> > specific window.
> >> At the very least, you should certainly not REPLACE the existing
> >> window number. The window number is set in a predictable way and can
> >> be used to switch to specific windows with <C-W><C-W>. Making the
> >> window number unique and static would make this impossible without
> >> first calling a function to figure out what the window number is.
> > This patch should create the function uwinnr(), leaving winnr() alone.
> As Ben said ...
> You can "tag" a window by creating a window-local variable and you can
> "tag" a tab page by creating a tab-page-local variable. Both combined
> result in "unique" window ID.
> To find the window with this ID again, you have to go through all
> windows in all tab pages (is this what you are worried about?) -- but
> this is only the worst case, when the layout has changed. Of course you
> will check the last remembered tabpagenr+winnr first, then all windows
> in the last remembered tab page, and after that all windows in all tab
> pages. It's something that a vimscript can do.
> --
> Andy
> I'd like to know why everybody wants to further bloat Vim's core.
It seems like there should be a standard way of finding a window/buffer/tabpage without every script creating a new way of looping through windows. Having said that, I can understand the need to keep bloat out of the project.
