Tab bar tabs landed on master

classic Classic list List threaded Threaded
75 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Tab bar tabs landed on master

Juri Linkov-2
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.

Reply | Threaded
Open this post in threaded view
|

Re: Tab bar tabs landed on master

Juanma Barranquero
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))
Reply | Threaded
Open this post in threaded view
|

Re: Tab bar tabs landed on master

Juri Linkov-2
> 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)

Reply | Threaded
Open this post in threaded view
|

Re: Tab bar tabs landed on master

Juanma Barranquero

On Wed, Oct 2, 2019 at 12:29 AM Juri Linkov <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Tab bar tabs landed on master

Ergus
In reply to this post by Juri Linkov-2
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)
>

Reply | Threaded
Open this post in threaded view
|

Re: Tab bar tabs landed on master

martin rudalics
In reply to this post by Juri Linkov-2
 > 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

Reply | Threaded
Open this post in threaded view
|

Re: Tab bar tabs landed on master

Eli Zaretskii
In reply to this post by Juanma Barranquero
> From: Juanma Barranquero <[hidden email]>
> Date: Tue, 1 Oct 2019 23:43:53 +0200
> Cc: Emacs developers <[hidden email]>
>
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Tab bar tabs landed on master

Juri Linkov-2
>> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Tab bar tabs landed on master

Juri Linkov-2
In reply to this post by martin rudalics
>> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Tab bar tabs landed on master

Eli Zaretskii
In reply to this post by Juri Linkov-2
> From: Juri Linkov <[hidden email]>
> Date: Wed, 02 Oct 2019 19:27:47 +0300
> Cc: Juanma Barranquero <[hidden email]>, [hidden email]
>
> 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?

Reply | Threaded
Open this post in threaded view
|

Re: Tab bar tabs landed on master

Juri Linkov-2
>   . 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.

Reply | Threaded
Open this post in threaded view
|

Re: Tab bar tabs landed on master

Stefan Kangas
In reply to this post by Juri Linkov-2
Juri Linkov <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Tab bar tabs landed on master

martin rudalics
In reply to this post by Juri Linkov-2
 > 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

Reply | Threaded
Open this post in threaded view
|

Re: Tab bar tabs landed on master

martin rudalics
In reply to this post by Eli Zaretskii
 >> 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

Reply | Threaded
Open this post in threaded view
|

Re: Tab bar tabs landed on master

Robert Pluim
In reply to this post by Juri Linkov-2
>>>>> On Tue, 01 Oct 2019 23:17:48 +0300, Juri Linkov <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Tab bar tabs landed on master

Andrii Kolomoiets
In reply to this post by Juri Linkov-2
Hi Robet,

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

Try tab-list after tab-new. For me tabs works fine. Just tab bar is not
implemented yet: http://git.savannah.gnu.org/cgit/emacs.git/tree/src/nsfns.m#n617
Reply | Threaded
Open this post in threaded view
|

Re: Tab bar tabs landed on master

Robert Pluim
>>>>> On Thu, 3 Oct 2019 14:23:21 +0300, Andrii Kolomoiets <[hidden email]> said:

    Andrii> Hi Robet,
    >> 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.

    Andrii> Try tab-list after tab-new. For me tabs works fine. Just tab bar is not
    Andrii> implemented yet: http://git.savannah.gnu.org/cgit/emacs.git/tree/src/nsfns.m#n617

OK, I see. Iʼll wait patiently, thereʼs no rush.

Robert

Reply | Threaded
Open this post in threaded view
|

Re: Tab bar tabs landed on master

Juri Linkov-2
In reply to this post by Ergus
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Tab bar tabs landed on master

Eli Zaretskii
In reply to this post by Juri Linkov-2
> From: Juri Linkov <[hidden email]>
> Cc: [hidden email],  [hidden email]
> 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?

Reply | Threaded
Open this post in threaded view
|

Re: Tab bar tabs landed on master

Juri Linkov-2
In reply to this post by Ergus
> 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?

1234