bug#38354: 27.0.50; Implement display action display-buffer-in-tab

[martin rudalics]

>>>     (tab-bar-buffer-visible-in-tabs-p buffer)
>>
>> But this may also return non-nil when the buffer is invisible, that is
>> not shown in any window.  We already have the "visible frames"
>> notation, including the non-obscured frames connotation, so I'd rather
>> not use the term visible in the context of tabs.
>
> Maybe like having the terms "visible frame" and "iconified frame",
> we should use the terms "current tab" and "inactive tabs".

IIUC, during one and the same session any tab is frame-local, can be
shown only on one and the same frame.  Deleting a frame kills its tabs
too, due to our implementation of window configurations.  Right?

If so, then we should decide whether we always want to stick to that
limitation or, eventually allow moving tabs between frames, probably
using window states for that purpose.  And we have to decide whether
such moving of a tab would mean making a completely self-reliant copy
of it or keep properties of it shared among frames.  And eventually we
should decide whether tabs could become first-class citizens - have a
life of their own without being attached to any frame.

Once we have decided on what to do here, we can try finding an
appropriate nomenclature.  That is, for each tab we can then either
find a function called 'tab-frame' (to return its one and only frame)
or 'tab-frame-list' (to return a possibly empty list of all frames
that currently have that tab in their tab-bar).  For each frame, we
should use 'frame-tab(s)-list' for returning all tabs in their
tab-bar, 'frame-selected|current|active-tab' for returning the tab
currently shown on that frame.  Maybe we could use a fitting
ALL-FRAMES arguments to return all tabs in tab-bars of all visible,
visible or iconified, ... frames with a function called 'tab(s)-list'
or the like.

In either case, a suitable, possibly expandable, nomenclature should
be established now - we already have enough examples of clashes in our
present frames/windows/buffer naming conventions.

>> Wouldn't something like 'tab-bar-buffer-present-in-tabs-p' or
>> 'tab-bar-buffer-in-tabs-p' be more intuitive?
>
> Instead of suffix '-p' that assumes the function returns a boolean value,
> better to return the found tab with the function name 'tab-bar-buffer-in-tab'.

Sure.  You just have to decide here and now on the arguments of that
function: Which tabs to search for the buffer?

> Anyway it seems better not to use the word "displayed".

"Displayed" and "shown" are useful for doc-strings and manuals.
Elsewhere, they can be ambiguous.

>> Don't you ever want to discriminate the tabs of the selected frame
>> from the tabs of other frames?  Or are they all the same?
>
> This means we need to add another dimension: first to look for the buffer
> in all tabs of the selected frame, then look in tabs of other frames:
> visible, iconified, or on any frame.

See below.

>>>> 'display-buffer-reuse-window' together with 'reusable-frames' should
>>>> have all the ingredients for this.  What is missing?
>>>
>>> Than we need to add 'reusable-tabs'?
>>
>> Why?  If a target tab (a tab with the name specified by ALIST) exists
>> on any frame specified by 'reusable-frames', reuse it.  Otherwise make
>> a new frame with the target tab as its only entry.
>
> I don't understand.  Should ALIST look like this?
>
> (push '("test1" .
>          ((display-buffer-reuse-window display-buffer-in-tab)
>           (reusable-frames  . visible)
>           (name . "Tab1")))
>        display-buffer-alist)

What would be the downside of it?  The 'reusable-frames' would specify
the list of frames to investigate - the other dimension you mentioned
above.

BTW: In the manual you write:

  By default, a new tab starts with the current buffer that was current
  before calling the command that adds a new tab.

That's confusing, at least.

martin