Re: Some ideas to improve Tab Bar

[Juri Linkov <juri@linkov.net>]

>> 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'.

This is fine since it's based on existing variable names.

>> 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.

A new boolean option would be too ad-hoc.  OTOH, a custom function to format
the final tab bar would be more preferable.  Maybe the same custom function
could be used to add more items like adding custom texts or buttons below:

>> 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.

Mode line constructs can be used to format tab-line, e.g.:

  (global-tab-line-mode)
  (setq tab-line-format '(:eval mode-line-format))

but not tab-bar.  tab-bar needs a completely separate solution.

>> `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.

I don't know, we need to ask the users of winner-mode whether they
can lose something after doing

 (defalias 'winner-mode 'tab-bar-history-mode)
 (defalias 'winner-undo 'tab-bar-history-back)
 (defalias 'winner-redo 'tab-bar-history-forward)