From: Ship Mints <shipmints@gmail.com>
To: Juri Linkov <juri@linkov.net>
Cc: 74087@debbugs.gnu.org
Subject: bug#74087: Bug patch: invoke tab-bar-tab-post-open-functions during tabs initialization
Date: Tue, 29 Oct 2024 15:32:49 -0400 [thread overview]
Message-ID: <CAN+1HbqP59prt3O7N93-3-4ABfhVjVUezaDtgLz4hFayjxMt=A@mail.gmail.com> (raw)
In-Reply-To: <CAN+1HboN+D7qB8JCWRC_=28k+TRZxpQwBqJCmgvYaJUC3dy2PQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]
A pre-open tab hook, though, might be useful for pinning cases if it would
allow influencing the tab position as a function value. I could think on
that separately from the proposed patch and see if I can simplify pinning
as a result (which is already a pain in the neck and quite imperfect).
On Tue, Oct 29, 2024 at 3:23 PM Ship Mints <shipmints@gmail.com> wrote:
> In a pre-open hook, I'd expect to be able to deny a new tab being opened,
> for example, if I want a tab-bar with a fixed set of tabs. That seems like
> a different use-case from operating on a tab after it's officially created
> even if not yet visible.
>
> On Tue, Oct 29, 2024 at 3:18 PM Ship Mints <shipmints@gmail.com> wrote:
>
>> That's not a good assumption, though. The motivation behind putting the
>> open hook call after the tabs are set on the frame is to allow users to use
>> the frame tabs as they would for tabs created at any other time with no
>> special casing. I don't think we need a special case, just treat all tabs
>> the same, first or beyond.
>>
>> My pre-close case is currently limited to just "lock" testing to inhibit
>> closing and is different.
>>
>> On Tue, Oct 29, 2024 at 3:09 PM Juri Linkov <juri@linkov.net> wrote:
>>
>>> > I think my proposed patch is more natural for implied-open tabs (with
>>> the
>>> > tab bar showing or not, doesn't really matter) or explicitly opened
>>> ones.
>>> > Just invoke when the tabs are created seems the best route and the one
>>> that
>>> > people would expect reading the code.
>>> >
>>> > I'll have a look at the close hooks again in a bit. I do know the
>>> behavior
>>> > of the pre-close hook is good for my uses.
>>>
>>> Since the behavior of the pre-close hook is good for your uses,
>>> then the best solution for you would be to introduce a new similar hook:
>>> 'tab-bar-tab-pre-open-functions' that will be called in the first tab as
>>> well.
>>>
>>
[-- Attachment #2: Type: text/html, Size: 3100 bytes --]
next prev parent reply other threads:[~2024-10-29 19:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-29 14:12 bug#74087: Bug patch: invoke tab-bar-tab-post-open-functions during tabs initialization Ship Mints
2024-10-29 18:13 ` Juri Linkov
2024-10-29 18:19 ` Ship Mints
2024-10-29 18:29 ` Ship Mints
2024-10-29 18:43 ` Ship Mints
2024-10-29 18:52 ` Juri Linkov
2024-10-29 19:03 ` Ship Mints
2024-10-29 19:07 ` Juri Linkov
2024-10-29 19:18 ` Ship Mints
2024-10-29 19:23 ` Ship Mints
2024-10-29 19:32 ` Ship Mints [this message]
2024-10-29 19:46 ` Juri Linkov
2024-10-29 20:04 ` Ship Mints
2024-10-29 20:05 ` Ship Mints
2024-10-30 7:24 ` Juri Linkov
2024-10-30 12:41 ` Ship Mints
2024-10-30 13:44 ` Ship Mints
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='CAN+1HbqP59prt3O7N93-3-4ABfhVjVUezaDtgLz4hFayjxMt=A@mail.gmail.com' \
--to=shipmints@gmail.com \
--cc=74087@debbugs.gnu.org \
--cc=juri@linkov.net \
/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.