RE: add Tab to ELPA other-frame-window

RE: add Tab to ELPA other-frame-window

[Drew Adams]

jl>> C-x 7  -  other-window
jl>> C-x 9  -  other-frame
jl>> But I don't know what prefix to propose for other-tab.
jl>> There are no more digits available on the C-x prefix.

sl> I always bind different keys for the prefix anyway
sl> (M-m other-window, M-M other-frame); we could just
sl> define the functions and not choose a default binding.
sl> Or use C-x t; that's free.

"We could just define the functions and not choose
a default binding."

Yes, that's preferable to sacrificing `C-x t' as a
default binding.

Define the commands.  Define keys for them in a
keymap.  But don't bind the keymap to any prefix
key by default.

sm> The choice of a useful yet "safe" default is
sm> not obvious, indeed.
sm> But users can decide to use C-x 3, C-x 6, C-x 5
sm> or whatever they fee like.

Yes, let users decide.

Define a keymap variable, to make it easy to use a
prefix key, but don't bind any prefix key by default.

What's wrong with that?

jl>> but let's hear more opinions before changing
jl>> 'C-x 6' to 'C-x t'.

ez> Agreed.  How about changing to "C-x t" if no one
ez> brings up serious objections within a week?

How about serious supporting arguments?
Have there been any?

FWIW, I don't like the idea.  There's nothing
"free" about `C-x t'.  It doesn't have a default
binding; that's all.  And that's a good thing.

Let users and libraries have it, without them
needing to override standard Emacs default
bindings.  Likewise, other `C-x' keys (`C-x 6'
etc.).

(Just one opinion.)

Tab bar tabs landed on master

[Juri Linkov]

Thanks to everyone for feedback that helped to improve the implementation.
All opinions were taken into account.

Now I've merged the feature/tabs branch into master.  Please try and report
any problems: in compilation and usability.

Additional customization options, minor features and tweaks are expected
to be added in the next few days.

Re: Tab bar tabs landed on master

[Juanma Barranquero]

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

Enabling tab-bar-mode grows the frame's height (not always, just the first
time). Disabling the mode does not shrink it. Is that intended?

(let ((initial (assq 'outer-size (frame-geometry))))
  (tab-bar-mode 1)
  (tab-bar-mode 0)
  (list (assq 'outer-size (frame-geometry)) initial))

=>  ((outer-size 689 . 687) (outer-size 689 . 671))

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

Re: Tab bar tabs landed on master

[Juri Linkov]

> Enabling tab-bar-mode grows the frame's height (not always, just the first
> time). Disabling the mode does not shrink it. Is that intended?

Is this on Windows?

> (let ((initial (assq 'outer-size (frame-geometry))))
>   (tab-bar-mode 1)
>   (tab-bar-mode 0)
>   (list (assq 'outer-size (frame-geometry)) initial))
>
> =>  ((outer-size 689 . 687) (outer-size 689 . 671))

On GNU/Linux it's correct:

=>  ((outer-size 678 . 633) (outer-size 678 . 633))

OTOH, for the tool-bar the problem exists:

(let ((initial (assq 'outer-size (frame-geometry))))
  (tool-bar-mode 1)
  (tool-bar-mode 0)
  (list (assq 'outer-size (frame-geometry)) initial))

=>  ((outer-size 678 . 587) (outer-size 678 . 633))

in both Emacs 27 and GNU Emacs 25.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.21)

Re: Tab bar tabs landed on master

[Ergus]

Hi Juri:

I'm amazed with the new tabs, very thanks!

I would like to ask you the possibility to make the tab-bar-switch-*
commands cyclic (after last go to first) even if not by default? The
problem is that in xterm (and related) it is not possible to sent
C-S-TAB, so in some cases (few tabs) it will be good enough to repeat
C-TAB. Even without this xterm issues it is easier to repeat C-TAB 2 or
3 times than changing the hands to type C-S-TAB.

Very thanks in advance,
Ergus.

On Wed, Oct 02, 2019 at 01:28:57AM +0300, Juri Linkov wrote:
>> Enabling tab-bar-mode grows the frame's height (not always, just the first
>> time). Disabling the mode does not shrink it. Is that intended?
>
>Is this on Windows?
>
>> (let ((initial (assq 'outer-size (frame-geometry))))
>>   (tab-bar-mode 1)
>>   (tab-bar-mode 0)
>>   (list (assq 'outer-size (frame-geometry)) initial))
>>
>> =>  ((outer-size 689 . 687) (outer-size 689 . 671))
>
>On GNU/Linux it's correct:
>
>=>  ((outer-size 678 . 633) (outer-size 678 . 633))
>
>OTOH, for the tool-bar the problem exists:
>
>(let ((initial (assq 'outer-size (frame-geometry))))
>  (tool-bar-mode 1)
>  (tool-bar-mode 0)
>  (list (assq 'outer-size (frame-geometry)) initial))
>
>=>  ((outer-size 678 . 587) (outer-size 678 . 633))
>
>in both Emacs 27 and GNU Emacs 25.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.21)
>

Re: Tab bar tabs landed on master

[Juri Linkov]

> I would like to ask you the possibility to make the tab-bar-switch-*
> commands cyclic (after last go to first) even if not by default? The
> problem is that in xterm (and related) it is not possible to sent
> C-S-TAB, so in some cases (few tabs) it will be good enough to repeat
> C-TAB. Even without this xterm issues it is easier to repeat C-TAB 2 or
> 3 times than changing the hands to type C-S-TAB.

Now cyclic switching implementation is pushed to master.

Some examples of prefix arguments that support cycling:

C-2 C-TAB switches to the second next tab
C-- C-TAB switches to the previous tab

These switching commands interpret their arg as relative offsets.
If you want to select a tab by its absolute position, this is now
possible with e.g.

  (dotimes (i 9)
    (global-set-key (vector (list 'super (+ i 1 ?0)))
                    'tab-bar-select-tab))

I don't know what prefix key or modifier could be used by default,
but this example allows `s-1' to select the first tab
in the tab bar, `s-2' the second, etc.

A new option tab-bar-tab-hints shows absolute positions of tabs
in the tab bar to help in selecting tabs by their numbers.

The same way now the arg is interpreted by tab-close as the absolute
position of tab to close, so e.g.

C-2 C-x 6 0 closes the second tab (instead of the current tab by default)

tab-new could support the prefix argument as well, but
I don't know whether to interpret its numeric prefix argument
as absolute or relative position because both ways are useful:

C-2 C-x 6 2 - could create a new tab as the second tab in the tab-bar

OR

C-2 C-x 6 2 - create a new tab as the second next
              to the right from the current tab
C-u -2 C-x 6 2 - create a new tab as the second previous
                 to the left from the current tab

Maybe to add a rule that if tab-bar-new-tab-to option has a relative value
like 'right' then M-x tab-new should interpret its arg as relative, or if
tab-bar-new-tab-to option has an absolute value like 'rightmost' then M-x
tab-new should interpret arg as absolute?

Or maybe to add a new command tab-add as a wrapper for tab-new
to translate its relative arg to absolute number for tab-new?

Re: Tab bar tabs landed on master

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Sun, 06 Oct 2019 00:55:33 +0300
> Cc: Juanma Barranquero <lekktu@gmail.com>,
>  Emacs developers <emacs-devel@gnu.org>
> 
> Now cyclic switching implementation is pushed to master.
> 
> Some examples of prefix arguments that support cycling:
> 
> C-2 C-TAB switches to the second next tab
> C-- C-TAB switches to the previous tab

This seems to have broken the C-x 6 prefix when invoking commands
without an argument.  E.g., "C-x 6 f" errors out as "undefined" and
"C-x 6 2" invokes 2-Column mode.  I guess this is not intentional?

Btw, it's a pity that C-TAB and C-S-TAB aren't normally supported on
TTY frames.  It would be nice to have a supported short binding, or at
least to have "C-x 6 o" switch to the "other" tab.

Re: Tab bar tabs landed on master

[Juri Linkov]

>> Some examples of prefix arguments that support cycling:
>> 
>> C-2 C-TAB switches to the second next tab
>> C-- C-TAB switches to the previous tab
>
> This seems to have broken the C-x 6 prefix when invoking commands
> without an argument.  E.g., "C-x 6 f" errors out as "undefined" and
> "C-x 6 2" invokes 2-Column mode.  I guess this is not intentional?

Now 2-Column mode uses only its primary mnemonic binding prefix `f2'.
And for backward-compatibility still binds `C-x 6' when its package is loaded.

> Btw, it's a pity that C-TAB and C-S-TAB aren't normally supported on
> TTY frames.  It would be nice to have a supported short binding, or at
> least to have "C-x 6 o" switch to the "other" tab.

Ergus said that in xterm it is possible to use only C-TAB, but not
C-S-TAB.  I tried, and indeed C-TAB works in -nw, and even C-S-TAB
is available as [backtab].  But maybe this is not on all TTY frames,
where 'C-x 6 o' should be the shortest replacement.

Re: Tab bar tabs landed on master

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: spacibba@aol.com,  lekktu@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 06 Oct 2019 21:48:06 +0300
> 
> >> C-2 C-TAB switches to the second next tab
> >> C-- C-TAB switches to the previous tab
> >
> > This seems to have broken the C-x 6 prefix when invoking commands
> > without an argument.  E.g., "C-x 6 f" errors out as "undefined" and
> > "C-x 6 2" invokes 2-Column mode.  I guess this is not intentional?
> 
> Now 2-Column mode uses only its primary mnemonic binding prefix `f2'.
> And for backward-compatibility still binds `C-x 6' when its package is loaded.

Does it mean the tab-bar related "C-x 6" prefix conflicts with 2C?  If
so, perhaps we should use "C-x 7" instead, as long as the genie is not
far from the bottle.  I'd like to avoid backward-incompatible changes
if possible.

> > Btw, it's a pity that C-TAB and C-S-TAB aren't normally supported on
> > TTY frames.  It would be nice to have a supported short binding, or at
> > least to have "C-x 6 o" switch to the "other" tab.
> 
> Ergus said that in xterm it is possible to use only C-TAB, but not
> C-S-TAB.  I tried, and indeed C-TAB works in -nw, and even C-S-TAB
> is available as [backtab].

Don't judge by xterm, it's an exception more than the rule.  Even with
PuTTY (which generally emulates xterm), C-TAB yields nothing in Emacs.

> But maybe this is not on all TTY frames, where 'C-x 6 o' should be
> the shortest replacement.

Yes, I think so.

Thanks.

Re: Tab bar tabs landed on master

[Juri Linkov]

>> >> C-2 C-TAB switches to the second next tab
>> >> C-- C-TAB switches to the previous tab
>> >
>> > This seems to have broken the C-x 6 prefix when invoking commands
>> > without an argument.  E.g., "C-x 6 f" errors out as "undefined" and
>> > "C-x 6 2" invokes 2-Column mode.  I guess this is not intentional?
>>
>> Now 2-Column mode uses only its primary mnemonic binding prefix `f2'.
>> And for backward-compatibility still binds `C-x 6' when its package is loaded.
>
> Does it mean the tab-bar related "C-x 6" prefix conflicts with 2C?  If
> so, perhaps we should use "C-x 7" instead, as long as the genie is not
> far from the bottle.

"C-x 6" is the perfect prefix for tab commands because it's easier to
remember as continuation of the sequence with window prefix "C-x 4"
and frame prefix "C-x 5":

C-x 4 - window commands
C-x 5 - frame commands
C-x 6 - tab commands

> I'd like to avoid backward-incompatible changes if possible.

Actually it's not quite backward-incompatible because it's still
available after loading two-column.el.

Also please read this comment in two-column.el that admits it's not mnemonic:

  ;; This one is for historical reasons and simple keyboards, it is not
  ;; at all mnemonic.  All usual sequences containing 2 were used, and
  ;; f2 could not be set up in a standard way under Emacs 18.
  (global-set-key "\C-x6" '2C-command)

>> > Btw, it's a pity that C-TAB and C-S-TAB aren't normally supported on
>> > TTY frames.  It would be nice to have a supported short binding, or at
>> > least to have "C-x 6 o" switch to the "other" tab.
>>
>> Ergus said that in xterm it is possible to use only C-TAB, but not
>> C-S-TAB.  I tried, and indeed C-TAB works in -nw, and even C-S-TAB
>> is available as [backtab].
>
> Don't judge by xterm, it's an exception more than the rule.  Even with
> PuTTY (which generally emulates xterm), C-TAB yields nothing in Emacs.

And [backtab] can't be used even on xterm, because it's bound to
other commands in some modes, e.g. to Info-prev-reference in Info-mode.

Re: Tab bar tabs landed on master

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: spacibba@aol.com,  lekktu@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 06 Oct 2019 22:23:42 +0300
> 
> > Does it mean the tab-bar related "C-x 6" prefix conflicts with 2C?  If
> > so, perhaps we should use "C-x 7" instead, as long as the genie is not
> > far from the bottle.
> 
> "C-x 6" is the perfect prefix for tab commands because it's easier to
> remember as continuation of the sequence with window prefix "C-x 4"
> and frame prefix "C-x 5":

I agree, but if "C-x 6" is already used, it's taken.  Is it such a
catastrophe to use "C-x 7"?

> > I'd like to avoid backward-incompatible changes if possible.
> 
> Actually it's not quite backward-incompatible because it's still
> available after loading two-column.el.

And then the tab-bar commands cannot be invoked via "C-x 6".  That's
very confusing, I think.  We should avoid a situation where 2 core
packages fight each other over key bindings.

> Also please read this comment in two-column.el that admits it's not mnemonic:
> 
>   ;; This one is for historical reasons and simple keyboards, it is not
>   ;; at all mnemonic.  All usual sequences containing 2 were used, and
>   ;; f2 could not be set up in a standard way under Emacs 18.
>   (global-set-key "\C-x6" '2C-command)

It says nothing about whether people still use it, nor what exactly
"simple keyboards" means.  Sorry, I still think there's a problem
here.

Re: Tab bar tabs landed on master

[Stefan Monnier]

>> "C-x 6" is the perfect prefix for tab commands because it's easier to
>> remember as continuation of the sequence with window prefix "C-x 4"
>> and frame prefix "C-x 5":

Actually, I think it would be a more logical progression to have
C-x 4  -  other-window
C-x 5  -  other-tab
C-x 6  -  other frame

Tho this is mostly for frame-level tabs.  Window-level tabs would
naturally come before all that (i.e. C-x 3). :-(

Which brings me to: could someone look into extending the
`other-frame-window` GNU ELPA package so it also works on tabs?


        Stefan

Re: Tab bar tabs landed on master

[Juri Linkov]

>>> "C-x 6" is the perfect prefix for tab commands because it's easier to
>>> remember as continuation of the sequence with window prefix "C-x 4"
>>> and frame prefix "C-x 5":
>
> Actually, I think it would be a more logical progression to have
> C-x 4  -  other-window
> C-x 5  -  other-tab
> C-x 6  -  other frame
>
> Tho this is mostly for frame-level tabs.  Window-level tabs would
> naturally come before all that (i.e. C-x 3). :-(

BTW, should we also have the variable pop-up-tabs?  I hope not :-)

> Which brings me to: could someone look into extending the
> `other-frame-window` GNU ELPA package so it also works on tabs?

I could help the author of `other-frame-window` to extend it
with tabs.  It uses these prefixes:

C-x 7  -  other-window
C-x 9  -  other-frame

But I don't know what prefix to propose for other-tab.
There are no more digits available on the C-x prefix.

add Tab to ELPA other-frame-window

[Stephen Leake]

Juri Linkov <juri@linkov.net> writes:

>> Which brings me to: could someone look into extending the
>> `other-frame-window` GNU ELPA package so it also works on tabs?
>
> I could help the author 

That's me

> of `other-frame-window` to extend it with tabs. It uses these
> prefixes:
>
> C-x 7  -  other-window
> C-x 9  -  other-frame
>
> But I don't know what prefix to propose for other-tab.
> There are no more digits available on the C-x prefix.

I always bind different keys for the prefix anyway (M-m other-window,
M-M other-frame); we could just define the functions and not choose a
default binding.

Or use C-x t; that's free.

-- 
-- Stephe

Re: add Tab to ELPA other-frame-window

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Date: Sun, 06 Oct 2019 15:58:30 -0700
> 
> Or use C-x t; that's free.

Yes, why don't we do that?  Juri?

Re: add Tab to ELPA other-frame-window

[Juri Linkov]

>>> Which brings me to: could someone look into extending the
>>> `other-frame-window` GNU ELPA package so it also works on tabs?
>>
>> I could help the author
>
> That's me

Glad to help you on extending the package with tabs.

>> of `other-frame-window` to extend it with tabs. It uses these
>> prefixes:
>>
>> C-x 7  -  other-window
>> C-x 9  -  other-frame
>>
>> But I don't know what prefix to propose for other-tab.
>> There are no more digits available on the C-x prefix.
>
> I always bind different keys for the prefix anyway (M-m other-window,
> M-M other-frame); we could just define the functions and not choose a
> default binding.
>
> Or use C-x t; that's free.

I like it, 'C-x t' has nice mnemonics, and on a Qwerty keyboard
't' is located near '6', so 'C-x t' is not harder to type than 'C-x 6',
but let's hear more opinions before changing 'C-x 6' to 'C-x t'.

Re: add Tab to ELPA other-frame-window

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Mon, 07 Oct 2019 23:14:27 +0300
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> > Or use C-x t; that's free.
> 
> I like it, 'C-x t' has nice mnemonics, and on a Qwerty keyboard
> 't' is located near '6', so 'C-x t' is not harder to type than 'C-x 6',
> but let's hear more opinions before changing 'C-x 6' to 'C-x t'.

Agreed.  How about changing to "C-x t" if no one brings up serious
objections within a week?

Re: add Tab to ELPA other-frame-window

[Juri Linkov]

>> > Or use C-x t; that's free.
>> 
>> I like it, 'C-x t' has nice mnemonics, and on a Qwerty keyboard
>> 't' is located near '6', so 'C-x t' is not harder to type than 'C-x 6',
>> but let's hear more opinions before changing 'C-x 6' to 'C-x t'.
>
> Agreed.  How about changing to "C-x t" if no one brings up serious
> objections within a week?

I enabled ‘C-x t’ in master (in addition to ‘C-x 6’) to allow everyone
to try a new keybinding during the next week of transition period
before removing ‘C-x 6’.

Re: add Tab to ELPA other-frame-window

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: stephen_leake@stephe-leake.org,  emacs-devel@gnu.org
> Date: Fri, 11 Oct 2019 01:46:46 +0300
> 
> I enabled ‘C-x t’ in master (in addition to ‘C-x 6’) to allow everyone
> to try a new keybinding during the next week of transition period
> before removing ‘C-x 6’.

Thanks.  I think we should adjust our documentation to this change, at
the end of the week at the latest.

Re: add Tab to ELPA other-frame-window

[Juri Linkov]

>> I enabled ‘C-x t’ in master (in addition to ‘C-x 6’) to allow everyone
>> to try a new keybinding during the next week of transition period
>> before removing ‘C-x 6’.
>
> Thanks.  I think we should adjust our documentation to this change, at
> the end of the week at the latest.

So I removed ‘C-x 6’ in favor of ‘C-x t’ and adjusted the documentation.

Re: add Tab to ELPA other-frame-window

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: stephen_leake@stephe-leake.org,  emacs-devel@gnu.org
> Date: Sun, 20 Oct 2019 01:07:06 +0300
> 
> >> I enabled ‘C-x t’ in master (in addition to ‘C-x 6’) to allow everyone
> >> to try a new keybinding during the next week of transition period
> >> before removing ‘C-x 6’.
> >
> > Thanks.  I think we should adjust our documentation to this change, at
> > the end of the week at the latest.
> 
> So I removed ‘C-x 6’ in favor of ‘C-x t’ and adjusted the documentation.

Thank you.