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