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. -- How do I set the laser printer to stun? /// 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
