bug#74087: Bug patch: invoke tab-bar-tab-post-open-functions during tabs initialization

bug#74087: Bug patch: invoke tab-bar-tab-post-open-functions during tabs initialization

[Ship Mints]

[-- Attachment #1.1: Type: text/plain, Size: 415 bytes --]

Greetings,

tab-bar-tab-post-open-functions need to be called during tab-bar
initialization. Currently, a user's custom post-open functions are invoked
only for tabs created beyond the initial tab. This is a bug, in my view.

I've created the patch vs. this morning's master and should also benefit
Emacs 30. I've been running a patched copy against my daily-use 29.4 for a
bit and it works as expected.

-Stephane

[-- Attachment #1.2: Type: text/html, Size: 902 bytes --]

[-- Attachment #2: 0001-Call-tab-bar-tab-post-open-functions-during-tabs-ini.patch --]
[-- Type: application/octet-stream, Size: 892 bytes --]

From 61a801eedb10d3d0dac5cf8b57c6b3641a6d226d Mon Sep 17 00:00:00 2001
From: shipmints <shipmints@gmail.com>
Date: Tue, 29 Oct 2024 09:56:15 -0400
Subject: [PATCH] Call tab-bar-tab-post-open-functions during tabs
 initialization

---
 lisp/tab-bar.el | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index 2efc2b8f85b..7fc04ab3c32 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -803,7 +803,9 @@ Return its existing value or a new value."
                   (funcall tab-bar-tab-name-function))))
       ;; Create default tabs
       (setq tabs (list (tab-bar--current-tab-make)))
-      (tab-bar-tabs-set tabs frame))
+      (tab-bar-tabs-set tabs frame)
+      (run-hook-with-args 'tab-bar-tab-post-open-functions
+                          (car tabs)))
     tabs))
 
 (defun tab-bar-tabs-set (tabs &optional frame)
-- 
2.47.0

bug#74087: Bug patch: invoke tab-bar-tab-post-open-functions during tabs initialization

[Juri Linkov]

> tab-bar-tab-post-open-functions need to be called during tab-bar
> initialization. Currently, a user's custom post-open functions are invoked
> only for tabs created beyond the initial tab. This is a bug, in my view.

Please explain what are you trying to achieve?

'tab-bar-tab-post-open-functions' is intended to be run in a new tab
explicitly created by the user via 'tab-bar-new-tab-to'.

OTOH, 'tab-bar-tabs' is a function that returns a list of existing tabs.

bug#74087: Bug patch: invoke tab-bar-tab-post-open-functions during tabs initialization

[Ship Mints]

[-- Attachment #1: Type: text/plain, Size: 1117 bytes --]

I'm trying to align all tab creation behavior with
tab-bar-tab-post-open-functions. Even the first tab should be considered
"opened" by the system and call people's functions on the hook. That tab,
if you close it, does call the close hooks correctly and that's aligned, at
least. If the open hook doesn't get called, then those tabs have to be
treated in a special way and that creates bugs and burden. Not sure how
relevant it is what I do in my custom hook that should get called for the
implied opened first frames but doesn't.

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

> > tab-bar-tab-post-open-functions need to be called during tab-bar
> > initialization. Currently, a user's custom post-open functions are
> invoked
> > only for tabs created beyond the initial tab. This is a bug, in my view.
>
> Please explain what are you trying to achieve?
>
> 'tab-bar-tab-post-open-functions' is intended to be run in a new tab
> explicitly created by the user via 'tab-bar-new-tab-to'.
>
> OTOH, 'tab-bar-tabs' is a function that returns a list of existing tabs.
>

[-- Attachment #2: Type: text/html, Size: 1539 bytes --]

bug#74087: Bug patch: invoke tab-bar-tab-post-open-functions during tabs initialization

[Ship Mints]

[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]

If you're really curious, one use case is auto-assigning a tab group. When
one makes a frame, the tab bar defaults to showing the window from which it
was created and any custom tab-bar symbols attached to the tab have to be
recreated. Another use case is optionally keeping tabs "pinned" to their
user-specified positions and the post-open hook can help track the first
and subsequent positions. I'll surely add more over time. tab-bar is great
and fun to use and enhance with cool productivity tools.

On Tue, Oct 29, 2024 at 2:19 PM Ship Mints <shipmints@gmail.com> wrote:

> I'm trying to align all tab creation behavior with
> tab-bar-tab-post-open-functions. Even the first tab should be considered
> "opened" by the system and call people's functions on the hook. That tab,
> if you close it, does call the close hooks correctly and that's aligned, at
> least. If the open hook doesn't get called, then those tabs have to be
> treated in a special way and that creates bugs and burden. Not sure how
> relevant it is what I do in my custom hook that should get called for the
> implied opened first frames but doesn't.
>
> On Tue, Oct 29, 2024 at 2:15 PM Juri Linkov <juri@linkov.net> wrote:
>
>> > tab-bar-tab-post-open-functions need to be called during tab-bar
>> > initialization. Currently, a user's custom post-open functions are
>> invoked
>> > only for tabs created beyond the initial tab. This is a bug, in my view.
>>
>> Please explain what are you trying to achieve?
>>
>> 'tab-bar-tab-post-open-functions' is intended to be run in a new tab
>> explicitly created by the user via 'tab-bar-new-tab-to'.
>>
>> OTOH, 'tab-bar-tabs' is a function that returns a list of existing tabs.
>>
>

[-- Attachment #2: Type: text/html, Size: 2485 bytes --]

bug#74087: Bug patch: invoke tab-bar-tab-post-open-functions during tabs initialization

[Ship Mints]

[-- Attachment #1: Type: text/plain, Size: 2044 bytes --]

We also have an "auto lock" feature that locks a tab from being closed,
though one can override with a prefix argument when closing a tab, or
calling the tab unlock command.

On Tue, Oct 29, 2024 at 2:31 PM Ship Mints <shipmints@gmail.com> wrote:

> If you're really curious, one use case is auto-assigning a tab group. When
> one makes a frame, the tab bar defaults to showing the window from which it
> was created and any custom tab-bar symbols attached to the tab have to be
> recreated. Another use case is optionally keeping tabs "pinned" to their
> user-specified positions and the post-open hook can help track the first
> and subsequent positions. I'll surely add more over time. tab-bar is great
> and fun to use and enhance with cool productivity tools.
>
> On Tue, Oct 29, 2024 at 2:19 PM Ship Mints <shipmints@gmail.com> wrote:
>
>> I'm trying to align all tab creation behavior with
>> tab-bar-tab-post-open-functions. Even the first tab should be considered
>> "opened" by the system and call people's functions on the hook. That tab,
>> if you close it, does call the close hooks correctly and that's aligned, at
>> least. If the open hook doesn't get called, then those tabs have to be
>> treated in a special way and that creates bugs and burden. Not sure how
>> relevant it is what I do in my custom hook that should get called for the
>> implied opened first frames but doesn't.
>>
>> On Tue, Oct 29, 2024 at 2:15 PM Juri Linkov <juri@linkov.net> wrote:
>>
>>> > tab-bar-tab-post-open-functions need to be called during tab-bar
>>> > initialization. Currently, a user's custom post-open functions are
>>> invoked
>>> > only for tabs created beyond the initial tab. This is a bug, in my
>>> view.
>>>
>>> Please explain what are you trying to achieve?
>>>
>>> 'tab-bar-tab-post-open-functions' is intended to be run in a new tab
>>> explicitly created by the user via 'tab-bar-new-tab-to'.
>>>
>>> OTOH, 'tab-bar-tabs' is a function that returns a list of existing tabs.
>>>
>>

[-- Attachment #2: Type: text/html, Size: 3103 bytes --]

bug#74087: Bug patch: invoke tab-bar-tab-post-open-functions during tabs initialization

[Juri Linkov]

>> I'm trying to align all tab creation behavior with
>> tab-bar-tab-post-open-functions. Even the first tab should be
>> considered "opened" by the system and call people's functions on the
>> hook. That tab, if you close it, does call the close hooks correctly
>> and that's aligned, at least.

Calling the close hooks currently doesn't look correct:

      (run-hook-with-args 'tab-bar-tab-pre-close-functions
                          (nth close-index tabs)
                          last-tab-p)
      (if last-tab-p
          (pcase tab-bar-close-last-tab-choice
            ('nil
             (user-error "Attempt to delete the sole tab in a frame"))

where first it makes an attempt to close the tab, calls the hook,
then fails with the user-error.  I think the hook should be called
when the tab is really closed.

>> If the open hook doesn't get called, then
>> those tabs have to be treated in a special way and that creates bugs
>> and burden. Not sure how relevant it is what I do in my custom hook
>> that should get called for the implied opened first frames but doesn't.
>
> If you're really curious, one use case is auto-assigning a tab group. When
> one makes a frame, the tab bar defaults to showing the window from which it
> was created and any custom tab-bar symbols attached to the tab have to be
> recreated. Another use case is optionally keeping tabs "pinned" to their
> user-specified positions and the post-open hook can help track the first
> and subsequent positions. I'll surely add more over time. tab-bar is great
> and fun to use and enhance with cool productivity tools.

Thanks, this is an interesting case.  Indeed, currently
there is an inconsistency.  For example, start `emacs -Q`.
Even if there is no tab-bar initially, we can say that
the first tab is already created.  Later, after creating
the second tab with 'C-x t 2', we have two tabs where
the post-open hook was called only in the second tab.

A possible solution would be to detect such situation
in 'tab-bar-new-tab-to' with the same code that
enables the tab-bar initially with:

    (when tab-bar-show
      (if (not tab-bar-mode)
          ;; Turn on `tab-bar-mode' since a tab was created.
          ;; Note: this also updates `tab-bar-lines'.
          (tab-bar-mode 1)
        (tab-bar--update-tab-bar-lines)))

then run the hook in the first tab as well.

bug#74087: Bug patch: invoke tab-bar-tab-post-open-functions during tabs initialization

[Ship Mints]

[-- Attachment #1: Type: text/plain, Size: 2986 bytes --]

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.

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

> >> I'm trying to align all tab creation behavior with
> >> tab-bar-tab-post-open-functions. Even the first tab should be
> >> considered "opened" by the system and call people's functions on the
> >> hook. That tab, if you close it, does call the close hooks correctly
> >> and that's aligned, at least.
>
> Calling the close hooks currently doesn't look correct:
>
>       (run-hook-with-args 'tab-bar-tab-pre-close-functions
>                           (nth close-index tabs)
>                           last-tab-p)
>       (if last-tab-p
>           (pcase tab-bar-close-last-tab-choice
>             ('nil
>              (user-error "Attempt to delete the sole tab in a frame"))
>
> where first it makes an attempt to close the tab, calls the hook,
> then fails with the user-error.  I think the hook should be called
> when the tab is really closed.
>
> >> If the open hook doesn't get called, then
> >> those tabs have to be treated in a special way and that creates bugs
> >> and burden. Not sure how relevant it is what I do in my custom hook
> >> that should get called for the implied opened first frames but doesn't.
> >
> > If you're really curious, one use case is auto-assigning a tab group.
> When
> > one makes a frame, the tab bar defaults to showing the window from which
> it
> > was created and any custom tab-bar symbols attached to the tab have to be
> > recreated. Another use case is optionally keeping tabs "pinned" to their
> > user-specified positions and the post-open hook can help track the first
> > and subsequent positions. I'll surely add more over time. tab-bar is
> great
> > and fun to use and enhance with cool productivity tools.
>
> Thanks, this is an interesting case.  Indeed, currently
> there is an inconsistency.  For example, start `emacs -Q`.
> Even if there is no tab-bar initially, we can say that
> the first tab is already created.  Later, after creating
> the second tab with 'C-x t 2', we have two tabs where
> the post-open hook was called only in the second tab.
>
> A possible solution would be to detect such situation
> in 'tab-bar-new-tab-to' with the same code that
> enables the tab-bar initially with:
>
>     (when tab-bar-show
>       (if (not tab-bar-mode)
>           ;; Turn on `tab-bar-mode' since a tab was created.
>           ;; Note: this also updates `tab-bar-lines'.
>           (tab-bar-mode 1)
>         (tab-bar--update-tab-bar-lines)))
>
> then run the hook in the first tab as well.
>

[-- Attachment #2: Type: text/html, Size: 3801 bytes --]

bug#74087: Bug patch: invoke tab-bar-tab-post-open-functions during tabs initialization

[Juri Linkov]

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

bug#74087: Bug patch: invoke tab-bar-tab-post-open-functions during tabs initialization

[Ship Mints]

[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1682 bytes --]

bug#74087: Bug patch: invoke tab-bar-tab-post-open-functions during tabs initialization

[Ship Mints]

[-- Attachment #1: Type: text/plain, Size: 1537 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2373 bytes --]

bug#74087: Bug patch: invoke tab-bar-tab-post-open-functions during tabs initialization

[Ship Mints]

[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3100 bytes --]

bug#74087: Bug patch: invoke tab-bar-tab-post-open-functions during tabs initialization

[Juri Linkov]

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

bug#74087: Bug patch: invoke tab-bar-tab-post-open-functions during tabs initialization

[Ship Mints]

[-- Attachment #1: Type: text/plain, Size: 1686 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2332 bytes --]

bug#74087: Bug patch: invoke tab-bar-tab-post-open-functions during tabs initialization

[Ship Mints]

[-- Attachment #1: Type: text/plain, Size: 1944 bytes --]

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 <shipmints@gmail.com> 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 <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'.
>>
>

[-- Attachment #2: Type: text/html, Size: 2890 bytes --]

bug#74087: Bug patch: invoke tab-bar-tab-post-open-functions during tabs initialization

[Juri Linkov]

> 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 <shipmints@gmail.com> 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.

The only concern here is that this change might break existing users' configs.
The users already might have a lot of different unimaginable uses of
this hook such as for example to move a new tab to another position
on the tab-bar, etc.  Are you sure this change won't break users' configs?

bug#74087: Bug patch: invoke tab-bar-tab-post-open-functions during tabs initialization

[Ship Mints]

[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]

I'd done a search engine search using two engines for any "public" use of
tab-bar-tab-post-open-functions and found only two cases, both of which
would be affected positively by the patch. I'm guessing that there aren't a
lot of people using the hook or the missing call for the initial tab would
have cropped up sooner.

On Wed, Oct 30, 2024 at 3:35 AM Juri Linkov <juri@linkov.net> wrote:

> > 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 <shipmints@gmail.com> 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.
>
> The only concern here is that this change might break existing users'
> configs.
> The users already might have a lot of different unimaginable uses of
> this hook such as for example to move a new tab to another position
> on the tab-bar, etc.  Are you sure this change won't break users' configs?
>

[-- Attachment #2: Type: text/html, Size: 1576 bytes --]

bug#74087: Bug patch: invoke tab-bar-tab-post-open-functions during tabs initialization

[Juri Linkov]

close 74087 31.0.50
thanks

>> The only concern here is that this change might break existing users' configs.
>> The users already might have a lot of different unimaginable uses of
>> this hook such as for example to move a new tab to another position
>> on the tab-bar, etc.  Are you sure this change won't break users' configs?
>
> I'd done a search engine search using two engines for any "public" use of
> tab-bar-tab-post-open-functions and found only two cases, both of which
> would be affected positively by the patch. I'm guessing that there aren't a
> lot of people using the hook or the missing call for the initial tab would
> have cropped up sooner.

Thanks for the research.  So now this is pushed to master.

bug#74087: Bug patch: invoke tab-bar-tab-post-open-functions during tabs initialization

[Ship Mints]

[-- Attachment #1: Type: text/plain, Size: 923 bytes --]

Thank you. Would be good to fix this in Emacs 30 if Eli agrees.

On Wed, Oct 30, 2024 at 2:34 PM Juri Linkov <juri@linkov.net> wrote:

> close 74087 31.0.50
> thanks
>
> >> The only concern here is that this change might break existing users'
> configs.
> >> The users already might have a lot of different unimaginable uses of
> >> this hook such as for example to move a new tab to another position
> >> on the tab-bar, etc.  Are you sure this change won't break users'
> configs?
> >
> > I'd done a search engine search using two engines for any "public" use of
> > tab-bar-tab-post-open-functions and found only two cases, both of which
> > would be affected positively by the patch. I'm guessing that there
> aren't a
> > lot of people using the hook or the missing call for the initial tab
> would
> > have cropped up sooner.
>
> Thanks for the research.  So now this is pushed to master.
>

[-- Attachment #2: Type: text/html, Size: 1352 bytes --]

bug#74087: Bug patch: invoke tab-bar-tab-post-open-functions during tabs initialization

[Eli Zaretskii]

> Cc: 74087@debbugs.gnu.org
> From: Ship Mints <shipmints@gmail.com>
> Date: Wed, 30 Oct 2024 14:38:05 -0400
> 
> Thank you. Would be good to fix this in Emacs 30 if Eli agrees.

Fine by me if Juri is okay with that.

bug#74087: Bug patch: invoke tab-bar-tab-post-open-functions during tabs initialization

[Juri Linkov]

>> Cc: 74087@debbugs.gnu.org
>> From: Ship Mints <shipmints@gmail.com>
>> Date: Wed, 30 Oct 2024 14:38:05 -0400
>> 
>> Thank you. Would be good to fix this in Emacs 30 if Eli agrees.
>
> Fine by me if Juri is okay with that.

Ok, backported to emacs-30.

bug#74087: Bug patch: invoke tab-bar-tab-post-open-functions during tabs initialization

[Ship Mints]

[-- Attachment #1: Type: text/plain, Size: 833 bytes --]

You're right about tab-bar-tab-pre-close-functions being called
prematurely. There seem to be almost no calls to it in the wild that I
could find. Now is a good time to correct this.

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

>
> Calling the close hooks currently doesn't look correct:
>
>       (run-hook-with-args 'tab-bar-tab-pre-close-functions
>                           (nth close-index tabs)
>                           last-tab-p)
>       (if last-tab-p
>           (pcase tab-bar-close-last-tab-choice
>             ('nil
>              (user-error "Attempt to delete the sole tab in a frame"))
>
> where first it makes an attempt to close the tab, calls the hook,
> then fails with the user-error.  I think the hook should be called
> when the tab is really closed.
>
>

[-- Attachment #2: Type: text/html, Size: 1293 bytes --]

bug#74087: Bug patch: invoke tab-bar-tab-post-open-functions during tabs initialization

[Juri Linkov]

>>     Calling the close hooks currently doesn't look correct:
>>
>>           (run-hook-with-args 'tab-bar-tab-pre-close-functions
>>                               (nth close-index tabs)
>>                               last-tab-p)
>>           (if last-tab-p
>>               (pcase tab-bar-close-last-tab-choice
>>                 ('nil
>>                  (user-error "Attempt to delete the sole tab in a frame"))
>>
>>     where first it makes an attempt to close the tab, calls the hook,
>>     then fails with the user-error.  I think the hook should be called
>>     when the tab is really closed.
>
> You're right about tab-bar-tab-pre-close-functions being called
> prematurely. There seem to be almost no calls to it in the wild that I
> could find. Now is a good time to correct this.

This could be corrected when someone will ask for it.