On Wednesday, August 8, 2012 5:34:00 AM UTC-7, Bram Moolenaar wrote: > William Bowers wrote: > > [Somehow empty lines get inserted somewhere...] > [also, when replying, please remove the footer] > > > > > I've included a patch that adds a setting that defines which tab to > > > > select after a tab is closed. The setting is 'tabcloseleft' or 'tcl' > > > > (maybe not the best name, but it's the best I could come up with), and > > > > when enabled causes the previous tab to be selected, as opposed to the > > > > next tab (the current functionality). The setting is off by default so > > > > nothing changes for users that don't know about it. > > > > > > > > Here is an example of what it does. Let's say I have the following tabs: > > > > > > > > one [two] three > > > > > > > > Tab 'two' is selected (denoted by []). Currently, if I close that tab, > > > > tab 'three' will be selected: > > > > > > > > one [three] > > > > > > > > With ':set tabcloseleft', tab 'one' will be selected: > > > > > > > > [one] three > > > > > > > > I've tested closing on the first tab, the last tab and every tab in > > > > between. Also, this works regardless of how the tab is closed > > > > (:tabclose, closing the last window in the tab, etc). > > > > > > > > > > > > This is my first patch, so apologies if I've missed some critical > > > > information in this submission, forgot to modify or add something in > > > > code that's necessary for new settings, overlooked previous attempts > > > > at adding this same feature or missed the ball completely on where you > > > > all are trying to take vim. I believe this to be in line with vim > > > > (customizable but fast and unobtrusive), but let me know if it's not, > > > > and if there is anything I can do to fix it. > > > > > > Do we have anything similar for windows? I don't think so, when closing > > > a window the focus goes to the next one (so that the current window > > > index remains the same), unless closing the last one. > > > > > > I think closing windows and tabs should work in a similar way. > > > > That's a great point. I believe that functionality exists with > > 'splitright' and 'splitbelow': > > > > /* > > * Find out which frame is going to get the freed up space when "win" is > > * closed. > > * if 'splitbelow'/'splitleft' the space goes to the window above/left. > > * if 'nosplitbelow'/'nosplitleft' the space goes to the window > > below/right. > > * This makes opening a window and closing it immediately keep the same > > window > > * layout. > > */ > > static frame_T * > > win_altframe(win, tp) > > > > Testing seems to confirm that. If 'splitright' is on, closing a > > vertically-split window opens the window to the left. If 'splitbelow' > > is on, closing a horizontally-split window opens the window above. > > > > By the way, the comment to win_alframe references 'splitleft', which > > isn't actually a setting. Do you prefer that patches only deal with > > one issue, or should I fix the comment in this patch? > > Yes, keep patches focused on one problem. Nice catch, 'splitleft' vs. > 'splitright'. > > So, we could have a 'tableft' option, I suppose. No need for > 'tabbelow'. Or should it be 'tabsplitleft'? I prefer short names when > it's not confusing.
I'm not quite sure why those extra lines were getting added in my replies. I've manually removed them. I agree on having short names. As short as possible while capturing intent. 'tableft' could work. It seems as though if there were any options in the future having to do with tabs and direction, this might get confusing. 'tabsplitleft' seems a little confusing because we're not really splitting tabs like we do windows. I went with 'tabcloseleft' to tie it to the ':tabclose' command. -- 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
