Hi Juri,

Juri Linkov <juri@linkov.net> writes:

> Thanks.  The command 'tab-bar-move-tab-to-frame' was intended
> to do exactly this.  If it doesn't, then it would be better
> to fix it, for example, by improving its 'interactive' spec, etc.
> Then you can add an alias 'tab-bar-detach-tab' to it.

Looking at that command, I'm not sure how to change its interactive spec
to move a tab to a new frame without changing the command's documented
behavior.  But using it to do the work of moving a tab to a new frame
created by another command is straightforward and easy for me to
understand.  :)

I've attached a new patch for your consideration.  It seems to work
correctly (correcting the issue Matt noted), and it also adds the new
command to the tab bar context menu.  If you'd still prefer to change
'tab-bar-move-tab-to-frame' to accomodate this functionality, I'm not
sure what you have in mind.

>> It might be worth binding it to something like "C-x t D" as well,
>> assuming the command is worth merging.  :)
>
> Currently I'm developing a command that will detach a window
> to a new tab, i.e. it will delete the selected window
> from the current tab after moving it to the new tab.
> And I'd like to add a keybinding to it with the same mnemonics "D" :-)

Hm, what if the new window-detaching command were on "C-x t d", and the
new tab-detaching command were on "C-x t D"?  Of course, "C-x t d" is
currently bound to 'dired-other-tab', but it seems like that should be
covered by 'other-tab-prefix', i.e. "C-x t t C-x d".