Re: Some ideas to improve Tab Bar

[Gabriel do Nascimento Ribeiro]

Juri Linkov <juri@linkov.net> writes:

>> Some little ideas on how Tab Bar can be further improved:
>
> Thanks for the ideas.
>
>> 1. Options to disable `tab-bar-back-button' and
>> `tab-bar-forward-button' when `tab-bar-history-mode' is on.  This will
>> be similar to what option `tab-bar-close-button-show' is to
>> `tab-bar-close-button'.
>
> The most difficult part is to choose a good option name.
> Maybe, `tab-bar-history-buttons-show' is not too bad.
>

I would suggest `tab-bar-back-button-show'and `tab-bar-forward-button-show'.

>> 2. Trim spaces of tab bar name. The tab bar name can have additional spaces 
>> on the right:
>>     2.1. When tab bar name name is set explicitly with `tab-bar-rename-tab';
>>     2.2. When `tab-bar-tab-hints' is true and `tab-bar-tab-name-function' 
>> returns an empty string;
>
> Sorry, I don't understand what is the problem.
> When the user intentionally adds spaces in case 2.1.,
> then why there is a need to trim spaces?
>

Yes, if the user intentionally adds space and wants this behavior, that's
okay. But if he wants the trim function or any other custom formatting, it's not
possible.

Another scenario is 2.2, where `tab-bar-tab-hints' is true and
`tab-bar-tab-name-function' returns an empty string. In this cases, tabs will be
named with a trim space on the right as follow: "1 ", "2 ", "3 " etc and it's
not possible to format the names (unless using some `defadvice´ on
`tab-bar-make-keymap-1' is used to manually modify the output list of menu
items). I ran into this problem when trying to mimic how some window managers
works by default like DWM or i3, where worspaces are named with numbers only.

I think that having some option here to better control how tab names are
displayed would be helpful and the implementation is not hard. We can add a new
boolean option to trim tab names or add a new option where the user can specify
a custom function to be run to format the final tab name string. There are more
alternatives but these two are the simplest, I guess.


>> 3. An easier way to add more items to Tab Bar to make it act more like
>> a general Bar.  The following example was shared in Emacs Devel
>> mailing list on how to add a simple clock to the right of Tab Bar:
>> =========================================
>>   (advice-add 'tab-bar-make-keymap-1 :around
>>               (lambda (orig-fun)
>>                 (append (funcall orig-fun)
>>                         `((display-time menu-item
>>                                         ,(concat
>>                                           (propertize " " 'display '(space 
>> :align-to (- right 5)))
>>                                           (format-time-string "%H:%M"))
>>                                         ignore))))
>>               '((name . tab-bar-display-time)))
>> =========================================
>
> Do you propose to add functions that would allow doing this more easily?
> Maybe using some hooks?
>

I didn't think in any implementation, actually. But I could see the potential of
the Tab Bar towards a more general Bar and that many users would like a better
control on what is displayed there, like adding custom texts or buttons. I ran
into this idea by reading some threads here in emacs-devel. I know `mode-line'
is super customizable and a there is `header-line' also, but that means having
additional bars on the screen.

>> 4. Maybe deprecate `winner-mode' in favor to `tab-bar-history-mode',
>> since these two modes have similar functions.
>> Using `tab-bar-history-mode' with only one Tab is like using
>> `winner-mode'.
>
> `winner-mode' should not be deprecated because it's still useful
> for users who don't use tabs with `tab-bar-mode'.  So `winner-mode'
> works fine when tabs are not used.  OTOH, `winner-mode' breaks tabs
> when used with `tab-bar-mode', so `tab-bar-history-mode' is needed
> to do the same when tabs are used.

That's my point. We have two similar modes to handle window configuration
history which works on specific cases. That means having more code on Emacs,
more documentation, more configuration on init files, more keybindings, more
stuff to learn, more confusion etc. That would be great if we could have a
single way to work with window configuration history in all cases. Not using
tabs is similar to using only one tab, where tab-bar visibility can be
configured with `tab-bar-show' set to nil or 1.

Regards,
Gabriel