bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Juri Linkov
Subject: bug#38354: 27.0.50; Implement display action display-buffer-in-tab
Date: Wed, 27 Nov 2019 23:37:48 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu)

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

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

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

> 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

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

> 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.
But currently there is need for a function that returns a tab that has
the given buffer:

diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index 5eb332884c..7746c59f17 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -1284,6 +1284,13 @@ display-buffer-in-tab
+(defun tab-bar-has-buffer-in-tab (buffer)
+  "Return a tab that has the buffer BUFFER."
+  (seq-some (lambda (tab)
+              (when (memq buffer (window-state-buffers (cdr (assq 'ws tab))))
+                tab))
+            (funcall tab-bar-tabs-function)))

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

Than we need to add 'reusable-tabs'?

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

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]