Closed jordwalke closed 6 years ago
This is probably a bug. Wintabs currently doesn't do any truncation - it always tries to keep whole tabs. I'd like to fix it asap.
Currently I know it has a conflict with (strangely) a javascript syntax plugin. If you are using pangloss/vim-javascript
, you can likely resolve this by point the plugin commit to '4839870f29807035541b658c1c835797c944290d'
. I'm still investigate the cause and hopefully can fix it soon.
If this conflict is not the issue, it's an unknown bug to me. Please help me diagnose by producing a minimal repro vimrc (only your colorscheme, wintabs, and their configurations).
What if there's no room for the whole tab content (like in the screenshot)? What is the desired behavior? (Testing pangloss plugin now).
I tested without the JS plugin and it still has the same behavior. It will take me some time to get a minimal vimrc setup for testing. I really wish there was an easy way for me to do that.
" This plugins is actually more of what Sublime/Atom do for split/tab
" management.
Plug 'zefei/vim-wintabs'
" Displaying on statusline is supperior as it allows ability to see all open
" files for each window split.
let g:wintabs_display = 'statusline'
let g:wintabs_autoclose_vimtab = 1
let g:wintabs_autoclose = 2
" Only available in new version.
let g:wintabs_autoclose_vim = 1
let g:wintabs_ui_active_higroup = 'TabLineSel'
let g:wintabs_switchbuf = 'useopen,usetab,vsplit'
" Wintabs requires buffers to be hidden to avoid the issue of Opening a new
" "tab" with :e, when there are unsaved changes to the current buffer.
set hidden
let intertabSpace= ' '
let activeWinTabChar = '▎'
" This must be different to distinguish.
let activeVimTabChar = '▍'
let g:wintabs_ui_sep_leftmost=intertabSpace
let g:wintabs_ui_sep_inbetween=intertabSpace
let g:wintabs_ui_active_right=intertabSpace
let g:wintabs_ui_active_left=activeWinTabChar
let g:wintabs_ui_sep_rightmost=intertabSpace
let g:wintabs_ui_modified=' ◎'
let g:wintabs_ignored_filetypes=[]
" Annotating the active vimtab makes it always available for detection
let g:wintabs_ui_active_vimtab_left=activeVimTabChar
let g:wintabs_ui_active_vimtab_right=intertabSpace
I understand if you don't have time to look into it right now until I get that minimal vim repro, but you might be able to easily try those settings above for WinTabs to see if you can reproduce. To repro with those settings, you can edit multiple files in one split, then shrink it so that the active tab collapses. If you can't repro, I'd be curious to see a screenshot of what you experience.
BTW: I sent you an email as well (unrelated).
Oh, I just realized you are using statusline. Do you use the entire statusline for wintabs or you manually set statusline? Currently wintabs assume to use the entirety of statusline, because of limitations of vim (like truncation in this case).
If you are using the entire statusline, the cause of that might be the unicode chars you used in the configuration. This is a vim limitation that len(unicode_char) != len(spaces_needed_for_that_char), which results in a miscalculation of tabs layout. This is a very hard issue to solve.
If you aren't using the entire statusline, the issue is then wintabs cannot rely on vim's statusline truncation and must do the statusline layout itself. I made this possible in my previous buftabs plugin, but changed to assume the usage of entire statusline in wintabs, because the configuration needed to accomplish that is pretty confusing. It requires you providing a fixed number of chars of statusline that you want to use for non-wintabs purpose. If you want to do this, I can change some code and probably provide you some private configuration to do so.
I personally use tabline to display wintabs although I used to use statusline, because nowadays I often find the statusline estate to be more important for other stuff.
I am currently using statusline (using wintabs' built in status line setting let g:wintabs_display = 'statusline'
). I also disabled all my custom characters, and the statusline truncation still occured.
I don't think I'm taking up the "whole status line". I just have it configured however Wintabs renders by default when you do let g:wintabs_display = 'statusline'
.
I would love to use the tabline
, but the problem is that when using the tabline, Wintabs doesn't allow individual tabs per split to be visible for all splits simultaneously (like modern editors such as Atom). (Or at least I don't know how to accomplish it).
This is a screenshot of my setup: I really enjoy airline, but since statusline
is the only way to get wintabs to show tabs per split, I had to show wintabs in the statusline, and then show airline in the tabline (with a custom fork of airline). It looks great, and feels really great, except I would much rather have them such that airline is at the bottom, and tabs are at the top.
Now, to swap the top/bottom positions like that is entirely separate from this truncation issue, however, if we can somehow accomplish the tabline rendering of wintabs, then the truncation issue might just go away anyways.
(My Setup)
I will create another issue to swap the tabline / statusline while still having the good statusline features, as it is a separate issue.
Ok, this is enough info for me to understand the bug. Thanks! I'll make a fix soon.
@jordwalke I just pushed a fix for this issue. However, you'll probably need to change wintab separators to ascii chars to get everything fixed. Unicode support is still a pretty far away goal because the effort it requires. It's very hard to truncate unicodes correctly when byte length, character count and displayed length are all different and used in calculation.
Awesome, looking forward to trying it.
Latest release seems to be improved. This is the truncation I observe.
On second thought, maybe not. Here's how I see it truncate in other cases, which I like much better:
Why is it not truncating in the same manner in the previous screenshot I shared?
Your first screenshot shows the behavior when the window width is large enough to show the active buffer. I don't do ellipsis for this case because the truncated buffer name often can only get very few spaces, and we care less about those buffers. The second screenshot shows the behavior when window width is too small to even show the active buffer, in this case I do ellipsis to show active buffer as much as possible.
Please try this without the leading |
char or use some ascii char instead. Both of your screenshots show some unused space at the right end of the window because wintabs still can't handle display width of unicode chars correctly (this is unlikely to be fixed because unicode layout is just too complex).
This is what it looks like with my setup:
I tried with ascii and nothing really changed. I don't have any issue with the truncation threshold (due to string length), the thing I'm pointing out is the <
character instead of ellipse. Is it possible to customize the <
character as well to be the ellipse, or is that Vim's own internal truncation happening?
You can use g:wintabs_uiarrow[left|right] to set the arrow character, it's a private setting I decided not to put in the doc: https://github.com/zefei/vim-wintabs/blob/master/plugin/wintabs.vim#L86
Great thanks!
Closing as this seems to be resolved.
This sequence of screenshots shows what happens when truncating tabs.
There's one (perhaps, bug?) issue with truncation: that is, when shrinking, the highlighting colorscheme (if active) is not applied, and left separator disappears.
I'm thinking that the following might be good improvements:
<l#
comes from. If configurable, I would likely set the truncation token to the single character…
ellipsis, and I might even prefer to have the ellipsis after the left separator, so in my case it might look like:|…ckage.json
, where|
is the left separator. I realize that the left separator won't always look great when truncated, but it does in my specific setup.