But the patch works and tabs have been set and the initial tab has been
assigned and passed to the hook. Works fine. I'm missing your concern.

On Tue, Oct 29, 2024 at 3:49 PM Juri Linkov <juri@linkov.net> wrote:

> > 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.
>
> The hook 'tab-bar-tab-post-open-functions' can't be called from
> 'tab-bar-tabs'
> because no new tab is opened from 'tab-bar-tabs'.  The initial tab already
> exists.
>
> What could be done in 'tab-bar-tabs' is to call a completely new hook named
> 'tab-bar-init'.
>