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
>
> In my code I use for this:
>
>    (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.  Wouldn't something
like 'tab-bar-buffer-present-in-tabs-p' or 'tab-bar-buffer-in-tabs-p'
be more intuitive?

>> - to say that a buffer is actually displayed on a frame that has a
>>    tab-bar.
>
> In my code I use for this:
>
>    (>= (length (get-buffer-window-list buffer t t)) 1)

Why not simply 'get-buffer-window'?  In either case what does the
above "displayed" in

>>> to display the buffer in an existing tab if such buffer is
>>> already displayed in it.

refer to now?  The former, the latter or their

> i.e. I check these situations differently, and use 'or'
> to combine these conditions:
>
>    (or (>= (length (get-buffer-window-list buffer t t)) 1)
>        (tab-bar-buffer-visible-in-tabs-p buffer))
>
> Should these conditions be combined in one function
> (if the current tab can be considered a tab as well)?

'or'?

>> 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.
>
> Not sure if "tabbed" is the right word.  None of these definitions fits:
> https://www.dictionary.com/browse/tabbed
> https://www.urbandictionary.com/define.php?term=tabbed

'tab' itself is already problematic, as we know.

>>> This will require a new function function tab-bar-buffer-visible-in-tabs.
>>
>> What would "visible" precisely stand for here?
>
> Maybe a better word is "has"?  Then the name would be 
tab-bar-has-buffer-in-tab.

OK.  But I think that the "has" is superfluous.

>> And why "tabs" indiscriminately?  Don't you ever want to check for
>> presence or visibility in a specific tab only?
>
> A specific tab referred by name?  Maybe such function could be useful as well.

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?

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

>>> 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'?
>
> Rather calling it explicitly with a new commands, but it should be
> possible to use 'kill-buffer-query-functions' too.

But the idea is to _not_ kill the buffer.  Right?  So this might be a
disconcerting effect.

>>> 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?
>
> A buffer can't be removed from saved window-configurations and window-states.

The buffer's object can be removed.  The buffer reference in a saved
window structure is weak, it cannot prevent collecting the buffer
object.

martin