Re: Tabs

[Juri Linkov]

> My usage is like this: I want tabs in w3m, for w3m buffers, tabs for
> eww buffers in a frame "dedicated" to browsing with eww (like a firefox
> window), tabs in *info* showing *info* buffers, etc.  I don't want
> tabs always and everywhere, I want tabs only for certain modes and then
> they should only show related buffers.  And I don't (necessarily) want
> to save any desktop file or frame configurations or so.  I just want to
> have missing tab support for e.g. eww or info, preferably without losing
> the header line.
>
> Does your implementation cover such a user behavior?

Yes, it's already customizable enough to cover many different needs.

At the core it provides a new place at the top of the frame for
the frame-local tab-bar, and also places for window-local tab-lines
at the top of each window.  So authors of many existing packages that
currently had no choice other than taking space from the header-line,
now can adapt packages to use new locations reserved specially for tabs.

If you are already using one of these packages you might want to
continue using them with the new tabs locations that doesn't conflict
with the header-line.  These packages provide dozens of user options,
and it makes no sense to copy all them to the core.  Instead of trying
to cover an infinite set of possible customization preferences, the core
should be general to allow adapting to the customization needs easily.

The current implementation is already flexible enough, so for example,
what you asked for *info* buffers, is possible to do with the current
implementation with just a few lines:

  (advice-add 'tab-line-tabs :around
              (lambda (orig-fun &optional window)
                (if (derived-mode-p 'Info-mode)
                    (mapcan (lambda (b)
                              (with-current-buffer b
                                (when (derived-mode-p 'Info-mode)
                                  (list b))))
                            (buffer-list))
                  (funcall orig-fun window))))

Later this could be generalized to provide e.g. an option for the list
of modes where to enable this behavior.

Also I already implemented more features such as tab close undo,
tab history back, etc.  But it would be better to add them later
after merging the branch to master, so merging will be easier
with minimal set of changes.  Thus perhaps now I should start
preparations for merging the feature/tabs branch to master
that includes mostly writing documentation for the Info manual.