Bug with tab drop and vertical splits?
hsitz
a vertical split in the tab where the target file is. Using Vim73.
Here are steps to reproduce what I'm seeing, which seems like it can't
be desired behavior:
1. edit mynewfile
2. vsplit
3. tab drop mynewfile
Instead of moving to window that has mynewfile (or even staying in
current window), the tab drop command opens up a new tab with
mynewfile. Subsequently issuing tab drop on the new tabs will open
yet another tab with mynewfile, despite fact that each of those tabs
has only single window.
Behavior is as expected when the split in the windows is horizontal:
tab drop stays on current tab.
Am I doing something wrong, or somehow misunderstanding 'tab drop'?
-- Herb
Ben Fritz
On Nov 17, 10:40 pm, hsitz <hes...@gmail.com> wrote:
> Unless I'm misunderstanding something, tab drop is broken when there's
> a vertical split in the tab where the target file is. Using Vim73.
> Here are steps to reproduce what I'm seeing, which seems like it can't
> be desired behavior:
>
> 1. edit mynewfile
> 2. vsplit
> 3. tab drop mynewfile
>
> Instead of moving to window that has mynewfile (or even staying in
> current window), the tab drop command opens up a new tab with
> mynewfile. Subsequently issuing tab drop on the new tabs will open
> yet another tab with mynewfile, despite fact that each of those tabs
> has only single window.
>
I can reproduce this in 7.3.353 (Vim without Cream) build on Windows
XP 64-bit.
However, additionally, if the current buffer is the empty one from Vim
startup, no new tab is opened; :tab drop just opens it in the current
window.
Also, using my normal Vim config, but not when using gvim -N -u NONE -
i NONE, if I used vnew instead of vsp, the correct tab was jumped to
but the file was loaded in the empty buffer instead of the cursor
being positioned on the existing window.
> Behavior is as expected when the split in the windows is horizontal:
> tab drop stays on current tab.
>
I don't see this, with gvim -N -u NONE -i NONE, or with my normal Vim
config. Horizontal splits also break. But with my normal Vim config,
if I use :new instead of :sp, and if I move the :new window to the
bottom, then Vim correctly jumps to the correct buffer. However, the
window jumped to by :tab drop (with the correct buffer) has swapped
positions with this :new window, so that it is always on the bottom.
hsitz
Ben --
Thanks yes, not sure how I missed this. Horizontal splits have same
problems for me, Vim7.3.277 32bit running on win7/64.
-- Herb
hsitz
>
> Thanks yes, not sure how I missed this. Horizontal splits have same
> problems for me, Vim7.3.277 32bit running on win7/64.
>
I think I see how I missed that now. There are other problems besides
the ones that have been described, and one is specific to vertical
splits. Here are some examples:
Case 1:
==========
Case 1a: One tab with horizontal split between one file, fileone.txt
Second tab with one window on a second file,
filetwo.txt
When cursor is in second tab and issuing command 'tab
drop fileone.txt', a new tab is opened for fileone.txt (instead of
postioning it to already existing tab page).
Case 1b: This issue does not exist if the horizontal split on first
tab is of two different files. In that case issuing 'tab drop' from a
different tab will find the files on existing tab correctly.
Case 2:
==========
Variation of case 1 with vertical splits.
Case 2a: Same problem when there are two vertical splits, each showing
same file.
Case 2b: But, problem exists with vertical splits even when they hold
two different files. Issuing 'tab drop' on a different tab will not
find an existing file in a vertical split.
-- Herb
Benjamin Fritz
> Case 1b: This issue does not exist if the horizontal split on first
> tab is of two different files. In that case issuing 'tab drop' from a
> different tab will find the files on existing tab correctly.
>
>
Do your windows also get rearranged here? Try with the "tab drop" file
in the top window. For me, it was always moved to the bottom window.
But I was using an empty buffer, not a second file, for my other
split.
sc
this looks very much like an issue tony pointed out in 2009:
<quote todo.txt>
":tab drop filename" doesn't work nicely when "filename" is open
in a window
in another tab. (Tony Mechelynck, 2009 Feb 13)
</quote todo.txt>
sc
Ben Fritz
in this thread:
http://groups.google.com/group/vim_dev/browse_thread/thread/3b997c95f04813f9/682afea074c4871c
However, the failure of :tab drop to jump to an existing tab, if the
file is already in a buffer in another tab with vertically split
windows, does not appear in that thread. I'd be interested to see,
however, if the same behavior exists in the old version mentioned in
the thread. And the issues may be related somehow.
hsitz
I'm not seeing any rearrangment in this case. Window layout stays the
same.
But I just discovered some more tab drop weirdness:
I have a few tabs open, each of them holding a fairly large document
that is folded using foldexpr. With the way Vim folding works, there
is a lag each time a file is loaded into the window as the foldexpr
assigns foldlevels to each line. Once loaded in a window however, you
can move between windows (even on different tabs) without retriggering
the foldexpr run on the buffer. This is main reason I use tabs, since
if I keep the documents open in a window on a tab I can quickly move
between windows/tabs without lags for foldexpr, whereas if I were
continually loading buffers into same window I would have several
seconds (or more) slowdown at each change.
The weirdness comes in when I try to do a 'tab drop' that should go to
a split-windowed-tab, which fails and instead opens a new tab. In
that case the fold status (or window load status?) of the window in
the tab I'm in when I issue the 'todo drop' gets partially reset, so
that if I try to 'tab drop' back to it the foldexpr/window load stuff
runs again. I think it's okay (i.e., no lag) if I go back to that tab/
window by means other than a 'tab drop'.
Also, the window load status of the windows in the split window (the
tab with the window that should have been found by 'tab drop') also
seems to get reset. So next time I visit that tab (always by means
other than 'tab drop' b/c tab drop doesn't find this split-window/tab)
it goes through lag of window-reload process.
I'm not positive above is absolutely accurate, but there is definitely
something strange going on with pre-existing windows going through a
reload process.
All of this is happening for me in context of a plugin that
programmatically issues 'tab drops' to go between windows/tabs (and
load new files into new tabs). 'tab drop' seems natural way to do
it, but I'm having to rewrite and not rely on 'tab drop'.
-- Herb