Custom tabline - Non-gui vim.
Patrick Gen-Paul
functionalities that I was looking for, such as display the tab page
number, or show only the focused file's basefile instead of the full
path, but all I get is a blank line on line one, followed by a white
line across the entire screen.
I switched color schemes, tried with the vim -u flag, logged in as a
different user.. no joy.
When I issue :call commands pointing to TabLineSet_verbose_rotate(), it
displays the "Tabline options" that it sets, but the corresponding
labels are invisible.
Is anyone successfully using this plugin in non-gui vim?
Thanks,
Gen-Paul.
Tony Mechelynck
I'm not using that plugin, but I'm using a text-style tabline in both
Console Vim and gvim.
One example of how to set it can be found under ":help setting-tabline".
What I use is slightly different, as follows (uncomment the maps at the
bottom if you like them):
if exists("+guioptions")
set go-=a go-=e go+=tc
" remove a no autoselect to * register
" remove e always use text-style tabs
" add t include tearoff menu items if possible
" add c avoid popup dialogs for small choices
endif
" define our text-style tabline
" this is adapted (with some enhancements) from the example
" at :help setting-tabline
if exists("+showtabline")
function MyTabLine()
let s = ''
let t = tabpagenr()
let i = 1
while i <= tabpagenr('$')
let buflist = tabpagebuflist(i)
let winnr = tabpagewinnr(i)
let s .= '%' . i . 'T'
let s .= (i == t ? '%1*' : '%2*')
let s .= ' '
let s .= i . ':'
let s .= winnr . '/' . tabpagewinnr(i,'$')
let s .= ' %*'
let s .= (i == t ? '%#TabLineSel#' : '%#TabLine#')
let file = bufname(buflist[winnr - 1])
let file = fnamemodify(file, ':p:t')
if file == ''
let file = '[No Name]'
endif
let s .= file
let i = i + 1
endwhile
let s .= '%T%#TabLineFill#%='
let s .= (tabpagenr('$') > 1 ? '%999XX' : 'X')
return s
endfunction
set stal=2
set tabline=%!MyTabLine()
" map <F10> :tabnext<CR>
" map! <F10> <C-O>:tabnext<CR>
" map <S-F10> :tabprev<CR>
" map! <S-F10> <C-O>:tabprev<CR>
endif
Patrick Gen-Paul
Thanks!
[..]
> I'm not using that plugin, but I'm using a text-style tabline in both
> Console Vim and gvim.
I really needed the tab number, because I function mostly with a single
vim session that opens when I start X, and by the time I get to garbage
collection time, it can easily have some ten tabs open or more.. So I
had to count the tabs so as to be able to issue {count}gt's or else
issue a ":tabs" :-(
Since the author of the plugin would not stand up and be counted, I
actually proceeded to write my own last night :-)
> One example of how to set it can be found under ":help setting-tabline".
> What I use is slightly different, as follows (uncomment the maps at the
> bottom if you like them):
[..]
I tried it and it's quite similar to the one I wrote, although yours is
structured differently - and uses programming syntax I didn't even know
existed in the vim scripting language such as "a ? b : c" as a shorthand
for "if-then-else".
I blindly followed the :h setting-tabline example, basically testing
every statement from the command line and with the online help in front
of me till I could get it to do what I wanted. :-(
Interestingly, both our versions have similar (minor) bugs:
1. In your version, there should be a space between the last tab and
this mysterious "X" to the far right of the tab line. Otherwise the X
looks like it's part of the file name. I have a similar problem that I
had failed to notice where I have three spaces instead of one - thus
wasting space.
2. When opening more tabs than the width of the display can accommodate,
if you issue a "1"+"gt" you do move back the focus to tab #1, but the
beginning of the tab line is not displayed, which means that you may be
displaying part of tab #4 etc. and you are not able to see which tab you
are on, since the tab that should be highlighted is not visible. All you
see is a "<" in column one that indicates that there are more tabs to
the left but I haven't found the way to display them. Maybe something to
do with that right-justified final "X" - I'm curious what that "X" is
for.. I don't use a mouse, so maybe that's why it does nothing that I
can see. Maybe the "<" is clickable?
On the other hand, we both fixed another minor bug with vim's default
tab line, where the space immediately following the file name is
highlighted, which doesn't look right.
I'm still debating the usefulness of having the &modified flag
materialize in my version. Kinda of clutters the display and I'm not
really sure I need that, so I may remove it - or possibly remove the
number of windows in a tab - made the coding more fun but I don't think
I really care if a tab has three windows open rather than four.
I'm curious as to why the tab line was implemented this way rather than
something like the status line. I'm not complaining, mind you, writing a
simple function was definitely a fun and useful experience - vim is an
editor for programmers, not a word processor, right ;-) - but I'm not
sure why it was not done the same way for the terminal as for the gui -
cf. :h set guitablabel..?
What would be possible then is that since users normally display the
same data in all their tabs, provided they had been implemented, you
could simply refer to a list of items similar to the ones defined in ":h
'statusline'".
To clarify, the help file could look a bit like:
'tablabel'
...
item meaning
N tab number
n number of windows in tab
F full name of file in current window
f base name of file in current window
m tab has unsaved buffers - cf. &modified
etc.
Anyway, attaching what I came up with, if you care to take a peek..
Hopefully it's I'm not violating the list's policy.
It's fenc=utf8 & tw=80 so I'm not sure I could paste it in this message.
It has lots of useless comments that I had to put in there for my own
sake, just to keep track of what I was doing. :-)
Oh, one other thing.. I often toggle between two tabs say, that may not
be adjacent.. Does vim keep track of the previous tab you were on so
that I could switch back and forth between tab-x and tab-y..?
I didn't see anything in the manual.
Thanks,
Gen-Paul.
Tony Mechelynck
> Tony Mechelynck wrote:
>
> Thanks!
>
> [..]
>
>> I'm not using that plugin, but I'm using a text-style tabline in both
>> Console Vim and gvim.
>
> I really needed the tab number, because I function mostly with a single
> vim session that opens when I start X, and by the time I get to garbage
> collection time, it can easily have some ten tabs open or more.. So I
> had to count the tabs so as to be able to issue {count}gt's or else
> issue a ":tabs" :-(
see :help tabpagenr()
>
> Since the author of the plugin would not stand up and be counted, I
> actually proceeded to write my own last night :-)
>
>> One example of how to set it can be found under ":help setting-tabline".
>> What I use is slightly different, as follows (uncomment the maps at the
>> bottom if you like them):
>
> [..]
>
> I tried it and it's quite similar to the one I wrote, although yours is
> structured differently - and uses programming syntax I didn't even know
> existed in the vim scripting language such as "a ? b : c" as a shorthand
> for "if-then-else".
>
> I blindly followed the :h setting-tabline example, basically testing
> every statement from the command line and with the online help in front
> of me till I could get it to do what I wanted. :-(
>
> Interestingly, both our versions have similar (minor) bugs:
>
> 1. In your version, there should be a space between the last tab and
> this mysterious "X" to the far right of the tab line. Otherwise the X
> looks like it's part of the file name. I have a similar problem that I
> had failed to notice where I have three spaces instead of one - thus
> wasting space.
I never have enough tabs to fill the line, and since the X is at far
right, I usually have quite some empty space between it and the
rightmost tab.
>
> 2. When opening more tabs than the width of the display can accommodate,
> if you issue a "1"+"gt" you do move back the focus to tab #1, but the
> beginning of the tab line is not displayed, which means that you may be
> displaying part of tab #4 etc. and you are not able to see which tab you
> are on, since the tab that should be highlighted is not visible. All you
> see is a "<" in column one that indicates that there are more tabs to
> the left but I haven't found the way to display them. Maybe something to
> do with that right-justified final "X" - I'm curious what that "X" is
> for.. I don't use a mouse, so maybe that's why it does nothing that I
> can see. Maybe the "<" is clickable?
click X (with the mouse) to close the current tab IIRC.
>
> On the other hand, we both fixed another minor bug with vim's default
> tab line, where the space immediately following the file name is
> highlighted, which doesn't look right.
>
> I'm still debating the usefulness of having the&modified flag
> materialize in my version. Kinda of clutters the display and I'm not
> really sure I need that, so I may remove it - or possibly remove the
> number of windows in a tab - made the coding more fun but I don't think
> I really care if a tab has three windows open rather than four.
there may be several windows in a tab, with modified buffers in some and
unmodified ones in others.
>
> I'm curious as to why the tab line was implemented this way rather than
> something like the status line. I'm not complaining, mind you, writing a
> simple function was definitely a fun and useful experience - vim is an
> editor for programmers, not a word processor, right ;-) - but I'm not
> sure why it was not done the same way for the terminal as for the gui -
> cf. :h set guitablabel..?
it _was_ done like the status line i.e. for the whole width. You can
display what you want in it, even just the number of the current tab...
I think there were a few Vim 7.0aa (alpha) snapshots which had the
'tabline' option available but not 'guitablabel'. The latter has to mesh
with tabs built by whatever GUI subsystem it was compiled with, so it
has to build only one tab label at a time. The former is part of the Vim
text display and to the OS it is just plain monospaced text just like
the rest of the Vim display.
>
> What would be possible then is that since users normally display the
> same data in all their tabs, provided they had been implemented, you
> could simply refer to a list of items similar to the ones defined in ":h
> 'statusline'".
>
> To clarify, the help file could look a bit like:
>
> 'tablabel'
>
> ...
>
> item meaning
>
> N tab number
> n number of windows in tab
> F full name of file in current window
> f base name of file in current window
> m tab has unsaved buffers - cf.&modified
>
> etc.
>
> Anyway, attaching what I came up with, if you care to take a peek..
>
> Hopefully it's I'm not violating the list's policy.
>
> It's fenc=utf8& tw=80 so I'm not sure I could paste it in this message.
tw=80 shouldn't be a problem, and you wouldn't be the first to post in
UTF-8, though UTF-8, ISO-8859-1 and US-ASCII represent identically
everything until U+007F / 0x7F / 127, so if you have only text
representable in 7-bit ASCII it can be read even by those braindead
mailers which don't obey the Content-Type header (and read any mail as
if it were encoded in Latin1), even if you send in UTF-8. SeaMonkey
1.1.6 (which you seem to be using) ought to set the mail headers
correctly according to how it sends the mail if you paste the text
inline. If you send it as attachment SeaMonkey doesn't necessarily know
the file's encoding, but regardless of whether or not there are "high
codepoints" in the text, UTF-8 with BOM, i.e. ":setlocal fenc=utf-8
bomb", should be readable by any modern editor including Vim (if
compiled with +multi_byte and set up with 'enc' set to utf8 and 'fencs'
starting with ucs-bom).
The only reason not to attach the file (or part of file) itself would be
if it were very long, and even then you could upload it somewhere (if
there is "somewhere" you can upload to) and post a link to it.
>
> It has lots of useless comments that I had to put in there for my own
> sake, just to keep track of what I was doing. :-)
If they are really useless you can remove them, but if they are only
useful to rank newbies they are not useless and in that case you can
leave them in. :-)
>
> Oh, one other thing.. I often toggle between two tabs say, that may not
> be adjacent.. Does vim keep track of the previous tab you were on so
> that I could switch back and forth between tab-x and tab-y..?
I think that if it existed it would be mentioned under "SWITCHING TO
ANOTHER TAB PAGE" in the help section starting with ":tabnext". I don't
ese it there so I suppose there's nothing built-in. I suppose you can
make autocommands to remember the previously-used tab, and a mapping or
user-command to go back to it.
>
> I didn't see anything in the manual.
>
> Thanks,
>
> Gen-Paul.
Best regards,
Tony.
--
You can't judge a book by the way it wears its hair.
Patrick Gen-Paul
> On 15/09/09 19:38, Patrick Gen-Paul wrote:
>> I have to count the tabs so as to be able to issue {count}gt's or else
>> issue a ":tabs"
>
> see :help tabpagenr()
Sorry for being unclear - I have for instance ten tabs and I see in the
tabline that I have my .vimrc in one of them and would like to go there
directly. At a glance it could be tab #3 or tab #4. Without the tab
number displayed, I need to count the tabs, 1, 2, 3, etc. to determine
which tab I want to go to - or else use the ":tabs" command.
Having the tab number displayed makes navigation between tabs a lot easier.
[..]
> click X (with the mouse) to close the current tab IIRC.
Doesn't do anything. :-(
[..]
>> I'm curious as to why the tab line was implemented this way rather than
>> something like the status line. I'm not complaining, mind you, writing a
>> simple function was definitely a fun and useful experience - vim is an
>> editor for programmers, not a word processor, right ;-) - but I'm not
>> sure why it was not done the same way for the terminal as for the gui -
>> cf. :h set guitablabel..?
>
> it _was_ done like the status line i.e. for the whole width. You can
> display what you want in it, even just the number of the current tab...
With gvim, something like ":set guitablabel=%N\ %f" defines a template
for your labels and vim automatically takes care of building each actual
label.
Unless I missed something, the equivalent option is not available for
users of non-gui vim.
What I meant initially was that whereas with gvim, basic tab line
customization is provided in a way that's similar to the status line,
with non-gui vim, you cannot define a template, and customizing your tab
line requires that you write code that will create it dynamically.
Could this be because the tab line was first felt to be something that
would fit in nicely with the gui model, and only implemented in terminal
vim as an afterthought?
[..]
> If you send it as attachment SeaMonkey doesn't necessarily know
> the file's encoding..
My bad - just discovered how I can change the character encoding after I
start composing my reply.
[..]
Thanks,
Gen-Paul.
Tony Mechelynck
[...]
>>> I'm curious as to why the tab line was implemented this way rather than
>>> something like the status line. I'm not complaining, mind you, writing a
>>> simple function was definitely a fun and useful experience - vim is an
>>> editor for programmers, not a word processor, right ;-) - but I'm not
>>> sure why it was not done the same way for the terminal as for the gui -
>>> cf. :h set guitablabel..?
>>
>> it _was_ done like the status line i.e. for the whole width. You can
>> display what you want in it, even just the number of the current tab...
>
> With gvim, something like ":set guitablabel=%N\ %f" defines a template
> for your labels and vim automatically takes care of building each actual
> label.
>
> Unless I missed something, the equivalent option is not available for
> users of non-gui vim.
>
> What I meant initially was that whereas with gvim, basic tab line
> customization is provided in a way that's similar to the status line,
> with non-gui vim, you cannot define a template, and customizing your tab
> line requires that you write code that will create it dynamically.
>
> Could this be because the tab line was first felt to be something that
> would fit in nicely with the gui model, and only implemented in terminal
> vim as an afterthought?
With 'statusline', you define the _whole_ statusline (for the full width
of the screen), and Vim repeatedly parses the option value at runtime
-dynamically- to make appear or disappear the [+], line, column,
filename, whatever.
With 'tabline', which, IIRC, appeared in Vim 7.0 alpha shortly _before_
'guitablabel' (as I already mentioned but apparently you didn't even see
that, and snipped it when replying), you _also_ define the tabline for
the whole width; however, due to its repetitive character, you have to
do it by means of a ":while" loop, which means using a function, which
was accounted for via a new statusline-like code, namely %!, to evaluate
the whole line as the return value of a function. That code could then
also be used for the 'statusline' option but IIRC it appeared together
with the 'tabline' option.
If you want to separate text-style labels by putting / dividers left of
the current label and \ ones right of it, you can, but you don't have
to. You can also use | as separator between labels, or just a space,
with maybe a change of highlight for the current tab.
For "gui-style" tab labels, the OS takes care of the decorations, and
gvim has to define separately the contents of one tab label at a time.
You can't define what kind of separators you want, the OS decides that
for you. IIRC implementing this option required some more thinking and
was implemented as an afterthought, not the other way round. It also
imposes more limitations on what you can display; and if you want
GUI-style tab labels in the GUI and a text-style tab line in Console Vim
you have to define both 'tabline' and 'guitablabel' separately; OTOH it
is quite possible to use a text-style tabline in both (I do), and in
that case you can dispense with 'guitablabel'.
Best regards,
Tony.
--
The rain it raineth on the just
And also on the unjust fella,
But chiefly on the just, because
The unjust steals the just's umbrella.
Patrick Gen-Paul
> [...]
> With 'statusline', you define the _whole_ statusline (for the full
width
> of the screen), and Vim repeatedly parses the option value at runtime
> -dynamically- to make appear or disappear the [+], line, column,
> filename, whatever.
>
> With 'tabline', which, IIRC, appeared in Vim 7.0 alpha shortly _before_
> 'guitablabel' (as I already mentioned but apparently you didn't even see
> that, and snipped it when replying), you _also_ define the tabline for
> the whole width; however, due to its repetitive character, you have to
> do it by means of a ":while" loop, which means using a function, which
> was accounted for via a new statusline-like code, namely %!, to evaluate
> the whole line as the return value of a function. That code could then
> also be used for the 'statusline' option but IIRC it appeared together
> with the 'tabline' option.
If you still have access to my second post in this thread, you will note
that I was talking about a template for the tab label, not the tab line.
I mentioned the status line as an illustration only because it provides
an extensive set of "items" that can be specified via the 'statusline'
option.
> If you want to separate text-style labels by putting / dividers left of
> the current label and \ ones right of it, you can, but you don't have
> to. You can also use | as separator between labels, or just a space,
> with maybe a change of highlight for the current tab.
The point I was making is that some degree of customization could have
been provided by giving console-vim users the possibility to specify a
template for their tab labels as it was done for gvim via 'guitablabel'.
With the current implementation, even the most basic customization such
as replacing the full file name by the base name requires that the user
write a function.
Naturally, the more flexible implementation I had in mind need not have
precluded optionally assigning the return value of a function to tabline
for users who felt that they needed more advanced customization, such as
setting fancier tab separators than the default space, etc.
> For "gui-style" tab labels, the OS takes care of the decorations, and
> gvim has to define separately the contents of one tab label at a time.
> You can't define what kind of separators you want, the OS decides that
> for you. IIRC implementing this option required some more thinking and
> was implemented as an afterthought, not the other way round. It also
> imposes more limitations on what you can display; and if you want
> GUI-style tab labels in the GUI and a text-style tab line in Console Vim
> you have to define both 'tabline' and 'guitablabel' separately; OTOH it
> is quite possible to use a text-style tabline in both (I do), and in
> that case you can dispense with 'guitablabel'.
Hehe.. If I didn't have a terminal and had to use gvim, I would use a
"text-mode" tabline as well, so I could remove _all_ the widgets, not
limited to tabs, but also the toolbars, scrollbars, status bars, menu
bars, as well as the title bar. :-)
Thank you for your comments.
Gen-Paul.
Tony Mechelynck
[...]
> Hehe.. If I didn't have a terminal and had to use gvim, I would use a
> "text-mode" tabline as well, so I could remove _all_ the widgets, not
> limited to tabs, but also the toolbars, scrollbars, status bars, menu
> bars, as well as the title bar. :-)
I don't think you can remove the titlebar altogether (except maybe by
removing the titlebars from _all_ applications, if your OS allows it),
but you _can_ remove the tabline and the bottom statusbar, even in
Console Vim: just use
if has('windows')
set showtabline=0 laststatus=0
endif
I don't recommend removing them, but YMMV. Of course, if you do, this
whole discussion about 'tabline' vs. 'guitablabel' becomes moot.
>
> Thank you for your comments.
My pleasure.
>
> Gen-Paul.
Best regards,
Tony.
--
Electrical Engineers do it with less resistance.
Matt Wozniski
>
> On 20/09/09 02:36, Patrick Gen-Paul wrote:
> [...]
>> Hehe.. If I didn't have a terminal and had to use gvim, I would use a
>> "text-mode" tabline as well, so I could remove _all_ the widgets, not
>> limited to tabs, but also the toolbars, scrollbars, status bars, menu
>> bars, as well as the title bar. :-)
>
> I don't think you can remove the titlebar altogether (except maybe by
> removing the titlebars from _all_ applications, if your OS allows it),
<OT>
On Unix, openbox (and I believe fluxbox) can remove decorations on a
per application basis. Compiz can, as well, IIRC, and there are
generic programs that monitor spawned windows and apply rules (like
"remove the decorations") based on pattern matching.
</OT>
~Matt
Tim Chase
>> removing the titlebars from _all_ applications, if your OS allows it),
>
> <OT>
> On Unix, openbox (and I believe fluxbox) can remove decorations on a
> per application basis.
Confirming fluxbox can too. I use it (fluxbox+no_decorations)
regularly for Thunderbird, my xterms, and my
browser-flavor-of-the-month (currently Midori and Dillo).
-tim
Patrick Gen-Paul
I've never really understood the purpose of title bars, but nowadays
with just about everything coming with tabs out of the box, I really
feel that they add little value and just use up screen real estate that
could be put to better use elsewhere.
So I don't have a problem removing all window manager decorations and
running everything full screen - using a GNU/screen's split screen
feature on the rare occasions when I really need output from different
applications side by side in the same viewport.
Thanks for your comments.
Gen-Paul.