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

Previous Next

Package: emacs;

Reported by: Ship Mints <shipmints <at> gmail.com>

Date: Thu, 30 Jan 2025 13:20:02 UTC

Severity: normal

Fixed in version 31.0.50

Done: Juri Linkov <juri <at> linkov.net>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Ship Mints <shipmints <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 75945 <at> debbugs.gnu.org
Subject: 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)]

This bug report was last modified 115 days ago.

Previous Next


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