Plus, the patch treats both initial and secondary tab opening identically with no special casing. That's key for users. On Tue, Oct 29, 2024 at 4:04 PM Ship Mints wrote: > 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 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 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 >> 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'. >> >