Tab bar tabs landed on master

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

[Juanma Barranquero]

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

On Wed, Oct 2, 2019 at 12:29 AM Juri Linkov <juri@linkov.net> wrote:

> Is this on Windows?

Yes.

The problem doesn't happen if the frame is maximized in height (with
--fullheight or --fullscreen) because then the frame is, quite logically,
not resized.

> 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))

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

so no problem with tool-bar.

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

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.

Thanks for the suggestion.  I implemented cyclic switching,
but its testing for different use cases takes more time.
I'll commit this tomorrow.

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

[Juri Linkov]

>> > 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"?

"C-x 7" is an illogical key, it breaks the sequence of C-x 4, C-x 5.

>> > 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.

We need to ask the users of 2C how often they use C-x 6.
I believe they are using a more mnemonic key f2.

>> 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.

As the comment in two-column.el explains, a choice of C-x 6 for 2C-command
was just a historic accident.

Using C-x 6 for tabs is more future-proof for next Emacs versions.

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:53:40 +0300
> 
> > I agree, but if "C-x 6" is already used, it's taken.  Is it such a
> > catastrophe to use "C-x 7"?
> 
> "C-x 7" is an illogical key, it breaks the sequence of C-x 4, C-x 5.

Then how about the suggestion to use "C-x t" instead?

> We need to ask the users of 2C how often they use C-x 6.
> I believe they are using a more mnemonic key f2.

Asking them and receiving the answers could take ages.  I don't think
we have that time.  We need to decide soon, because once the emacs-27
branch is cut, it will be harder to make such changes.

Would more people please speak up on this issue, and suggest
alternative prefixes if they have ideas about that?

> As the comment in two-column.el explains, a choice of C-x 6 for 2C-command
> was just a historic accident.

That might be so, but I don't think we can correct that accident
without some transition period.  Which is not possible ion this case.

Re: Tab bar tabs landed on master

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> "C-x 7" is an illogical key, it breaks the sequence of C-x 4, C-x 5.
>
> Then how about the suggestion to use "C-x t" instead?
>
>> We need to ask the users of 2C how often they use C-x 6.
>> I believe they are using a more mnemonic key f2.
>
> Asking them and receiving the answers could take ages.  I don't think
> we have that time.  We need to decide soon, because once the emacs-27
> branch is cut, it will be harder to make such changes.
>
> Would more people please speak up on this issue, and suggest
> alternative prefixes if they have ideas about that?

I'm pretty uninformed about the tab bar stuff, but I would prefer
`C-x t' over `C-x 6'.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Tab bar tabs landed on master

[Ergus]

On Mon, Oct 07, 2019 at 08:18:59PM +0300, Eli Zaretskii wrote:
>> From: Juri Linkov <juri@linkov.net>
>> Cc: spacibba@aol.com,  lekktu@gmail.com,  emacs-devel@gnu.org
>> Date: Sun, 06 Oct 2019 22:53:40 +0300
>>
>> > I agree, but if "C-x 6" is already used, it's taken.  Is it such a
>> > catastrophe to use "C-x 7"?
>>
>> "C-x 7" is an illogical key, it breaks the sequence of C-x 4, C-x 5.
>
>Then how about the suggestion to use "C-x t" instead?
>
>> We need to ask the users of 2C how often they use C-x 6.
>> I believe they are using a more mnemonic key f2.
>
>Asking them and receiving the answers could take ages.  I don't think
>we have that time.  We need to decide soon, because once the emacs-27
>branch is cut, it will be harder to make such changes.
>
>Would more people please speak up on this issue, and suggest
>alternative prefixes if they have ideas about that?
>
Hi:

(Advertisement: personal opinion here)

Call me revolutionary, but I am perfectly fine to set this to `C-x 6`
and move the old one to a better place (when needed) Specially if this
keeps things more organized and `standardized` somehow (easier to
remember/associate).

2C already have something much more "privileged": f2 is short,
exclusive and mnemonic... Very few commands has the privilege to get a
single key binding as 2C already do. Free bindings does not grow like
mushrooms in emacs... ;p

C-x t is "fine", but if breaks the sequence 4 5 6 (which is not a
disaster, but will break the "standard" we have been following up to
now.) In order of priority I will base the decisions:

1- ergonomic
2- mnemonic
2.5- economy of shorter bindings
3- backward compatibility (terminal compatibility/limitations are exception)
4- historical reasons.

So actually I prefer C-x 6 for this feature that potentially may be very
popular for new users as all the browsers and modern applications use
them....

C-x t on the other hand is popular for "term" and similar commands
(better-shell multi-term and so on...) so in the future we should
consider maybe to set it to something related to that if possible.



>> As the comment in two-column.el explains, a choice of C-x 6 for 2C-command
>> was just a historic accident.
>
>That might be so, but I don't think we can correct that accident
>without some transition period.  Which is not possible ion this case.

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.

Re: Tab bar tabs landed on master

[Stefan Monnier]

> 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

I use it with prefix C-x 4 and C-x 5

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

The choice of a useful yet "safe" default is not obvious, indeed.

But users can decide to use C-x 3, C-x 6, C-x 5 or whatever they fee like.


        Stefan

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.

Re: Tab bar tabs landed on master

[Juri Linkov]

> 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

More commands are implemented:

C-2 M-x tab-swap exchanges the current tab with the second tab;
C-2 M-x tab-move moves the current tab two positions to the right;
C-- M-x tab-move moves the current tab one position to the left.

Re: Tab bar tabs landed on master

[Juri Linkov]

>> 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
>
> More commands are implemented:
>
> C-2 M-x tab-swap exchanges the current tab with the second tab;
> C-2 M-x tab-move moves the current tab two positions to the right;
> C-- M-x tab-move moves the current tab one position to the left.

My mistake, browsers only move tabs, not swap them.  So the first now is:

C-2 M-x tab-move-to changes the position of the current tab to be second
(shifting following tabs the to the right).

Re: Tab bar tabs landed on master

[Juri Linkov]

> C-2 M-x tab-move-to changes the position of the current tab to be second
> (shifting following tabs the to the right).

New command:

C-2 M-x tab-recent switches to the second most recently visited tab.

Re: Tab bar tabs landed on master

[Juri Linkov]

>> C-2 M-x tab-move-to changes the position of the current tab to be second
>> (shifting following tabs the to the right).
>
> New command:
>
> C-2 M-x tab-recent switches to the second most recently visited tab.

Like web browsers show two arrow buttons: left to go back in the history
of tab contents, and right to go forward, now tab-bar provides the same
with a new submode tab-bar-history-mode and two arrow buttons in the tab-bar
to navigate history.

Re: Tab bar tabs landed on master

[Juri Linkov]

> 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 t 2 - could create a new tab as the second tab in the tab-bar
>
> OR
>
> C-2 C-x t 2 - create a new tab as the second next
>               to the right from the current tab
> C-u -2 C-x t 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?

Now there are two commands:

C-2 M-x tab-new adds a new tab two positions to the right from the current tab;
C-2 M-x tab-new-to adds a new tab as the second tab in the tab-bar.

Re: Tab bar tabs landed on master

[Ergus]

Hi Juri:

I am trying the tabs in the master branch and with my config it works
fine in tui. But for some reason in GUI, when I create a new tab, emacs
freezes:

I have not reported this as a bug because it only happens with my
config, but I have no idea about what produces this (I don't have
anything too weird in my config).

==================================

In gdb the bt shows:

#0  0x000055addb2b837f in mark_object (arg=<optimized out>) at ../../src/alloc.c:6583
#1  0x000055addb2b8f0e in mark_vectorlike (header=0x7f98b16ae700) at ../../src/alloc.c:6157
#2  0x000055addb2b8373 in mark_object (arg=<optimized out>) at ../../src/alloc.c:6581
#3  0x000055addb2b8f0e in mark_vectorlike (header=0x7f98b16ae660) at ../../src/alloc.c:6157
#4  0x000055addb2b8373 in mark_object (arg=<optimized out>) at ../../src/alloc.c:6581
#5  0x000055addb2b8f0e in mark_vectorlike (header=0x7f98b16ab3f8) at ../../src/alloc.c:6157

(repeats this until)

#1968 0x000055addb2b8f0e in mark_vectorlike (header=0x7f98b167e4e0) at ../../src/alloc.c:6157
#1969 0x000055addb2b8373 in mark_object (arg=<optimized out>) at ../../src/alloc.c:6581
#1970 0x000055addb2b8f0e in mark_vectorlike (header=0x7f98b1bc0f28) at ../../src/alloc.c:6157
#1971 0x000055addb2b8373 in mark_object (arg=<optimized out>) at ../../src/alloc.c:6581
#1972 0x000055addb2b8169 in visit_vectorlike_root (type=GC_ROOT_BUFFER_LOCAL_DEFAULT, ptr=<optimized out>, visitor=...) at ../../src/alloc.c:5693
#1973 0x000055addb2b8169 in visit_buffer_root (type=GC_ROOT_BUFFER_LOCAL_DEFAULT, buffer=<optimized out>, visitor=...) at ../../src/alloc.c:5708
#1974 0x000055addb2b8169 in visit_static_gc_roots (visitor=...) at ../../src/alloc.c:5720
#1975 0x000055addb2b9761 in garbage_collect () at ../../src/alloc.c:5941
#1976 0x000055addb2ba121 in maybe_garbage_collect () at ../../src/alloc.c:5853
#1977 0x000055addb2d6475 in maybe_gc () at ../../src/lisp.h:5061
#1978 0x000055addb2d6475 in Ffuncall (nargs=4, args=0x7ffc4de5fca0) at ../../src/eval.c:2778
#1979 0x000055addb2d9164 in call3 (fn=<optimized out>, arg1=arg1@entry=0x55addd037973, arg2=<optimized out>, arg3=arg3@entry=0x0) at ../../src/eval.c:2668

#1980 0x000055addb265012 in cmd_error_internal (data=data@entry=0x55addd037973, context=context@entry=0x7ffc4de5fd00 "") at ../../src/lisp.h:3935
#1981 0x000055addb26514d in cmd_error (data=0x55addd037973) at ../../src/keyboard.c:953
#1982 0x000055addb2d5719 in internal_condition_case
     (bfun=bfun@entry=0x55addb26e140 <command_loop_1>, handlers=handlers@entry=0x90, hfun=hfun@entry=0x55addb265040 <cmd_error>) at ../../src/eval.c:1351
#1983 0x000055addb25fc24 in command_loop_2 (ignore=ignore@entry=0x0) at ../../src/lisp.h:1032

#1984 0x000055addb2d5681 in internal_catch (tag=tag@entry=0xd4d0, func=func@entry=0x55addb25fc00 <command_loop_2>, arg=arg@entry=0x0) at ../../src/eval.c:1116
#1985 0x000055addb25fbcb in command_loop () at ../../src/lisp.h:1032
#1986 0x000055addb264c56 in recursive_edit_1 () at ../../src/keyboard.c:714
#1987 0x000055addb264f82 in Frecursive_edit () at ../../src/keyboard.c:786
#1988 0x000055addb186910 in main (argc=1, argv=<optimized out>) at ../../src/emacs.c:2055

===================================

See that this stack is too high and it seems to be triggered by the
garbage_collect call, so maybe I am just exposing some issue somewhere
else (maybe in the gc?).

I thought that this happened because I have this in the config:

```
(defun my/minibuffer-setup-hook ()
   (setq gc-cons-threshold most-positive-fixnum))

(defun my/minibuffer-exit-hook ()
   (setq gc-cons-threshold 800000)
   (garbage-collect))

(add-hook 'minibuffer-setup-hook #'my/minibuffer-setup-hook)
(add-hook 'minibuffer-exit-hook #'my/minibuffer-exit-hook)
```

But I commented it and it didn't change anything.

Do you have any idea about where to look to fix this?

Re: Tab bar tabs landed on master

[Eli Zaretskii]

> Date: Sat, 2 Nov 2019 00:13:10 +0100
> From: Ergus <spacibba@aol.com>
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> I am trying the tabs in the master branch and with my config it works
> fine in tui. But for some reason in GUI, when I create a new tab, emacs
> freezes:

Can we please use the bug tracker for reporting and investigating
bugs?  This list is not the right place for that.

> In gdb the bt shows:
> 
> #0  0x000055addb2b837f in mark_object (arg=<optimized out>) at ../../src/alloc.c:6583
> #1  0x000055addb2b8f0e in mark_vectorlike (header=0x7f98b16ae700) at ../../src/alloc.c:6157
> #2  0x000055addb2b8373 in mark_object (arg=<optimized out>) at ../../src/alloc.c:6581
> #3  0x000055addb2b8f0e in mark_vectorlike (header=0x7f98b16ae660) at ../../src/alloc.c:6157
> #4  0x000055addb2b8373 in mark_object (arg=<optimized out>) at ../../src/alloc.c:6581
> #5  0x000055addb2b8f0e in mark_vectorlike (header=0x7f98b16ab3f8) at ../../src/alloc.c:6157

Are you saying that Emacs starts GC and never finishes it?  If you set
garbage-collection-messages non-nil, do you see the message announcing
GC displayed once or many times one after the other?

> I thought that this happened because I have this in the config:
> 
> ```
> (defun my/minibuffer-setup-hook ()
>    (setq gc-cons-threshold most-positive-fixnum))
> 
> (defun my/minibuffer-exit-hook ()
>    (setq gc-cons-threshold 800000)
>    (garbage-collect))
> 
> (add-hook 'minibuffer-setup-hook #'my/minibuffer-setup-hook)
> (add-hook 'minibuffer-exit-hook #'my/minibuffer-exit-hook)
> ```
> 
> But I commented it and it didn't change anything.

Do you have any other GC-related customizations?  They could be in
packages you load, not necessarily in your init files.  What are the
values of gc-cons-threshold and gc-cons-percentage after you comment
out the above parts?

> Do you have any idea about where to look to fix this?

Bisect your init file, if nothing else gives a clue.

And once again, please report this as a bug, and let's continue
discussion on the bug tracker.

Thanks.

Re: Tab bar tabs landed on master

[Ergus]

On Sat, Nov 02, 2019 at 09:20:41AM +0200, Eli Zaretskii wrote:
>
>Can we please use the bug tracker for reporting and investigating
>bugs?  This list is not the right place for that.
>
OK, I didn't because I assumed the error was in my config not in emacs.

>
>Are you saying that Emacs starts GC and never finishes it?  If you set
>garbage-collection-messages non-nil, do you see the message announcing
>GC displayed once or many times one after the other?
>

I found that the error is produced by this lines in my config, but the
bt obviously shows that this is related with something else in the gc:

(set-face-attribute 'tab-bar nil
       :background "#000000" :foreground "#e5e5e5"
       :inverse-video nil)

(set-face-attribute 'tab-bar-tab nil
       :weight 'ultra-bold :underline t)

(set-face-attribute 'tab-bar-tab-inactive nil
       :background "#000000" :foreground "#ffffff"
       :weight 'normal :underline nil)

>
>Do you have any other GC-related customizations?  They could be in
>packages you load, not necessarily in your init files.  What are the
>values of gc-cons-threshold and gc-cons-percentage after you comment
>out the above parts?
>
>> Do you have any idea about where to look to fix this?
>
>Bisect your init file, if nothing else gives a clue.
>
>And once again, please report this as a bug, and let's continue
>discussion on the bug tracker.
>
>Thanks.
>

Re: Tab bar tabs landed on master

[martin rudalics]

 > On GNU/Linux it's correct:

Not with a Motif build.

 > 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)

No problem here.  The first call returns the height including the tool
bar, the second call the height without it.

martin

Re: Tab bar tabs landed on master

[Juri Linkov]

>> On GNU/Linux it's correct:
>
> Not with a Motif build.

I tried to build Lucid and it successfully compiled.
But this problem is not reproducible on Lucid.
Then I tried to rebuild with Motif, but compilation failed with:

../lwlib/liblw.a(lwlib.o): In function `set_one_value':
../lwlib/lwlib.c:529: undefined reference to `lw_lucid_widget_p'
../lwlib/lwlib.c:530: undefined reference to `xlw_update_one_widget'
../lwlib/lwlib.c:537: undefined reference to `lw_xaw_widget_p'
../lwlib/lwlib.c:538: undefined reference to `xaw_update_one_widget'
../lwlib/liblw.a(lwlib.o): In function `instantiate_widget_instance':
../lwlib/lwlib.c:690: undefined reference to `xlw_creation_table'
../lwlib/lwlib.c:698: undefined reference to `xaw_creation_table'
../lwlib/lwlib.c:714: undefined reference to `xaw_create_dialog'
../lwlib/liblw.a(lwlib.o): In function `destroy_one_instance':
../lwlib/lwlib.c:812: undefined reference to `lw_lucid_widget_p'
../lwlib/lwlib.c:813: undefined reference to `xlw_destroy_instance'
../lwlib/lwlib.c:822: undefined reference to `lw_xaw_widget_p'
../lwlib/lwlib.c:823: undefined reference to `xaw_destroy_instance'
../lwlib/liblw.a(lwlib.o): In function `lw_pop_all_widgets':
../lwlib/lwlib.c:940: undefined reference to `lw_lucid_widget_p'
../lwlib/lwlib.c:943: undefined reference to `xlw_pop_instance'
../lwlib/lwlib.c:954: undefined reference to `lw_xaw_widget_p'
../lwlib/lwlib.c:958: undefined reference to `xaw_pop_instance'
../lwlib/liblw.a(lwlib.o): In function `lw_popup_menu':
../lwlib/lwlib.c:980: undefined reference to `lw_lucid_widget_p'
../lwlib/lwlib.c:981: undefined reference to `xlw_popup_menu'
../lwlib/lwlib.c:988: undefined reference to `lw_xaw_widget_p'
../lwlib/lwlib.c:989: undefined reference to `xaw_popup_menu'
../lwlib/liblw.a(lwlib.o): In function `get_one_value':
../lwlib/lwlib.c:1002: undefined reference to `lw_lucid_widget_p'
../lwlib/lwlib.c:1003: undefined reference to `xlw_update_one_value'
../lwlib/lwlib.c:1010: undefined reference to `lw_xaw_widget_p'
../lwlib/lwlib.c:1011: undefined reference to `xaw_update_one_value'
../lwlib/liblw.a(lwlib.o): In function `lw_refigure_widget':
../lwlib/lwlib.c:1179: undefined reference to `XawPanedSetRefigureMode'

Then I used `make clean' in the lwlib directory,
and compilation succeeded.

And indeed, this problem is reproducible with a Motif build.

>> 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)
>
> No problem here.  The first call returns the height including the tool
> bar, the second call the height without it.

Please try running `emacs -Q -f tool-bar-mode' that disables tool-bar-mode
before it's displayed first time.

Re: Tab bar tabs landed on master

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Tue, 1 Oct 2019 23:43:53 +0200
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> 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?

What's worse, this also happens in the -nw session on MS-Windows, and
that makes the session all but unusable, because the echo-area is
mostly invisible, and the mouse clicks don't work, probably because of
the same miscalculation of coordinates.

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?
>
> What's worse, this also happens in the -nw session on MS-Windows, and
> that makes the session all but unusable, because the echo-area is
> mostly invisible, and the mouse clicks don't work, probably because of
> the same miscalculation of coordinates.

Tab-bar code is just a copy of tool-bar code.  And indeed
running `emacs -Q -f tool-bar-mode' that disables tool-bar-mode
exposes the same problem:

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

=> ((outer-size 680 . 693) (outer-size 680 . 676))

The reason why this problem was unknown until now
is because tool-bar-mode is enabled by default.
But disabling it with a command line option
of by using .Xresources causes frame resizing.

So we need to fix it simultaneously for both tool-bar and
tab-bar.  I'd appreciate any help from our experts in
window-related code.

Re: Tab bar tabs landed on master

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Wed, 02 Oct 2019 19:27:47 +0300
> Cc: Juanma Barranquero <lekktu@gmail.com>, emacs-devel@gnu.org
> 
> Tab-bar code is just a copy of tool-bar code.  And indeed
> running `emacs -Q -f tool-bar-mode' that disables tool-bar-mode
> exposes the same problem:
> 
> (let ((initial (assq 'outer-size (frame-geometry))))
>   (tool-bar-mode 1)
>   (tool-bar-mode 0)
>   (list (assq 'outer-size (frame-geometry)) initial))
> 
> => ((outer-size 680 . 693) (outer-size 680 . 676))

I don't see any problem here.  As I understand it, the problem with
tab bars is twofold:

  . turning on tab-bar-mode on GUI frames behaves differently on
    GNU/Linux and MS-Windows

  . turning on tab-bar-mode on TTY frames on MS-Windows produces a
    broken frame

We should fix these problems; what you show for tool bar is not a
problem, but the expected behavior, AFAICT.

Martin, am I right?

Re: Tab bar tabs landed on master

[Juri Linkov]

>   . turning on tab-bar-mode on GUI frames behaves differently on
>     GNU/Linux and MS-Windows

I can reproduce this on GNU/Linux too with a Motif build.
Maybe Martin could help us because the same problem exists
with the tool bar.

>   . turning on tab-bar-mode on TTY frames on MS-Windows produces a
>     broken frame

The latter problem for TTY frames on MS-Windows is fixed now.

Re: Tab bar tabs landed on master

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: lekktu@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 02 Oct 2019 22:55:25 +0300
> 
> >   . turning on tab-bar-mode on TTY frames on MS-Windows produces a
> >     broken frame
> 
> The latter problem for TTY frames on MS-Windows is fixed now.

Thanks.

Can you explain how tab-bar-handle-mouse is supposed to work on TTY
frames with a mouse?  It doesn't work for me on the MS-Windows
console: I get "<nil> <mouse-1> is undefined".  Which makes sense to
me, as I don't see any code which would generate a TAB_BAR_EVENT event
on a TTY, so I thought I need to write code to implement that in the
TTY case.  However, the doc string of tab-bar-handle-mouse seems to
imply that I'm missing something.

Did you try the code on TTY frames with some mouse capability, and if
so, what was your configuration?

Re: Tab bar tabs landed on master

[Juri Linkov]

> Can you explain how tab-bar-handle-mouse is supposed to work on TTY
> frames with a mouse?  It doesn't work for me on the MS-Windows
> console: I get "<nil> <mouse-1> is undefined".  Which makes sense to
> me, as I don't see any code which would generate a TAB_BAR_EVENT event
> on a TTY, so I thought I need to write code to implement that in the
> TTY case.  However, the doc string of tab-bar-handle-mouse seems to
> imply that I'm missing something.

tab-bar-make-keymap-1 binds '(keymap (mouse-1 . tab-bar-handle-mouse))
that on TTY frames accepts mouse clicks anywhere on the tab bar,
and then tab-bar-handle-mouse finds the clicked tab.

> Did you try the code on TTY frames with some mouse capability, and if
> so, what was your configuration?

On TTY frames on GNU/Linux the code works well after enabling
xterm-mouse-mode.  I tried to test it on MS-Windows too, but
can't figure out how to enable mouse on the MS-Windows console.
I was able to run 'emacs -nw' only on winpty.  Could you suggest
how mouse could be enabled on the MS-Windows console?

Re: Tab bar tabs landed on master

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: lekktu@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 06 Oct 2019 01:07:54 +0300
> 
> > Can you explain how tab-bar-handle-mouse is supposed to work on TTY
> > frames with a mouse?  It doesn't work for me on the MS-Windows
> > console: I get "<nil> <mouse-1> is undefined".  Which makes sense to
> > me, as I don't see any code which would generate a TAB_BAR_EVENT event
> > on a TTY, so I thought I need to write code to implement that in the
> > TTY case.  However, the doc string of tab-bar-handle-mouse seems to
> > imply that I'm missing something.
> 
> tab-bar-make-keymap-1 binds '(keymap (mouse-1 . tab-bar-handle-mouse))
> that on TTY frames accepts mouse clicks anywhere on the tab bar,
> and then tab-bar-handle-mouse finds the clicked tab.
> 
> > Did you try the code on TTY frames with some mouse capability, and if
> > so, what was your configuration?
> 
> On TTY frames on GNU/Linux the code works well after enabling
> xterm-mouse-mode.

That means platforms that support TTY mouse on the C level (GPM and
MS-Windows/MS-DOS) will not be able to invoke tab-bar commands with a
mouse, because there's no code that would produce the relevant events
Emacs expects.  xt-mouse bypasses the normal channels of feeding mouse
events to the event queue, so implementation that works with xt-mouse
alone generally doesn't produce the infrastructure required by "real"
mouse support on TTY frames.

> I tried to test it on MS-Windows too, but can't figure out how to
> enable mouse on the MS-Windows console.  I was able to run 'emacs
> -nw' only on winpty.  Could you suggest how mouse could be enabled
> on the MS-Windows console?

It is enabled by default.  Maybe your cmd window has the Quick Edit
mode enabled, in which case mouse events are not reported to console
applications, but instead handled by Windows.  I have now installed
code to disable Quick Edit when Emacs starts, so you shouldn't need to
do that persistently (this option can be controlled in the Properties
of the cmd window).

I also installed support for mouse gestures on the tab bar on
text-mode frames.  It currently only works on MS-Windows, but should
be easy to extend to GPM as well.  Do you have access to a system with
a GPM-capable console, and can compile Emacs with GPM support?  If so,
I will send a patch for you to try (I don't myself have access to such
a system, so I cannot try it myself).

Thanks.

Re: Tab bar tabs landed on master

[Juri Linkov]

> I also installed support for mouse gestures on the tab bar on
> text-mode frames.  It currently only works on MS-Windows, but should
> be easy to extend to GPM as well.

Today I tried TTY mouse support on MS-Windows that you implemented
for the tab bar, and confirm that it works well.

> Do you have access to a system with a GPM-capable console, and can
> compile Emacs with GPM support?  If so, I will send a patch for you to
> try (I don't myself have access to such a system, so I cannot try it
> myself).

I prepared everything needed to test on a GPM-capable console,
so now I'm ready to help you in testing your patch.

Re: Tab bar tabs landed on master

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: lekktu@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 07 Oct 2019 22:15:39 +0300
> 
> > I also installed support for mouse gestures on the tab bar on
> > text-mode frames.  It currently only works on MS-Windows, but should
> > be easy to extend to GPM as well.
> 
> Today I tried TTY mouse support on MS-Windows that you implemented
> for the tab bar, and confirm that it works well.

Thanks for testing.

> > Do you have access to a system with a GPM-capable console, and can
> > compile Emacs with GPM support?  If so, I will send a patch for you to
> > try (I don't myself have access to such a system, so I cannot try it
> > myself).
> 
> I prepared everything needed to test on a GPM-capable console,
> so now I'm ready to help you in testing your patch.

Thanks, I will send a patch soon, probably tomorrow.

Re: Tab bar tabs landed on master

[Eli Zaretskii]

> Date: Mon, 07 Oct 2019 22:23:55 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: lekktu@gmail.com, emacs-devel@gnu.org
> 
> > I prepared everything needed to test on a GPM-capable console,
> > so now I'm ready to help you in testing your patch.
> 
> Thanks, I will send a patch soon, probably tomorrow.

(For some value of "tomorrow".  Sorry for the delay.)

The patch is below, I hope I didn't goof.  Let me know if there are
problems this causes.

It is possible that we will need to force reset of up_modifier bit
from the event modifiers inside tty_handle_tab_bar_click, I'm not
sure.  If you get error messages when clicking on the tab bar saying
something like "<tab-bar> <up-current-tab> is undefined", this is the
reason.

diff --git a/src/term.c b/src/term.c
index 6420105..b60484e 100644
--- a/src/term.c
+++ b/src/term.c
@@ -2568,6 +2568,14 @@ handle_one_term_event (struct tty_display_info *tty, Gpm_Event *event,
   else {
     f->mouse_moved = 0;
     term_mouse_click (&ie, event, f);
+    if (tty_handle_tab_bar_click (f, event->x, event->y,
+				  (ie.modifiers & down_modifier) != 0, &ie))
+      {
+	/* tty_handle_tab_bar_click stores 2 events in the event
+	   queue, so we are done here.  */
+	count += 2;
+	return count;
+      }
   }
 
  done:

Re: Tab bar tabs landed on master

[Juri Linkov]

> The patch is below, I hope I didn't goof.  Let me know if there are
> problems this causes.
>
> It is possible that we will need to force reset of up_modifier bit
> from the event modifiers inside tty_handle_tab_bar_click, I'm not
> sure.  If you get error messages when clicking on the tab bar saying
> something like "<tab-bar> <up-current-tab> is undefined", this is the
> reason.

Today I tried your patch, and observe the following behavior -
typing on a tab displays in the each area:

  tab-bar up-current-tab-

and waits for reading the next event.  Then after typing any key,
e.g. 'x', it displays in the each area:

  <tab-bar> x is undefined

Re: Tab bar tabs landed on master

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: lekktu@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 09 Oct 2019 21:43:25 +0300
> 
> > It is possible that we will need to force reset of up_modifier bit
> > from the event modifiers inside tty_handle_tab_bar_click, I'm not
> > sure.  If you get error messages when clicking on the tab bar saying
> > something like "<tab-bar> <up-current-tab> is undefined", this is the
> > reason.
> 
> Today I tried your patch, and observe the following behavior -
> typing on a tab displays in the each area:
> 
>   tab-bar up-current-tab-
> 
> and waits for reading the next event.

I think this is a sign that the up_modifier needs to be reset from the
event modifiers inside tty_handle_tab_bar_click, as I envisioned.  Can
you try that?

Re: Tab bar tabs landed on master

[Juri Linkov]

>> > It is possible that we will need to force reset of up_modifier bit
>> > from the event modifiers inside tty_handle_tab_bar_click, I'm not
>> > sure.  If you get error messages when clicking on the tab bar saying
>> > something like "<tab-bar> <up-current-tab> is undefined", this is the
>> > reason.
>>
>> Today I tried your patch, and observe the following behavior -
>> typing on a tab displays in the each area:
>>
>>   tab-bar up-current-tab-
>>
>> and waits for reading the next event.
>
> I think this is a sign that the up_modifier needs to be reset from the
> event modifiers inside tty_handle_tab_bar_click, as I envisioned.  Can
> you try that?

Finally I got a chance to test this on a GPM-capable console
(there was a problem that the <Ctrl> key on my keyboard is broken
that is not a problem on X where it's remapped to <CapsLock>,
but on the console only the <Meta> key has an alternative <ESC>,
not <Ctrl>, and using such replacements as 'ESC x next-line RET'
is too cumbersome, ISTR there was some support for key remapping,
and I used it long ago on console, but already forgot all details,
so I had to find a keyboard with a functional <Ctrl> key.)

Anyway, here is the tested patch that indeed needed to reset up_modifier.
Sorry for the delay.

diff --git a/src/term.c b/src/term.c
index 871734318c..a3aef31ec2 100644
--- a/src/term.c
+++ b/src/term.c
@@ -2568,6 +2568,14 @@ handle_one_term_event (struct tty_display_info *tty, Gpm_Event *event,
   else {
     f->mouse_moved = 0;
     term_mouse_click (&ie, event, f);
+    if (tty_handle_tab_bar_click (f, event->x, event->y,
+                                 (ie.modifiers & down_modifier) != 0, &ie))
+      {
+       /* tty_handle_tab_bar_click stores 2 events in the event
+          queue, so we are done here.  */
+       count += 2;
+       return count;
+      }
   }
 
  done:
diff --git a/src/xdisp.c b/src/xdisp.c
index 53300928d7..516013ce4b 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -13516,6 +13516,10 @@ tty_handle_tab_bar_click (struct frame *f, int x, int y, bool down_p,
     f->last_tab_bar_item = prop_idx;
   else
     {
+      /* Force reset of up_modifier bit from the event modifiers.  */
+      if (event->modifiers & up_modifier)
+        event->modifiers &= ~up_modifier;
+
       /* Generate a TAB_BAR_EVENT event.  */
       Lisp_Object frame;
       Lisp_Object key = AREF (f->tab_bar_items,

Re: Tab bar tabs landed on master

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: emacs-devel@gnu.org
> Date: Sun, 12 Jan 2020 01:57:22 +0200
> 
> > I think this is a sign that the up_modifier needs to be reset from the
> > event modifiers inside tty_handle_tab_bar_click, as I envisioned.  Can
> > you try that?
> 
> Finally I got a chance to test this on a GPM-capable console
> (there was a problem that the <Ctrl> key on my keyboard is broken
> that is not a problem on X where it's remapped to <CapsLock>,
> but on the console only the <Meta> key has an alternative <ESC>,
> not <Ctrl>, and using such replacements as 'ESC x next-line RET'
> is too cumbersome, ISTR there was some support for key remapping,
> and I used it long ago on console, but already forgot all details,
> so I had to find a keyboard with a functional <Ctrl> key.)
> 
> Anyway, here is the tested patch that indeed needed to reset up_modifier.
> Sorry for the delay.

Thanks, please push this to the emacs-27 branch.

Re: Tab bar tabs landed on master

[Juri Linkov]

>> Anyway, here is the tested patch that indeed needed to reset up_modifier.
>> Sorry for the delay.
>
> Thanks, please push this to the emacs-27 branch.

Done.  Also I'd like to extend the documentation about tabs.
Whereas it's clear where to describe the recently added tab-bar
features (in the node “Tab Bars” under “Frames”), it's
not so clear where to describe major features of the tab-line.

Currently ‘global-tab-line-mode’ is briefly mentioned
in “Window Convenience” under “Windows” in the same node
together with Winner mode and the Windmove package.

Shouldn't this node be split to more subnodes to describe them
separately like the node “Buffer Convenience” (under “Buffers”)
is already split to subnodes “Icomplete” and “Buffer Menus”?

Re: Tab bar tabs landed on master

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: emacs-devel@gnu.org
> Date: Mon, 13 Jan 2020 01:25:19 +0200
> 
> I'd like to extend the documentation about tabs.
> Whereas it's clear where to describe the recently added tab-bar
> features (in the node “Tab Bars” under “Frames”), it's
> not so clear where to describe major features of the tab-line.

Are those user-level features or Lisp-level features?

For the former, I wonder how much more would you like to tell.  If
just a little, maybe leave that in the current node.  Otherwise, it
should probably warrant its own node.

For the latter, I guess a separate node, like we already have for
"Header Lines", is TRT.

> Shouldn't this node be split to more subnodes to describe them
> separately

It's currently just 49 lines, so I don't think dividing it further is
justified.

Thanks.

Re: Tab bar tabs landed on master

[Juri Linkov]

>> I'd like to extend the documentation about tabs.
>> Whereas it's clear where to describe the recently added tab-bar
>> features (in the node “Tab Bars” under “Frames”), it's
>> not so clear where to describe major features of the tab-line.
>
> Are those user-level features or Lisp-level features?

User-level features.

> For the former, I wonder how much more would you like to tell.  If
> just a little, maybe leave that in the current node.  Otherwise, it
> should probably warrant its own node.

Not too much, but still enough for a separate node, mainly to mention
basic customizable options and also to describe the difference between
tab-bar and tab-line, with cross-references between the node "Tab Bars"
and a new node "Window Tab Lines" (in the Emacs manual).

> For the latter, I guess a separate node, like we already have for
> "Header Lines", is TRT.

Yes, Lisp-level features could have a small node in the Elisp manual
as well like "Header Lines".

>> Shouldn't this node be split to more subnodes to describe them
>> separately
>
> It's currently just 49 lines, so I don't think dividing it further is
> justified.

Than maybe a new node "Window Tab Lines" in the Emacs manual
could be a subnode of "Windows", not subnode of "Window Convenience".

Re: Tab bar tabs landed on master

[Juri Linkov]

>>> I'd like to extend the documentation about tabs.
>>> Whereas it's clear where to describe the recently added tab-bar
>>> features (in the node “Tab Bars” under “Frames”), it's
>>> not so clear where to describe major features of the tab-line.
>>
>> Are those user-level features or Lisp-level features?
>
> User-level features.
>
>> For the former, I wonder how much more would you like to tell.  If
>> just a little, maybe leave that in the current node.  Otherwise, it
>> should probably warrant its own node.
>
> Not too much, but still enough for a separate node, mainly to mention
> basic customizable options and also to describe the difference between
> tab-bar and tab-line, with cross-references between the node "Tab Bars"
> and a new node "Window Tab Lines" (in the Emacs manual).

Like a new node "Image Mode" was created from "File Conveniences",
I could split "Window Convenience" to new node "Window Tab Lines"
to describe all features of global-tab-line-mode.

Also I could describe more features of the Windmove package,
but maybe they will fit into the same node "Window Convenience".

Re: Tab bar tabs landed on master

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: emacs-devel@gnu.org
> Date: Sun, 19 Apr 2020 02:56:08 +0300
> 
> Like a new node "Image Mode" was created from "File Conveniences",
> I could split "Window Convenience" to new node "Window Tab Lines"
> to describe all features of global-tab-line-mode.
> 
> Also I could describe more features of the Windmove package,
> but maybe they will fit into the same node "Window Convenience".

SGTM, thanks.

Re: Tab bar tabs landed on master

[Juri Linkov]

> It is possible that we will need to force reset of up_modifier bit
> from the event modifiers inside tty_handle_tab_bar_click, I'm not
> sure.  If you get error messages when clicking on the tab bar saying
> something like "<tab-bar> <up-current-tab> is undefined", this is the
> reason.
>
> diff --git a/src/term.c b/src/term.c
> index 6420105..b60484e 100644
> --- a/src/term.c
> +++ b/src/term.c
> @@ -2568,6 +2568,14 @@ handle_one_term_event (struct tty_display_info *tty, Gpm_Event *event,
>    else {
>      f->mouse_moved = 0;
>      term_mouse_click (&ie, event, f);
> +    if (tty_handle_tab_bar_click (f, event->x, event->y,
> +				  (ie.modifiers & down_modifier) != 0, &ie))
> +      {
> +	/* tty_handle_tab_bar_click stores 2 events in the event
> +	   queue, so we are done here.  */
> +	count += 2;
> +	return count;
> +      }
>    }
>  
>   done:

I'm still trying to implement this, but after yesterday's commit 2241f7ca7ad,
compilation fails with

emacs/src/term.c:2571: undefined reference to `tty_handle_tab_bar_click'

Not sure why `tty_handle_tab_bar_click' should be defined
only with HAVE_NTGUI && !CYGWIN.

What condition should be added to use tty_handle_tab_bar_click in term.c?
Maybe HAVE_GPM?  Is this change correct?

diff --git a/src/xdisp.c b/src/xdisp.c
index 320e0731de..5ff69bcc77 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -13437,7 +13437,7 @@ tty_get_tab_bar_item (struct frame *f, int x, int *idx, ptrdiff_t *end)
   return Qnil;
 }
 
-#if defined HAVE_NTGUI && !defined CYGWIN
+#if defined HAVE_GPM || (defined HAVE_NTGUI && !defined CYGWIN)
 
 /* Handle a mouse click at X/Y on the tab bar of TTY frame F.  If the
    click was on the tab bar and was handled, populate the EVENT
@@ -13501,7 +13501,7 @@ tty_handle_tab_bar_click (struct frame *f, int x, int y, bool down_p,
 
   return true;
 }
-#endif /* HAVE_NTGUI && !CYGWIN */
+#endif /* HAVE_GPM || (HAVE_NTGUI && !CYGWIN) */
 
 \f
 

Re: Tab bar tabs landed on master

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: lekktu@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 15 Nov 2019 01:37:51 +0200
> 
> > diff --git a/src/term.c b/src/term.c
> > index 6420105..b60484e 100644
> > --- a/src/term.c
> > +++ b/src/term.c
> > @@ -2568,6 +2568,14 @@ handle_one_term_event (struct tty_display_info *tty, Gpm_Event *event,
> >    else {
> >      f->mouse_moved = 0;
> >      term_mouse_click (&ie, event, f);
> > +    if (tty_handle_tab_bar_click (f, event->x, event->y,
> > +				  (ie.modifiers & down_modifier) != 0, &ie))
> > +      {
> > +	/* tty_handle_tab_bar_click stores 2 events in the event
> > +	   queue, so we are done here.  */
> > +	count += 2;
> > +	return count;
> > +      }
> >    }
> >  
> >   done:
> 
> I'm still trying to implement this, but after yesterday's commit 2241f7ca7ad,
> compilation fails with
> 
> emacs/src/term.c:2571: undefined reference to `tty_handle_tab_bar_click'
> 
> Not sure why `tty_handle_tab_bar_click' should be defined
> only with HAVE_NTGUI && !CYGWIN.

It was a mistake to do that, and I've reverted that part.  It should
compile for you now.

> What condition should be added to use tty_handle_tab_bar_click in term.c?
> Maybe HAVE_GPM?  Is this change correct?

There should be no condition at all.  This function is needed by any
build that supports the mouse on TTY frames, and that means all the
platforms we support, at least potentially.

Re: Tab bar tabs landed on master

[martin rudalics]

 >> Tab-bar code is just a copy of tool-bar code.  And indeed
 >> running `emacs -Q -f tool-bar-mode' that disables tool-bar-mode
 >> exposes the same problem:
 >>
 >> (let ((initial (assq 'outer-size (frame-geometry))))
 >>    (tool-bar-mode 1)
 >>    (tool-bar-mode 0)
 >>    (list (assq 'outer-size (frame-geometry)) initial))
 >>
 >> => ((outer-size 680 . 693) (outer-size 680 . 676))
 >
 > I don't see any problem here.  As I understand it, the problem with
 > tab bars is twofold:
 >
 >    . turning on tab-bar-mode on GUI frames behaves differently on
 >      GNU/Linux and MS-Windows
 >
 >    . turning on tab-bar-mode on TTY frames on MS-Windows produces a
 >      broken frame
 >
 > We should fix these problems; what you show for tool bar is not a
 > problem, but the expected behavior, AFAICT.
 >
 > Martin, am I right?

The behavior Juri reports for his GTK build is not right - the values
should be the same.  But I cannot reproduce it here.  And I would not
trust any recipe that asks for display and suppression of an external
widget within two redisplays cycles.  This way madness lies.

But if the behavior is reproducible for emacs -Q -f tool-bar-mode and

(progn
   (tool-bar-mode 1)
   (assq 'outer-size (frame-geometry)))

(progn
   (tool-bar-mode 0)
   (assq 'outer-size (frame-geometry)))

done in separate steps then we indeed have a problem with at least one
window manager.  Bug#16013 and friends are still open ...

martin

Re: Tab bar tabs landed on master

[martin rudalics]

 > Tab-bar code is just a copy of tool-bar code.  And indeed
 > running `emacs -Q -f tool-bar-mode' that disables tool-bar-mode
 > exposes the same problem:
 >
 > (let ((initial (assq 'outer-size (frame-geometry))))
 >    (tool-bar-mode 1)
 >    (tool-bar-mode 0)
 >    (list (assq 'outer-size (frame-geometry)) initial))
 >
 > => ((outer-size 680 . 693) (outer-size 680 . 676))

This gets me ((outer-size 760 . 702) (outer-size 760 . 702)) as
expected.  With a GTK+ Version 3.22.11 build of 2019-10-02.

 > The reason why this problem was unknown until now
 > is because tool-bar-mode is enabled by default.
 > But disabling it with a command line option
 > of by using .Xresources causes frame resizing.
 >
 > So we need to fix it simultaneously for both tool-bar and
 > tab-bar.  I'd appreciate any help from our experts in
 > window-related code.

IIUC your window manager handles things differently and we can try to
work out a solution (and maybe also for 'frame-inhibit-implied-resize'
customizations).  But we really should fix the problems with Motif and
Windows builds.  And Lucid builds too as I was just able to verify ...

martin

Re: Tab bar tabs landed on master

[Stefan Kangas]

Juri Linkov <juri@linkov.net> writes:

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

Congratulations!  Looking forward to testing and using it over the
coming days and weeks.  Two things:

1. You might want to close the long-standing wishlist "bug#5854: editor tabs".

2. On macOS, if anyone has problems getting a working emacs: say "make
bootstrap".

Best regards,
Stefan Kangas

Re: Tab bar tabs landed on master

[Robert Pluim]

>>>>> On Tue, 01 Oct 2019 23:17:48 +0300, Juri Linkov <juri@linkov.net> said:

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

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

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


Iʼve not been following closely; are the tabs supposed to work on
macOS? 'M-x tab-new' doesnʼt seem to do anything for me.

Robert

Re: Tab bar tabs landed on master

[Stefan Kangas]

Juri Linkov <juri@linkov.net> writes:

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

Thanks for that.

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

When I say M-x tab-bar-mode on macOS 10.12, nothing happens besides
seeing the message "Tab-Bar mode enabled".  (M-x global-tab-line-mode
works as expected.)

If support for macOS is not ready, perhaps it should be mentioned in
NEWS?  And perhaps the command should say that this is not supported
if window-system is ns?

Best regards,
Stefan Kangas

Re: Tab bar tabs landed on master

[Stefan Kangas]

Juri Linkov <juri@linkov.net> writes:

>  Please try and report any problems: in compilation and usability.

NEWS says: "Using the mouse wheel on the tab-line scrolls tabs that
display the window buffers."

(Nit-pick: IMO, you could scratch "that display the window buffers"
from that sentence.  I think it's redundant.)

When I try that on macOS, I get these messages:

<tab-line> <wheel-down> is undefined
<tab-line> <double-wheel-down> is undefined
<tab-line> <triple-wheel-down> is undefined [5 times]
<tab-line> <wheel-up> is undefined
<tab-line> <double-wheel-up> is undefined
<tab-line> <triple-wheel-up> is undefined

Best regards,
Stefan Kangas

Re: Tab bar tabs landed on master

[Ergus]

Hi Juri:

Very thanks for the changes.. It works better now in
xterm. (gnome-terminal or urxvt does not send C-TAB... so `C-x 6 o` will
be needed for them). Finding free bindings is always a problem and
keeping backward compatibility or keeping some historical bindings just
for that reason makes the problem worth.

Any way. I have suggested in a Telegram group to try the new tab bar
functionality from master and they are enjoying it. There is only a
complain from a which-key user. When the which-key panel activates the
tab bar displays which-key in it's name. It is not something critical,
but is it there a simple way to correct this?


On Mon, Oct 07, 2019 at 03:21:45PM +0200, Stefan Kangas wrote:
>Juri Linkov <juri@linkov.net> writes:
>
>>  Please try and report any problems: in compilation and usability.
>
>NEWS says: "Using the mouse wheel on the tab-line scrolls tabs that
>display the window buffers."
>
>(Nit-pick: IMO, you could scratch "that display the window buffers"
>from that sentence.  I think it's redundant.)
>
>When I try that on macOS, I get these messages:
>
><tab-line> <wheel-down> is undefined
><tab-line> <double-wheel-down> is undefined
><tab-line> <triple-wheel-down> is undefined [5 times]
><tab-line> <wheel-up> is undefined
><tab-line> <double-wheel-up> is undefined
><tab-line> <triple-wheel-up> is undefined
>
>Best regards,
>Stefan Kangas
>

Re: Tab bar tabs landed on master

[Juri Linkov]

> Any way. I have suggested in a Telegram group to try the new tab bar
> functionality from master and they are enjoying it.

Thanks.

> There is only a complain from a which-key user. When the which-key
> panel activates the tab bar displays which-key in it's name. It is not
> something critical, but is it there a simple way to correct this?

It's possible to use the same fix as recently committed for speedbar:

--- a/lisp/speedbar.el
+++ b/lisp/speedbar.el
@@ -1115,7 +1115,9 @@ speedbar-mode
 	(setq dframe-track-mouse-function #'speedbar-track-mouse))
     (setq dframe-help-echo-function #'speedbar-item-info
 	  dframe-mouse-click-function #'speedbar-click
-	  dframe-mouse-position-function #'speedbar-position-cursor-on-line))
+	  dframe-mouse-position-function #'speedbar-position-cursor-on-line)
+    (setq-local tab-bar-mode nil)
+    (setq-local tab-line-format nil))
   speedbar-buffer)

This will remove tabs from which-key windows.  But maybe you meant
removing the name of the which-key buffer from the tab name?
This will be possible with a new defcustom that I'll finish soon.

Re: Tab bar tabs landed on master

[Ergus]

On Mon, Oct 07, 2019 at 11:23:46PM +0300, Juri Linkov wrote:
>> Any way. I have suggested in a Telegram group to try the new tab bar
>> functionality from master and they are enjoying it.
>
>Thanks.
>
>> There is only a complain from a which-key user. When the which-key
>> panel activates the tab bar displays which-key in it's name. It is not
>> something critical, but is it there a simple way to correct this?
>
>It's possible to use the same fix as recently committed for speedbar:
>
>--- a/lisp/speedbar.el
>+++ b/lisp/speedbar.el
>@@ -1115,7 +1115,9 @@ speedbar-mode
> 	(setq dframe-track-mouse-function #'speedbar-track-mouse))
>     (setq dframe-help-echo-function #'speedbar-item-info
> 	  dframe-mouse-click-function #'speedbar-click
>-	  dframe-mouse-position-function #'speedbar-position-cursor-on-line))
>+	  dframe-mouse-position-function #'speedbar-position-cursor-on-line)
>+    (setq-local tab-bar-mode nil)
>+    (setq-local tab-line-format nil))
>   speedbar-buffer)
>
>This will remove tabs from which-key windows.  But maybe you meant
>removing the name of the which-key buffer from the tab name?
>This will be possible with a new defcustom that I'll finish soon.

Yes I mean that. which-key shouldn't be shown there in any situation. So
maybe when you add the defcustom we will contact the which-key
developers to hint that.

Very thanks... hopefully Eli will fill also the segfault soon.

Re: Tab bar tabs landed on master

[Zach Pearson]

> This will be possible with a new defcustom that I'll finish soon.

Woo! Thanks for the work you’re doing on this. The Treemacs buffer name in particular can get obnoxiously long. 

> On 7 Oct 2019, at 15:23, Juri Linkov <juri@linkov.net> wrote:
> 
>> Any way. I have suggested in a Telegram group to try the new tab bar
>> functionality from master and they are enjoying it.
> 
> Thanks.
> 
>> There is only a complain from a which-key user. When the which-key
>> panel activates the tab bar displays which-key in it's name. It is not
>> something critical, but is it there a simple way to correct this?
> 
> It's possible to use the same fix as recently committed for speedbar:
> 
> --- a/lisp/speedbar.el
> +++ b/lisp/speedbar.el
> @@ -1115,7 +1115,9 @@ speedbar-mode
> 	(setq dframe-track-mouse-function #'speedbar-track-mouse))
>     (setq dframe-help-echo-function #'speedbar-item-info
> 	  dframe-mouse-click-function #'speedbar-click
> -	  dframe-mouse-position-function #'speedbar-position-cursor-on-line))
> +	  dframe-mouse-position-function #'speedbar-position-cursor-on-line)
> +    (setq-local tab-bar-mode nil)
> +    (setq-local tab-line-format nil))
>   speedbar-buffer)
> 
> This will remove tabs from which-key windows.  But maybe you meant
> removing the name of the which-key buffer from the tab name?
> This will be possible with a new defcustom that I'll finish soon.
> 

Re: Tab bar tabs landed on master

[Juri Linkov]

>> This will be possible with a new defcustom that I'll finish soon.
>
> Woo! Thanks for the work you’re doing on this. The Treemacs buffer
> name in particular can get obnoxiously long.

This defcustom is implemented now and pushed.  It makes tab names
much shorter.

Re: Tab bar tabs landed on master

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Tue, 08 Oct 2019 01:29:01 +0300
> Cc: emacs-devel@gnu.org
> 
> >> This will be possible with a new defcustom that I'll finish soon.
> >
> > Woo! Thanks for the work you’re doing on this. The Treemacs buffer
> > name in particular can get obnoxiously long.
> 
> This defcustom is implemented now and pushed.  It makes tab names
> much shorter.

For some reason, buffer names on the tab-bar tabs now all have the
" (1)" suffix.  Is that intentional, and if so, what is the reason?

Thanks.

Re: Tab bar tabs landed on master

[Juri Linkov]

>> This defcustom is implemented now and pushed.  It makes tab names
>> much shorter.
>
> For some reason, buffer names on the tab-bar tabs now all have the
> " (1)" suffix.  Is that intentional, and if so, what is the reason?

This is fixed now to not show the number of windows when there is
only one window in the window configuration.

Re: Tab bar tabs landed on master

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: emacs-devel@gnu.org
> Date: Thu, 10 Oct 2019 01:43:44 +0300
> 
> >> This defcustom is implemented now and pushed.  It makes tab names
> >> much shorter.
> >
> > For some reason, buffer names on the tab-bar tabs now all have the
> > " (1)" suffix.  Is that intentional, and if so, what is the reason?
> 
> This is fixed now to not show the number of windows when there is
> only one window in the window configuration.

Thanks.  So the number indicates how many windows are in the
configuration recorded by the tab?

Re: Tab bar tabs landed on master

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Mon, 7 Oct 2019 15:21:45 +0200
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> NEWS says: "Using the mouse wheel on the tab-line scrolls tabs that
> display the window buffers."
> 
> (Nit-pick: IMO, you could scratch "that display the window buffers"
> from that sentence.  I think it's redundant.)
> 
> When I try that on macOS, I get these messages:
> 
> <tab-line> <wheel-down> is undefined
> <tab-line> <double-wheel-down> is undefined
> <tab-line> <triple-wheel-down> is undefined [5 times]
> <tab-line> <wheel-up> is undefined
> <tab-line> <double-wheel-up> is undefined
> <tab-line> <triple-wheel-up> is undefined

Likewise on MS-Windows.

Re: Tab bar tabs landed on master

[Juri Linkov]

>>  Please try and report any problems: in compilation and usability.
>
> NEWS says: "Using the mouse wheel on the tab-line scrolls tabs that
> display the window buffers."
>
> (Nit-pick: IMO, you could scratch "that display the window buffers"
> from that sentence.  I think it's redundant.)
>
> When I try that on macOS, I get these messages:
>
> <tab-line> <wheel-down> is undefined
> <tab-line> <double-wheel-down> is undefined
> <tab-line> <triple-wheel-down> is undefined [5 times]
> <tab-line> <wheel-up> is undefined
> <tab-line> <double-wheel-up> is undefined
> <tab-line> <triple-wheel-up> is undefined

Do you use wheel-down on the tab-line?  Currently it works only on tabs,
not on empty space between tabs.  Maybe it should also work anywhere on
the tab-line, this will be implemented soon.

Re: Tab bar tabs landed on master

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Mon, 07 Oct 2019 23:19:08 +0300
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > <tab-line> <wheel-down> is undefined
> > <tab-line> <double-wheel-down> is undefined
> > <tab-line> <triple-wheel-down> is undefined [5 times]
> > <tab-line> <wheel-up> is undefined
> > <tab-line> <double-wheel-up> is undefined
> > <tab-line> <triple-wheel-up> is undefined
> 
> Do you use wheel-down on the tab-line?  Currently it works only on tabs,
> not on empty space between tabs.

For me, it doesn't matter where on the tab-line is the mouse when I
turn the wheel, I always see the above error messages.

Re: Tab bar tabs landed on master

[Juri Linkov]

> NEWS says: "Using the mouse wheel on the tab-line scrolls tabs that
> display the window buffers."
>
> (Nit-pick: IMO, you could scratch "that display the window buffers"
> from that sentence.  I think it's redundant.)
>
> When I try that on macOS, I get these messages:
>
> <tab-line> <wheel-down> is undefined
> <tab-line> <double-wheel-down> is undefined
> <tab-line> <triple-wheel-down> is undefined [5 times]
> <tab-line> <wheel-up> is undefined
> <tab-line> <double-wheel-up> is undefined
> <tab-line> <triple-wheel-up> is undefined

Thanks for the feedback, this is fixed now.

Re: Tab bar tabs landed on master

[Ergus]

On Mon, Oct 21, 2019 at 01:39:05AM +0300, Juri Linkov wrote:
>> NEWS says: "Using the mouse wheel on the tab-line scrolls tabs that
>> display the window buffers."
>>
>> (Nit-pick: IMO, you could scratch "that display the window buffers"
>> from that sentence.  I think it's redundant.)
>>
>> When I try that on macOS, I get these messages:
>>
>> <tab-line> <wheel-down> is undefined
>> <tab-line> <double-wheel-down> is undefined
>> <tab-line> <triple-wheel-down> is undefined [5 times]
>> <tab-line> <wheel-up> is undefined
>> <tab-line> <double-wheel-up> is undefined
>> <tab-line> <triple-wheel-up> is undefined
>
>Thanks for the feedback, this is fixed now.
>

Hi Juri:

In tui I still get:

<tab-bar> <mouse-5> is undefined [2 times]
<tab-bar> <mouse-4> is undefined [11 times]
<tab-bar> <mouse-5> is undefined [3 times]
<tab-bar> <mouse-4> is undefined [6 times]
<tab-bar> <mouse-5> is undefined [8 times]
<tab-bar> <mouse-4> is undefined [5 times]

and in gui I get nothing... nothing happens in spite of I pulled the
latest changes you did about this.

Re: Tab bar tabs landed on master

[Eli Zaretskii]

> Date: Mon, 21 Oct 2019 01:06:17 +0200
> From: Ergus <spacibba@aol.com>
> Cc: Stefan Kangas <stefan@marxist.se>, Emacs developers <emacs-devel@gnu.org>
> 
> In tui I still get:
> 
> <tab-bar> <mouse-5> is undefined [2 times]
> <tab-bar> <mouse-4> is undefined [11 times]
> <tab-bar> <mouse-5> is undefined [3 times]
> <tab-bar> <mouse-4> is undefined [6 times]
> <tab-bar> <mouse-5> is undefined [8 times]
> <tab-bar> <mouse-4> is undefined [5 times]
> 
> and in gui I get nothing... nothing happens in spite of I pulled the
> latest changes you did about this.

This is tab bar, not tab-line.  Are you sure you turned the wheel on
the window's tab-line?

Re: Tab bar tabs landed on master

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Mon, 21 Oct 2019 01:39:05 +0300
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > <tab-line> <wheel-down> is undefined
> > <tab-line> <double-wheel-down> is undefined
> > <tab-line> <triple-wheel-down> is undefined [5 times]
> > <tab-line> <wheel-up> is undefined
> > <tab-line> <double-wheel-up> is undefined
> > <tab-line> <triple-wheel-up> is undefined
> 
> Thanks for the feedback, this is fixed now.

It works for me on GUI frames, but the first time I turn the wheel on
the tab-line, a tab for the *Messages* buffer, which wasn't there
before, is added to the buttons.  I think this isn't intended?

Thanks.

Re: Tab bar tabs landed on master

[Juri Linkov]

>> > <tab-line> <wheel-down> is undefined
>> > <tab-line> <double-wheel-down> is undefined
>> > <tab-line> <triple-wheel-down> is undefined [5 times]
>> > <tab-line> <wheel-up> is undefined
>> > <tab-line> <double-wheel-up> is undefined
>> > <tab-line> <triple-wheel-up> is undefined
>>
>> Thanks for the feedback, this is fixed now.
>
> It works for me on GUI frames, but the first time I turn the wheel on
> the tab-line, a tab for the *Messages* buffer, which wasn't there
> before, is added to the buttons.  I think this isn't intended?

This is intended.  Using the wheel on the tab-line is equivalent to
typing C-x <right>.

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.)