[vim/vim] Add scroll/scrollbar support to tabpanel (PR #19979)
mattn
Add "scroll" and "scrollbar" values to 'tabpanelopt' so a tab list that exceeds the screen height can be scrolled. "scroll" enables offset-based scrolling driven by the mouse wheel over the tabpanel area; "scrollbar" additionally draws a draggable thumb column (using the PmenuSbar/PmenuThumb highlights) that lets the user jump to an arbitrary offset.
This PR was drafted with the help of Claude Code.
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/19979
Commit Summary
- 368d030 Add scroll/scrollbar support to tabpanel
- b8ff3f1 Make tabpanel scrollbar draggable
- b43a287 Add tests for tabpanel scroll/scrollbar options
File Changes
(4 files)
- M src/mouse.c (55)
- M src/proto/tabpanel.pro (4)
- M src/tabpanel.c (223)
- M src/testdir/test_tabpanel.vim (61)
Patch Links:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#19979)Thanks, but let's hold off until #19960 is merged
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
mattn
@mattn pushed 3 commits.
- ab58541 Add scroll/scrollbar support to tabpanel
- efade9a Make tabpanel scrollbar draggable
- f067dc3 Add tests for tabpanel scroll/scrollbar options
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
mattn
mattn left a comment (vim/vim#19979)It seems that the scrolled position is not being clicked correctly. Working on fixing it.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
mattn
mattn left a comment (vim/vim#19979)I found a long-standing issue that affects %N[FuncName] click regions in 'statusline' / 'tabline' / 'tabpanel'.
Location: src/buffer.c around lines 4883–4949 in build_stl_str_hl_local():
4883: minwid = 0; 4884: maxwid = 9999; ... 4897: if (VIM_ISDIGIT(*s)) 4898: { 4899: minwid = (int)getdigits(&s); 4900: if (minwid < 0) // overflow 4901: minwid = 0; 4902: } ... 4949: minwid = (minwid > 50 ? 50 : minwid) * l;
That 50 cap has been in the tree since the Vim 7.0.001 import (commit 071d4279d6) with no comment explaining its rationale. It looks like a sanity limit for the padding width in %{minwid}{item} formats (e.g. %5l), but there is no documented reason for the specific value 50.
The problem: the same minwid variable is later used for %N[FuncName] click regions (line 5309), where N is a user-supplied identifier, not a width. So any %N[FuncName] with N > 50 gets silently clamped to 50.
Reproducer — a tabpanel / statusline with many click items:
%0[MyClick]a%[] %1[MyClick]b%[] ... %100[MyClick]z%[]
Clicks on regions 50..100 all report minwid == 50 to the callback, so they are indistinguishable.
I'd like to simply remove the 50 cap. Buffer-overflow is already guarded by p + 1 < out + outlen in the padding loop, so the cap is not a safety net — it just silently mangles values.
Does anyone see a reason to keep it, or would a more targeted fix (e.g. skip the cap only for STL_CLICKFUNC) be preferred? Any input appreciated.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.