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