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.