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