From: Juri Linkov <juri@linkov.net>
To: martin rudalics <rudalics@gmx.at>
Cc: 38354@debbugs.gnu.org
Subject: bug#38354: 27.0.50; Implement display action display-buffer-in-tab
Date: Wed, 27 Nov 2019 23:37:48 +0200 [thread overview]
Message-ID: <87d0dd3yb7.fsf@mail.linkov.net> (raw)
In-Reply-To: <7979be54-2a01-2e97-d956-2500e7999e26@gmx.at> (martin rudalics's message of "Wed, 27 Nov 2019 10:49:17 +0100")
>> 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.
next prev parent reply other threads:[~2019-11-27 21:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-23 23:09 bug#38354: 27.0.50; Implement display action display-buffer-in-tab Juri Linkov
2019-11-26 9:32 ` martin rudalics
2019-11-26 22:30 ` Juri Linkov
2019-11-26 22:43 ` Juri Linkov
2019-11-27 9:49 ` martin rudalics
2019-11-27 21:37 ` Juri Linkov [this message]
2019-11-28 9:20 ` martin rudalics
2019-11-28 23:02 ` Juri Linkov
2019-11-29 9:24 ` martin rudalics
2019-12-01 22:29 ` Juri Linkov
2019-12-02 9:40 ` martin rudalics
2019-12-02 23:43 ` Juri Linkov
2019-12-03 9:18 ` martin rudalics
2019-12-03 23:36 ` Juri Linkov
2019-12-04 9:22 ` martin rudalics
2019-12-04 22:51 ` Juri Linkov
2019-12-05 9:05 ` martin rudalics
2019-12-05 23:54 ` Juri Linkov
2019-12-06 7:37 ` martin rudalics
2022-12-06 17:40 ` Juri Linkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d0dd3yb7.fsf@mail.linkov.net \
--to=juri@linkov.net \
--cc=38354@debbugs.gnu.org \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.