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

[Juri Linkov <juri@linkov.net>]

[-- Attachment #1: Type: text/plain, Size: 5084 bytes --]

>>>>     (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?

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.

There are two separate cases to consider:

1. Moving an inactive tab to another frame.
   In this case we need to use its window-state, not window-configuration,
   i.e. just delete the window-configuration from tab data, then it
   could be moved to another frame without problems.

2. Moving the current tab to another frame.  Here we need to save
   window-configuration of another frame to its inactive tab, then clone
   the original frame to another frame.  Do you know if such a function
   already exists that duplicates all frame parameters with frame-root
   window-state to another frame?

An additional question to consider is how to interactively select
an another frame: by frame name, or using other-frame with a numeric
prefix argument?

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

I think a tab should know nothing about the frame where it belongs,
otherwise it would complicate the matter (e.g. saving to the desktop).
The code that operates on tabs should follow the data hierarchy starting
from frames then accessing tabs from each frame, i.e. we should never
have a dangling tab from which to ask where is its frame.

But code that returns the tab could add a parameter frame to the
returned tab like in the patch below.

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

A better function is implemented below: tab-bar-get-buffer-tab takes
the function name, arguments and docstring from get-buffer-window.

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

We need an alist entry that will tell display-buffer-reuse-window
to search in tabs.  Maybe just the presence of the 'use-tabs' param
will tell display-buffer-reuse-window to search in tabs like:

(push '("test1" .
         (display-buffer-reuse-window
          (reusable-frames  . visible)
          (use-tabs . t)))
       display-buffer-alist)

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

Maybe this is better?

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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: tab-bar-get-buffer-tab.patch --]
[-- Type: text/x-diff, Size: 2214 bytes --]

diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index 5eb332884c..af993637a6 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -1284,6 +1284,44 @@ display-buffer-in-tab
               (tab-bar-rename-tab name))))
       (tab-bar-new-tab))))
 
+(defun tab-bar-get-buffer-tab (buffer-or-name &optional all-frames)
+  "Return a tab currently displaying BUFFER-OR-NAME, or nil if none.
+BUFFER-OR-NAME may be a buffer or a buffer name and defaults to
+the current buffer.
+
+The optional argument ALL-FRAMES specifies the frames to consider:
+
+- t means consider all tabs on all existing frames.
+
+- `visible' means consider all tabs on all visible frames.
+
+- A frame means consider all tabs on that frame only.
+
+Any other value of ALL-FRAMES means consider all tabs on the
+selected frame and no others."
+  (let ((buffer (if buffer-or-name
+                    (get-buffer buffer-or-name)
+                  (current-buffer))))
+    (when (bufferp buffer)
+      (let ((frames (cond
+                     ((eq all-frames t) (frame-list))
+                     ((eq all-frames 'visible) (visible-frame-list))
+                     ((framep all-frames) (list all-frames))
+                     (t (list (selected-frame))))))
+        (seq-some (lambda (frame)
+                    (with-selected-frame frame
+                      (seq-some (lambda (tab)
+                                  (when (if (eq (car tab) 'current-tab)
+                                            (get-buffer-window buffer frame)
+                                          (let* ((state (cdr (assq 'ws tab)))
+                                                 (buffers (when state
+                                                            (window-state-buffers state))))
+                                            (or (memq buffer buffers)
+                                                (member (buffer-name buffer) buffers))))
+                                    (append tab `((frame . ,frame)))))
+                                (funcall tab-bar-tabs-function))))
+                  frames)))))
+
 \f
 (defun switch-to-buffer-other-tab (buffer-or-name &optional norecord)
   "Switch to buffer BUFFER-OR-NAME in another tab.