GNU logs - #75945, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#75945: tab-bar-new-tab-to tab post clone improvement
Resent-From: Ship Mints <shipmints@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 30 Jan 2025 13:20:02 +0000
Resent-Message-ID: <handler.75945.B.173824318723701 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 75945 <at> debbugs.gnu.org, juri@HIDDEN
MIME-Version: 1.0
From: Ship Mints <shipmints@HIDDEN>
Date: Thu, 30 Jan 2025 08:17:28 -0500
Message-ID: <CAN+1Hbp4cCY08yzayQDinqGqjjOYQK_wd5XKpg2t9J+ox-Zn_g@HIDDEN>
Content-Type: multipart/alternative; boundary="00000000000010e5f8062cec46e3"
Received-SPF: pass client-ip=2607:f8b0:4864:20::92a;
 envelope-from=shipmints@HIDDEN; helo=mail-ua1-x92a.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

--00000000000010e5f8062cec46e3
Content-Type: text/plain; charset="UTF-8"

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

--00000000000010e5f8062cec46e3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e">The existing hooks: post open, post close, post clone (patch submitted),=
 are insufficient in the tab clone case where users=C2=A0employ 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 e=
xperience the same need.</div><div class=3D"gmail_default" style=3D"font-fa=
mily:monospace"><br></div><div class=3D"gmail_default" style=3D"font-family=
:monospace">I see a few ways we can help address this. Once we agree on an =
approach, I&#39;m happy to submit a patch.</div><div class=3D"gmail_default=
" style=3D"font-family:monospace"><br></div><div class=3D"gmail_default" st=
yle=3D"font-family:monospace">1. Alter tab-bar-tab-post-open-functions to a=
ccept an optional second argument, namely, the originating tab, iff tab-bar=
-new-tab-choice &#39;clone.<br></div><div class=3D"gmail_default" style=3D"=
font-family:monospace"><br></div><div class=3D"gmail_default" style=3D"font=
-family:monospace">2. Create a new hook tab-bar-post-duplicate-tab-function=
s, the functions of which accept two arguments: the originating tab, the cl=
oned tab, and where the hook runs=C2=A0iff tab-bar-new-tab-choice &#39;clon=
e.</div><div class=3D"gmail_default" style=3D"font-family:monospace"><br>3.=
=C2=A0In harmony with clone-frame, tab-bar could propagate tab parameters t=
o 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 need=
ed to allow a user to control their custom parameters. (A new post undo-clo=
se tab hook patch is pending to support the undo case.)</div><div class=3D"=
gmail_default" style=3D"font-family:monospace"><br></div><div class=3D"gmai=
l_default" style=3D"font-family:monospace">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 th=
e list of parameters to clone.</div><div class=3D"gmail_default" style=3D"f=
ont-family:monospace"><br></div><div class=3D"gmail_default" style=3D"font-=
family:monospace">My preference is 1, the simplest, but I can be persuaded =
that another on this list, or a different one entirely, is acceptable.</div=
><div class=3D"gmail_default" style=3D"font-family:monospace"><br></div><di=
v class=3D"gmail_default" style=3D"font-family:monospace">-Stephane</div></=
div>

--00000000000010e5f8062cec46e3--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Ship Mints <shipmints@HIDDEN>
Subject: bug#75945: Acknowledgement (tab-bar-new-tab-to tab post clone
 improvement)
Message-ID: <handler.75945.B.173824318723701.ack <at> debbugs.gnu.org>
References: <CAN+1Hbp4cCY08yzayQDinqGqjjOYQK_wd5XKpg2t9J+ox-Zn_g@HIDDEN>
X-Gnu-PR-Message: ack 75945
X-Gnu-PR-Package: emacs
Reply-To: 75945 <at> debbugs.gnu.org
Date: Thu, 30 Jan 2025 13:20:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 75945 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
75945: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D75945
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#75945: tab-bar-new-tab-to tab post clone improvement
Resent-From: Juri Linkov <juri@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 30 Jan 2025 17:53:02 +0000
Resent-Message-ID: <handler.75945.B75945.173825955824918 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Ship Mints <shipmints@HIDDEN>
Cc: 75945 <at> debbugs.gnu.org
From: Juri Linkov <juri@HIDDEN>
In-Reply-To: <CAN+1Hbp4cCY08yzayQDinqGqjjOYQK_wd5XKpg2t9J+ox-Zn_g@HIDDEN>
 (Ship Mints's message of "Thu, 30 Jan 2025 08:17:28 -0500")
Organization: LINKOV.NET
References: <CAN+1Hbp4cCY08yzayQDinqGqjjOYQK_wd5XKpg2t9J+ox-Zn_g@HIDDEN>
Date: Thu, 30 Jan 2025 19:49:40 +0200
Message-ID: <87v7twtcnf.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> 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 sent to bug-gnu-emacs@HIDDEN:

Subject: bug#75945: tab-bar-new-tab-to tab post clone improvement
Resent-From: Ship Mints <shipmints@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 30 Jan 2025 18:12:02 +0000
Resent-Message-ID: <handler.75945.B75945.173826070628349 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Juri Linkov <juri@HIDDEN>
Cc: 75945 <at> debbugs.gnu.org
MIME-Version: 1.0
References: <CAN+1Hbp4cCY08yzayQDinqGqjjOYQK_wd5XKpg2t9J+ox-Zn_g@HIDDEN>
 <87v7twtcnf.fsf@HIDDEN>
In-Reply-To: <87v7twtcnf.fsf@HIDDEN>
From: Ship Mints <shipmints@HIDDEN>
Date: Thu, 30 Jan 2025 13:09:45 -0500
Message-ID: <CAN+1Hbp=57W4Rf5E-RNTVy+0GDv=dpOp4OugubtML96s2YJRAg@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000005f0943062cf05bbd"
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--0000000000005f0943062cf05bbd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFPM Juri Linkov <juri@HIDDEN> wrot=
e:

> > 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 migh=
t
> > 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 'clon=
e.
>
> 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 function=
s
> 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.
>

--0000000000005f0943062cf05bbd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e">That trick works,=C2=A0if a bit circuitous. Thank you.</div><div class=
=3D"gmail_default" style=3D"font-family:monospace"><br></div><div class=3D"=
gmail_default" style=3D"font-family:monospace">Is it really the case that a=
dding an &amp;optional argument to a hook function breaks those that accept=
 only the mandatory arguments?</div></div><br><div class=3D"gmail_quote gma=
il_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jan 30, 2=
025 at 12:52=E2=80=AFPM Juri Linkov &lt;<a href=3D"mailto:juri@HIDDEN">=
juri@HIDDEN</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">&gt; The existing hooks: post open, post close, post clone (=
patch submitted),<br>
&gt; are insufficient in the tab clone case where users employ custom tab<b=
r>
&gt; parameters. Such tab parameters often need post-clone curation. In my =
case,<br>
&gt; cumbersome tab-bar advice is needed to work around cloning. Others mig=
ht<br>
&gt; experience the same need.<br>
&gt;<br>
&gt; I see a few ways we can help address this. Once we agree on an approac=
h,<br>
&gt; I&#39;m happy to submit a patch.<br>
&gt;<br>
&gt; 1. Alter tab-bar-tab-post-open-functions to accept an optional second<=
br>
&gt; argument, namely, the originating tab, iff tab-bar-new-tab-choice &#39=
;clone.<br>
<br>
Adding a new argument will break the existing uses.=C2=A0 This could be<br>
avoided by using (condition-case ... (wrong-number-of-arguments ...)).<br>
<br>
But much simpler would be just to check the dynamically bound value<br>
in the hook, e.g.:<br>
<br>
(add-hook &#39;tab-bar-tab-post-open-functions<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (lambda (tab)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (when (eq tab-bar-new-tab-choice =
&#39;clone)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (message &quot;Cloned tab =
%S&quot; tab))))<br>
<br>
&gt; 2. Create a new hook tab-bar-post-duplicate-tab-functions, the functio=
ns of<br>
&gt; which accept two arguments: the originating tab, the cloned tab, and w=
here<br>
&gt; the hook runs iff tab-bar-new-tab-choice &#39;clone.<br>
<br>
The existing hook tab-bar-tab-post-open-functions doesn&#39;t accept the<br=
>
originating tab.=C2=A0 But still it&#39;s possible to get the originating t=
ab<br>
using tab-bar--tab-index-recent.<br>
<br>
&gt; 3. In harmony with clone-frame, tab-bar could propagate tab parameters=
 to a<br>
&gt; cloned tab (it already saves them naturally, for use in undo close tab=
),<br>
&gt; modulo internal tab-bar parameters. A post-clone hook would still be n=
eeded<br>
&gt; to allow a user to control their custom parameters. (A new post undo-c=
lose<br>
&gt; tab hook patch is pending to support the undo case.)<br>
<br>
A cloned tab already inherits the group with tab-bar-new-tab-group.<br>
<br>
And it&#39;s easy to get other parameters from the originating tab using<br=
>
tab-bar--tab-index-recent in the tab-bar-tab-post-open-functions hook.<br>
</blockquote></div>

--0000000000005f0943062cf05bbd--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#75945: tab-bar-new-tab-to tab post clone improvement
Resent-From: Juri Linkov <juri@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 30 Jan 2025 18:48:01 +0000
Resent-Message-ID: <handler.75945.B75945.173826284513839 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 75945
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ship Mints <shipmints@HIDDEN>
Cc: 75945 <at> debbugs.gnu.org
Received: via spool by 75945-submit <at> debbugs.gnu.org id=B75945.173826284513839
          (code B ref 75945); Thu, 30 Jan 2025 18:48:01 +0000
Received: (at 75945) by debbugs.gnu.org; 30 Jan 2025 18:47:25 +0000
Received: from localhost ([127.0.0.1]:47799 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tdZZV-0003b9-30
	for submit <at> debbugs.gnu.org; Thu, 30 Jan 2025 13:47:25 -0500
Received: from relay6-d.mail.gandi.net ([217.70.183.198]:51239)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <juri@HIDDEN>)
 id 1tdZZS-0003ar-Rk; Thu, 30 Jan 2025 13:47:23 -0500
Received: by mail.gandi.net (Postfix) with ESMTPSA id 4DEA9442A6;
 Thu, 30 Jan 2025 18:47:15 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
In-Reply-To: <CAN+1Hbp=57W4Rf5E-RNTVy+0GDv=dpOp4OugubtML96s2YJRAg@HIDDEN>
 (Ship Mints's message of "Thu, 30 Jan 2025 13:09:45 -0500")
Organization: LINKOV.NET
References: <CAN+1Hbp4cCY08yzayQDinqGqjjOYQK_wd5XKpg2t9J+ox-Zn_g@HIDDEN>
 <87v7twtcnf.fsf@HIDDEN>
 <CAN+1Hbp=57W4Rf5E-RNTVy+0GDv=dpOp4OugubtML96s2YJRAg@HIDDEN>
Date: Thu, 30 Jan 2025 20:45:13 +0200
Message-ID: <87jzacrvie.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-State: clean
X-GND-Score: -100
X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeiheekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufgjohhffffkfgggtgesthdtredttdertdenucfhrhhomheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqeenucggtffrrghtthgvrhhnpeffgeetfeevlefhleejfeeuheeiudeitdffhfdutdekfeffgffhveehteegueekheenucfkphepledurdduvdelrdeliedrledtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepledurdduvdelrdeliedrledtpdhhvghlohepmhgrihhlrdhgrghnughirdhnvghtpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhgspghrtghpthhtohepfedprhgtphhtthhopegtohhnthhrohhlseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtohepjeehleegheesuggvsggsuhhgshdrghhnuhdrohhrghdprhgtphhtthhopehshhhiphhmihhnthhssehgmhgrihhlrdgtohhm
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

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 received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 30 Jan 2025 18:47:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 30 13:47:33 2025
Received: from localhost ([127.0.0.1]:47801 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tdZZc-0003bM-KZ
	for submit <at> debbugs.gnu.org; Thu, 30 Jan 2025 13:47:32 -0500
Received: from relay6-d.mail.gandi.net ([217.70.183.198]:51239)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <juri@HIDDEN>)
 id 1tdZZS-0003ar-Rk; Thu, 30 Jan 2025 13:47:23 -0500
Received: by mail.gandi.net (Postfix) with ESMTPSA id 4DEA9442A6;
 Thu, 30 Jan 2025 18:47:15 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Ship Mints <shipmints@HIDDEN>
Subject: Re: bug#75945: tab-bar-new-tab-to tab post clone improvement
In-Reply-To: <CAN+1Hbp=57W4Rf5E-RNTVy+0GDv=dpOp4OugubtML96s2YJRAg@HIDDEN>
 (Ship Mints's message of "Thu, 30 Jan 2025 13:09:45 -0500")
Organization: LINKOV.NET
References: <CAN+1Hbp4cCY08yzayQDinqGqjjOYQK_wd5XKpg2t9J+ox-Zn_g@HIDDEN>
 <87v7twtcnf.fsf@HIDDEN>
 <CAN+1Hbp=57W4Rf5E-RNTVy+0GDv=dpOp4OugubtML96s2YJRAg@HIDDEN>
Date: Thu, 30 Jan 2025 20:45:13 +0200
Message-ID: <87jzacrvie.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-State: clean
X-GND-Score: -100
X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdeiheekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufgjohhffffkfgggtgesthdtredttdertdenucfhrhhomheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqeenucggtffrrghtthgvrhhnpeffgeetfeevlefhleejfeeuheeiudeitdffhfdutdekfeffgffhveehteegueekheenucfkphepledurdduvdelrdeliedrledtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepledurdduvdelrdeliedrledtpdhhvghlohepmhgrihhlrdhgrghnughirdhnvghtpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhgspghrtghpthhtohepfedprhgtphhtthhopegtohhnthhrohhlseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtohepjeehleegheesuggvsggsuhhgshdrghhnuhdrohhrghdprhgtphhtthhopehshhhiphhmihhnthhssehgmhgrihhlrdgtohhm
X-GND-Sasl: juri@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: control
Cc: 75945 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

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.

Last modified: Thu, 30 Jan 2025 19:00:02 UTC

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