GNU bug report logs - #75945
tab-bar-new-tab-to tab post clone improvement

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 75945 in the body.
You can then email your comments to 75945 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: tab-bar-new-tab-to tab post clone improvement
Date: Thu, 30 Jan 2025 08:17:28 -0500

[Message part 1 (text/plain, inline)]

The existing hooks: post open, post close, post clone (patch submitted),
are insufficient in the tab clone case where users employ custom tab
parameters. Such tab parameters often need post-clone curation. In my case,
cumbersome tab-bar advice is needed to work around cloning. Others might
experience the same need.

I see a few ways we can help address this. Once we agree on an approach,
I'm happy to submit a patch.

1. Alter tab-bar-tab-post-open-functions to accept an optional second
argument, namely, the originating tab, iff tab-bar-new-tab-choice 'clone.

2. Create a new hook tab-bar-post-duplicate-tab-functions, the functions of
which accept two arguments: the originating tab, the cloned tab, and where
the hook runs iff tab-bar-new-tab-choice 'clone.

3. In harmony with clone-frame, tab-bar could propagate tab parameters to a
cloned tab (it already saves them naturally, for use in undo close tab),
modulo internal tab-bar parameters. A post-clone hook would still be needed
to allow a user to control their custom parameters. (A new post undo-close
tab hook patch is pending to support the undo case.)

4. In pseudo harmony with clone-frame, add
tab-bar-duplicate-tab-clone-parameters-functions hook, the user-provided
functions of which would accept the originating tab, and return the list of
parameters to clone.

My preference is 1, the simplest, but I can be persuaded that another on
this list, or a different one entirely, is acceptable.

-Stephane

[Message part 2 (text/html, inline)]

Message #8 received at 75945 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 75945 <at> debbugs.gnu.org
Subject: Re: bug#75945: tab-bar-new-tab-to tab post clone improvement
Date: Thu, 30 Jan 2025 19:49:40 +0200

> The existing hooks: post open, post close, post clone (patch submitted),
> are insufficient in the tab clone case where users employ custom tab
> parameters. Such tab parameters often need post-clone curation. In my case,
> cumbersome tab-bar advice is needed to work around cloning. Others might
> experience the same need.
>
> I see a few ways we can help address this. Once we agree on an approach,
> I'm happy to submit a patch.
>
> 1. Alter tab-bar-tab-post-open-functions to accept an optional second
> argument, namely, the originating tab, iff tab-bar-new-tab-choice 'clone.

Adding a new argument will break the existing uses.  This could be
avoided by using (condition-case ... (wrong-number-of-arguments ...)).

But much simpler would be just to check the dynamically bound value
in the hook, e.g.:

(add-hook 'tab-bar-tab-post-open-functions
	  (lambda (tab)
	    (when (eq tab-bar-new-tab-choice 'clone)
	      (message "Cloned tab %S" tab))))

> 2. Create a new hook tab-bar-post-duplicate-tab-functions, the functions of
> which accept two arguments: the originating tab, the cloned tab, and where
> the hook runs iff tab-bar-new-tab-choice 'clone.

The existing hook tab-bar-tab-post-open-functions doesn't accept the
originating tab.  But still it's possible to get the originating tab
using tab-bar--tab-index-recent.

> 3. In harmony with clone-frame, tab-bar could propagate tab parameters to a
> cloned tab (it already saves them naturally, for use in undo close tab),
> modulo internal tab-bar parameters. A post-clone hook would still be needed
> to allow a user to control their custom parameters. (A new post undo-close
> tab hook patch is pending to support the undo case.)

A cloned tab already inherits the group with tab-bar-new-tab-group.

And it's easy to get other parameters from the originating tab using
tab-bar--tab-index-recent in the tab-bar-tab-post-open-functions hook.

Message #11 received at 75945 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 75945 <at> debbugs.gnu.org
Subject: Re: bug#75945: tab-bar-new-tab-to tab post clone improvement
Date: Thu, 30 Jan 2025 13:09:45 -0500

[Message part 1 (text/plain, inline)]

That trick works, if a bit circuitous. Thank you.

Is it really the case that adding an &optional argument to a hook function
breaks those that accept only the mandatory arguments?

On Thu, Jan 30, 2025 at 12:52 PM Juri Linkov <juri <at> linkov.net> wrote:

> > The existing hooks: post open, post close, post clone (patch submitted),
> > are insufficient in the tab clone case where users employ custom tab
> > parameters. Such tab parameters often need post-clone curation. In my
> case,
> > cumbersome tab-bar advice is needed to work around cloning. Others might
> > experience the same need.
> >
> > I see a few ways we can help address this. Once we agree on an approach,
> > I'm happy to submit a patch.
> >
> > 1. Alter tab-bar-tab-post-open-functions to accept an optional second
> > argument, namely, the originating tab, iff tab-bar-new-tab-choice 'clone.
>
> Adding a new argument will break the existing uses.  This could be
> avoided by using (condition-case ... (wrong-number-of-arguments ...)).
>
> But much simpler would be just to check the dynamically bound value
> in the hook, e.g.:
>
> (add-hook 'tab-bar-tab-post-open-functions
>           (lambda (tab)
>             (when (eq tab-bar-new-tab-choice 'clone)
>               (message "Cloned tab %S" tab))))
>
> > 2. Create a new hook tab-bar-post-duplicate-tab-functions, the functions
> of
> > which accept two arguments: the originating tab, the cloned tab, and
> where
> > the hook runs iff tab-bar-new-tab-choice 'clone.
>
> The existing hook tab-bar-tab-post-open-functions doesn't accept the
> originating tab.  But still it's possible to get the originating tab
> using tab-bar--tab-index-recent.
>
> > 3. In harmony with clone-frame, tab-bar could propagate tab parameters
> to a
> > cloned tab (it already saves them naturally, for use in undo close tab),
> > modulo internal tab-bar parameters. A post-clone hook would still be
> needed
> > to allow a user to control their custom parameters. (A new post
> undo-close
> > tab hook patch is pending to support the undo case.)
>
> A cloned tab already inherits the group with tab-bar-new-tab-group.
>
> And it's easy to get other parameters from the originating tab using
> tab-bar--tab-index-recent in the tab-bar-tab-post-open-functions hook.
>

[Message part 2 (text/html, inline)]

Message #14 received at 75945 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 75945 <at> debbugs.gnu.org
Subject: Re: bug#75945: tab-bar-new-tab-to tab post clone improvement
Date: Thu, 30 Jan 2025 20:45:13 +0200

close 75945 31.0.50
thanks

> That trick works, if a bit circuitous. Thank you.

Ok, then let's close this report.

> Is it really the case that adding an &optional argument to a hook function
> breaks those that accept only the mandatory arguments?

The caller needs to provide the optional argument in any case.
But the user still has only mandatory arguments.
Therefore the error with wrong number of arguments.

A precautious user could add '&rest args' to the end of ALL own hook
functions for the case when the callers decide to add more arguments.
Then for the caller it would be safe to call the hook
with any number of arguments.

Message #19 received at 75945 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 75945 <at> debbugs.gnu.org
Subject: Re: bug#75945: tab-bar-new-tab-to tab post clone improvement
Date: Thu, 30 Jan 2025 14:05:55 -0500

[Message part 1 (text/plain, inline)]

Right, right. It's not a pattern we can expect people to follow at this
stage of Emacs evolution and popularity.

On Thu, Jan 30, 2025 at 1:47 PM Juri Linkov <juri <at> linkov.net> wrote:

> close 75945 31.0.50
> thanks
>
> > That trick works, if a bit circuitous. Thank you.
>
> Ok, then let's close this report.
>
> > Is it really the case that adding an &optional argument to a hook
> function
> > breaks those that accept only the mandatory arguments?
>
> The caller needs to provide the optional argument in any case.
> But the user still has only mandatory arguments.
> Therefore the error with wrong number of arguments.
>
> A precautious user could add '&rest args' to the end of ALL own hook
> functions for the case when the callers decide to add more arguments.
> Then for the caller it would be safe to call the hook
> with any number of arguments.
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.