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

[martin rudalics]

> display-buffer-in-tab is implemented now, but we need also an action
> to display the buffer in an existing tab if such buffer is
> already displayed in it.

Could we please clarify the term "display(ed)" in this context.  IIUC
you use it

- to say that a buffer is part of a tab (a window configuration that
  can be shown on a frame), and

- to say that a buffer is actually displayed on a frame that has a
  tab-bar.

Right?  Then the former should not use the term "display(ed)" but
maybe something like "tab(bed)".  "Tab a buffer" would then mean to
make sure that the buffer is part of a tab, "tabbed" that it is part
of at least one tab.

> I tried to copy an existing action
> that supports frames, but can't find such a frame action that
> would select another frame if the buffer is already is displayed in it.
> Does such frame action exist whose behavior could be copied to tabs?

'display-buffer-reuse-window' together with 'reusable-frames' should
have all the ingredients for this.  What is missing?

> This will require a new function function tab-bar-buffer-visible-in-tabs.

What would "visible" precisely stand for here?  And why "tabs"
indiscriminately?  Don't you ever want to check for presence or
visibility in a specific tab only?

> Also I use this function in a wrapper that kills the buffer, such wrapper 
checks
>
>    (tab-bar-buffer-visible-in-tabs-p (current-buffer))
>
> If true, it doesn't kill the buffer, but buries it.

Via 'kill-buffer-query-functions'?

> So switching back to that tab still displays the buffer.

When I do 'kill-buffer', I expect that buffer to get removed from
'buffer-list' and all windows showing it, that it won't be switched to
by many functions and so on.  Whatever we'd do, we have to manage this
controversy somehow.  Think of changes or the deletion of the visited
files.  How would we try to avoid saving such buffers to their files
in that case?

martin