Re: Tabs

Re: Tabs

[Angelo Graziosi]

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

I am an old user of 'tabbar-ruler' and friends from MELPA (https://melpa.org/#/tabbar-ruler) and have built your branch on Windows with the following results.

First, I tried this:

> 1. M-x tab-bar-mode RET
> 2. Click on the plus sign to create a new tab

I get the image tab-bar-mode.png (see tar-ball attached) and haven't understood much how to use it

> 3. Click on the previous tab
> 4. Click on the close icon
>

Then tried this, and the result is global-tab.png: notice, usually, Emacs here starts restoring about 65 buffers

> 1. M-x global-tab-line-mode
> 2. Click on the plus sign and select a buffer to create a new tab
> 3. Click on the previous tab
> 4. Click on the close icon
>

For comparison, with the same configuration (65 buffers) the result with tabbar-ruler from MELPA is tabbar-ruler.png: notice how the selected tab is highlighted compared to the others.

Tabbar-ruler allow for grouping per mode, see tabbar-ruler-permode.png.

Tanks for this work,
  Angelo.

[-- Attachment #2: tabs-img.tar.gz --]
[-- Type: application/x-gzip, Size: 32857 bytes --]

Re: Tabs

[Juri Linkov]

> I am an old user of 'tabbar-ruler' and friends from MELPA
> (https://melpa.org/#/tabbar-ruler) and have built your branch on
> Windows with the following results.

You mean all your screenshots were taken on Windows?
This is good news.  This means after blindly changing
Windows related code without testing it just works.

> First, I tried this:
>
>> 1. M-x tab-bar-mode RET
>> 2. Click on the plus sign to create a new tab
>
> I get the image tab-bar-mode.png (see tar-ball attached) and haven't
> understood much how to use it

Please try to click on the plus sign.  Does it work?

>> 3. Click on the previous tab
>> 4. Click on the close icon
>
> Then tried this, and the result is global-tab.png: notice, usually,
> Emacs here starts restoring about 65 buffers

Have you visited all these 65 buffers in the same window?

Re: Tabs

[Angelo Graziosi]

> Il 2 settembre 2019 alle 21.46 Juri Linkov ha scritto:
> 
> 
> > I am an old user of 'tabbar-ruler' and friends from MELPA
> > (https://melpa.org/#/tabbar-ruler) and have built your branch on
> > Windows with the following results.
> 
> You mean all your screenshots were taken on Windows?
> This is good news.  This means after blindly changing
> Windows related code without testing it just works.

Yes.

> 
> >> 3. Click on the previous tab
> >> 4. Click on the close icon
> >
> > Then tried this, and the result is global-tab.png: notice, usually,
> > Emacs here starts restoring about 65 buffers
> 
> Have you visited all these 65 buffers in the same window?

From the screenshots I sent, when I use tabbar-ruler from MELPA, Emacs loads 65 buffers and shows them 'per mode', i.e. if I select a .f90 buffer, it shows only buffers in F90 mode. Usually I can see about 4-5 tabs but I can navigate (scroll) between them using left-right arrows (see tabbar-ruler.png). The '-' on the tabs row allows to switch to see tabs per mode (tabbar-ruler-permode.png), so I click the '-', select 'Shell-script' tab and then visit a loaded .sh buffer, and so on.

More or less similar functionalities are present in other Editors/IDEs/Browsers. 

Maybe, instead of limit the number of tabs, one should limit its dimension so that the name buffer is still partially visible.. Yuri (https://lists.gnu.org/archive/html/emacs-devel/2019-09/msg00057.html) has good POV.

Re: Tabs

[Juri Linkov]

>> >> 3. Click on the previous tab
>> >> 4. Click on the close icon
>> >
>> > Then tried this, and the result is global-tab.png: notice, usually,
>> > Emacs here starts restoring about 65 buffers
>>
>> Have you visited all these 65 buffers in the same window?
>
> From the screenshots I sent, when I use tabbar-ruler from MELPA, Emacs
> loads 65 buffers and shows them 'per mode', i.e. if I select a .f90 buffer,
> it shows only buffers in F90 mode. Usually I can see about 4-5 tabs but
> I can navigate (scroll) between them using left-right arrows (see
> tabbar-ruler.png). The '-' on the tabs row allows to switch to see tabs per
> mode (tabbar-ruler-permode.png), so I click the '-', select 'Shell-script'
> tab and then visit a loaded .sh buffer, and so on.

Grouping buffers by their modes is already implemented when you click
on the plus sign: buffers are grouped by modes at the top submenus.

> More or less similar functionalities are present in other Editors/IDEs/Browsers.
>
> Maybe, instead of limit the number of tabs, one should limit its
> dimension so that the name buffer is still partially visible.. Yuri
> (https://lists.gnu.org/archive/html/emacs-devel/2019-09/msg00057.html)
> has good POV.

Yes, I tend to agree that truncating tab names to the point
of complete unreadability like Chromes does, doesn't make any good.
I guess we have to define some minimal size of the tab name.

Re: Tabs

[Angelo Graziosi]

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


> Juri Linkov wrote:
> 
> I implemented now the display and support of the mouse in 
> text-mode frames and pushed to the feature/tabs branch in
> commit a365251d01.
> 

Usually, I do a nox build for my WSL, so tried your branch but it failed.

Attached the build log.

Thanks.

[-- Attachment #2: emacs-tabs-nox-x86_64-20190904-release-build.log.bz2 --]
[-- Type: application/x-bzip, Size: 7936 bytes --]

Re: Tabs

[Juri Linkov]

>> I implemented now the display and support of the mouse in 
>> text-mode frames and pushed to the feature/tabs branch in
>> commit a365251d01.
>
> Usually, I do a nox build for my WSL, so tried your branch but it failed.
>
> Attached the build log.

Thanks for the log.  I wonder how you disable X without using
--without-x, but anyway it's clear what's your configuration.
So now I implemented support for nox builds as well, and pushed
to the branch.  Please try to recompile.

Re: Tabs

[Angelo Graziosi]

> Il 4 settembre 2019 alle 21.05 Juri Linkov <juri@linkov.net> ha scritto:
> 
> 
> >> I implemented now the display and support of the mouse in 
> >> text-mode frames and pushed to the feature/tabs branch in
> >> commit a365251d01.
> >
> > Usually, I do a nox build for my WSL, so tried your branch but it failed.
> >
> > Attached the build log.
> 
> Thanks for the log.  I wonder how you disable X without using
> --without-x, but anyway it's clear what's your configuration.

Why do you think that? The nox build means I DO use ./configure --without-x (really '--with-x=no', which is the same). BTW, I do that build to be used in WSL (both WSL and my GNU/Linux Mint are based on Ubuntu 18.04)

> So now I implemented support for nox builds as well, and pushed
> to the branch.  Please try to recompile.

Thanks.. tomorrow, now I am on Windows..

Re: Tabs

[Angelo Graziosi]

> Juri Linkov wrote:
>
> 
> Thanks for the log.  I wonder how you disable X without using
> --without-x, but anyway it's clear what's your configuration.
> So now I implemented support for nox builds as well, and pushed
> to the branch.  Please try to recompile.


Done. It builds; tested on WSL. A few considerations.

Usually, when I start nox Emacs it loads the last buffer I worked on previously because I have '(desktop-save-mode 1)'. Call this buffer foo.txt. The same occurs with your branch. So I do 'M-x global-tab-line-mode' and foo.txt is in a tab, and near the tab a '+'.

So, I don't see the other buffers saved in desktop.

When I click with mouse the '+' a menu shows up whose items are just those buffers! I can select another buffer in this menu only with UP/DOWN keyboard key and NOT with the mouse: someone of you should ad this and also to work with File Edit Options... menu and their items (now one has to do F10 and move with arrows...)

In this way, I can have other desktop saved buffers in tabs.. but quitting Emacs, the next time I have to repeat all those steps... which is annoying.

I think one wants that starting Emacs all those buffer are in tabs.


I have built the same source of the branch on Windows. 

Here there is an issue before using M-x global... : the mouse does not work on the tool bar. Indeed I modified my init.el to not use the tabbar-ruler from MELPA and when I tried to save it clicking on the tool bar icon, 'save current buffer...', the minibuffer showed "mouse-1 is undefined".

Any way, C-x C-s helped me and after restarting Emacs I noticed the following.

Only a few buffer in tabs, just to fill the window width, and this is good. But how are chosen the buffer to shows in tabs? apparently it seems at random, and beside this, their name are only partially visible, too little. 

With this build, clicking the '+' allows to put in tab buffers based on their mode.. Hmm.. 

Thanks

Re: Tabs

[Angelo Graziosi]

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


> Angelo Graziosi wrote:
> 
> Done. It builds;

Just a few suggestions to make these tabs more friendly..

In tabbar-ruler from MELPA (see attachment), the  tab line starts with a tab and the tabs adapt their length to the buffer name even if uniquify-buffer-name-style is set to forward: in this case the tab line contains fewer tabs or just one tab (consider a buffer with name : emacs-master-w64-x86_64-20190903_135542-release-build.log.bz2...). Only the last tab could be 'truncated'. In any case, one could scroll between tabs using the L-R arrows on the tab line (see attachment)...

[-- Attachment #2: tbr-example.png.bz2 --]
[-- Type: application/x-bzip2, Size: 11693 bytes --]

Re: Tabs

[Juri Linkov]

>> So now I implemented support for nox builds as well, and pushed
>> to the branch.  Please try to recompile.
>
> Done. It builds; tested on WSL. A few considerations.

Thanks for testing and considerations for improvement.

> Usually, when I start nox Emacs it loads the last buffer I worked on
> previously because I have '(desktop-save-mode 1)'. Call this buffer
> foo.txt. The same occurs with your branch. So I do 'M-x
> global-tab-line-mode' and foo.txt is in a tab, and near the tab a '+'.
>
> So, I don't see the other buffers saved in desktop.
>
> When I click with mouse the '+' a menu shows up whose items are just those
> buffers! I can select another buffer in this menu only with UP/DOWN
> keyboard key and NOT with the mouse: someone of you should ad this and also
> to work with File Edit Options... menu and their items (now one has to do
> F10 and move with arrows...)

Indeed F10 doesn't allow selecting menu items with the mouse, neither
<C-down-mouse-1> ('mouse-buffer-menu') on which the '+' is based.
I don't know whether it's possible to implement mouse support
for these menus.

> In this way, I can have other desktop saved buffers in tabs.. but
> quitting Emacs, the next time I have to repeat all those
> steps... which is annoying.

Actually after restoring the desktop, all previous buffers
will appear in tabs if you use the same window.

So currently it works in that way that allows you to select
which buffers you want to see in the tab-line of the current window,
and restores these selected buffers in the same window after
restoring from the desktop file.

> I think one wants that starting Emacs all those buffer are in tabs.

I can't imagine how to display all available buffers in tabs.
Usually I have dozens of buffers visited in the same session,
and fitting all them in the same tab-line would be impossible.

> I have built the same source of the branch on Windows.
>
> Here there is an issue before using M-x global... : the mouse does not work
> on the tool bar. Indeed I modified my init.el to not use the tabbar-ruler
> from MELPA and when I tried to save it clicking on the tool bar icon, 'save
> current buffer...', the minibuffer showed "mouse-1 is undefined".

This could be fixed by refactoring tool-bar Windows code.

> Any way, C-x C-s helped me and after restarting Emacs I noticed the following.
>
> Only a few buffer in tabs, just to fill the window width, and this is
> good. But how are chosen the buffer to shows in tabs? apparently it
> seems at random,

The tab-line is centered around the current tab, so currently you can
scroll the tab-line by clicking on the leftmost/rightmost tab.  Although
better scrolling could be implemented too.

> and beside this, their name are only partially visible, too little.

Maybe we should not truncate tab names at all.

But as you wrote in another mail:

> Just a few suggestions to make these tabs more friendly..
>
> In tabbar-ruler from MELPA (see attachment), the tab line starts with a tab
> and the tabs adapt their length to the buffer name even if
> uniquify-buffer-name-style is set to forward: in this case the tab line
> contains fewer tabs or just one tab (consider a buffer with name :
> emacs-master-w64-x86_64-20190903_135542-release-build.log.bz2...). Only the
> last tab could be 'truncated'.

Is it really good to show just one long non-truncated tab name?
Maybe we should add an option for the tab width.

> In any case, one could scroll between tabs using the L-R arrows on the
> tab line (see attachment)...

We could add such scrolling as an option but I doubt if this is the easiest
way of finding and selecting the tab.

Re: Tabs

[Juri Linkov]

> When I click with mouse the '+' a menu shows up whose items are just those
> buffers! I can select another buffer in this menu only with UP/DOWN
> keyboard key and NOT with the mouse: someone of you should ad this and also
> to work with File Edit Options... menu and their items (now one has to do
> F10 and move with arrows...)

Mouse clicks are not supported in popup menus.  So now the menu for the '+'
will fall back to tmm-prompt on terminals.

> Here there is an issue before using M-x global... : the mouse does not work
> on the tool bar. Indeed I modified my init.el to not use the tabbar-ruler
> from MELPA and when I tried to save it clicking on the tool bar icon, 'save
> current buffer...', the minibuffer showed "mouse-1 is undefined".

Now this Windows issue is fixed as well.

Re: Tabs

[Angelo Graziosi]

Today branch fails on Windows (at least..), maybe a typo:

[...]
  GEN      ../../etc/charsets/IBM862.map
  GEN      ../../etc/charsets/IBM863.map
  GEN      ../../etc/charsets/IBM864.map
xdisp.c: In function 'tab_bar_item_info':
xdisp.c:13181:41: error: 'Qclose' undeclared (first use in this function); did you mean 'Qclosed'?
13181 |                                         Qclose,
      |                                         ^~~~~~
      |                                         Qclosed
xdisp.c:13181:41: note: each undeclared identifier is reported only once for each function it appears in
  GEN      ../../etc/charsets/IBM865.map
  GEN      ../../etc/charsets/IBM866.map
  GEN      ../../etc/charsets/IBM868.map
  GEN      ../../etc/charsets/IBM869.map
  GEN      ../../etc/charsets/IBM870.map
make[1]: *** [Makefile:402: xdisp.o] Error 1
make[1]: *** Attesa per i processi non terminati....
[...]
  GEN      ../../etc/charsets/JISX2131.map
  GEN      charsets.stamp
make[2]: uscita dalla directory "/tmp/emacs-master/admin/charsets"
make[1]: uscita dalla directory "/tmp/emacs-master/src"
make: *** [Makefile:424: src] Error 2
Error: Failure running MAKE

Re: Tabs

[Angelo Graziosi]

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

> Today branch fails on Windows (at least..), maybe a typo:
> 
> [...]
>   GEN      ../../etc/charsets/IBM862.map
>   GEN      ../../etc/charsets/IBM863.map
>   GEN      ../../etc/charsets/IBM864.map
> xdisp.c: In function 'tab_bar_item_info':
> xdisp.c:13181:41: error: 'Qclose' undeclared (first use in this function); did you mean 'Qclosed'?
> 13181 |                                         Qclose,
>       |                                         ^~~~~~
>       |                                         Qclosed
> xdisp.c:13181:41: note: each undeclared identifier is reported 

I corrected and it builds.

Some comment:

After removing the code to use tabbar from MELPA in my init.el, I started Emacs of your branch and did: M-x global-tab-line-mode. The result is in the attachment. I think it should only shows a limited number of tabs, so that the buffer names are readable (like in the previous screenshots regarding tabbar from MELPA), other wise it is unusable.

BTW, I use sr-speedbar from MELPA and as you can see from too_many_tabs.png its window contains two tabs (init.el and *SPEEDBAR*): maybe it should not contain tabs or at most just that regarding speedbar..

[-- Attachment #2: too_many_tabs.png.bz2 --]
[-- Type: application/x-bzip2, Size: 17410 bytes --]

Re: Tabs

[Juri Linkov]

>> Today branch fails on Windows (at least..), maybe a typo:
>> 
>> [...]
>>   GEN      ../../etc/charsets/IBM862.map
>>   GEN      ../../etc/charsets/IBM863.map
>>   GEN      ../../etc/charsets/IBM864.map
>> xdisp.c: In function 'tab_bar_item_info':
>> xdisp.c:13181:41: error: 'Qclose' undeclared (first use in this function); did you mean 'Qclosed'?
>> 13181 |                                         Qclose,
>>       |                                         ^~~~~~
>>       |                                         Qclosed
>> xdisp.c:13181:41: note: each undeclared identifier is reported 
>
> I corrected and it builds.

This is fixed now.

> Some comment:
>
> After removing the code to use tabbar from MELPA in my init.el, I started
> Emacs of your branch and did: M-x global-tab-line-mode. The result is in
> the attachment. I think it should only shows a limited number of tabs, so
> that the buffer names are readable (like in the previous screenshots
> regarding tabbar from MELPA), other wise it is unusable.

I agree that it should show only buffers that you visited in the window,
but I suspect that a long list of previously visited buffers in your window
caused by a desktop bug - it seems the desktop restores all buffers
saved from the previous session using the same window, thus causing
a large list of visited buffers in one window (and as you noted below
there are no such long list of buffers in other windows).

> BTW, I use sr-speedbar from MELPA and as you can see from
> too_many_tabs.png its window contains two tabs (init.el and
> *SPEEDBAR*): maybe it should not contain tabs or at most just that
> regarding speedbar..

Yes, it seems it makes no sense to display tabs in the speedbar window.
Please try this customization:

(add-hook 'speedbar-mode-hook
          (lambda ()
            (setq-local tab-line-format nil)))

Another place I noticed where it could be disabled is *Completions* window.

Re: Tabs

[Angelo Graziosi]

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

I am trying to use these tabs but, at moment, I find them very "obscure".

Usually I use tabbar and sr-speedbar from MELPA, so  I removed from the init.el file the code regarding tabbar but _NOT_ that for sr-speedbar and delete the desktop file.

To try to understand how these tabs work I have build current master (f113ae59222) and the emacs.pdf manual (all on Windows).

When I start Emacs, it displays the scratch buffer and after M-x tab-bar-mode I see two empty box (see tab-bar-01.png in attachment). The tooltips say 'Current tab' and 'New Tab'. I visited another file, and another using the sr-sppedbar and would expect to see these in their own tabs but the result is that 'scratch(2)' is replaced by the first and then the other file name with the ending '(2)' (Why this '(2)'?). See tab-bar-02.png. 

How can I see the visited files in tabs? When I click in the box whose tooltip says 'New tab', it seems that the same buffer is in more than a tab.

When I use C-x 6 b ... I see another file in tab (tab-bar-03.png) but to switch between the I have to click more times, at least initially, and why all those empty box?

When I use tabbar.el from MELPA, all I need is to install the package, start Emacs, type M-x tabbar-mode and visit files with C-x f or with the sr-speedbar..

It seems that 'M-x global-tab-line-mode' works similarly to tabbar.el from MELPA but just visiting four files truncates their names (tab-bar-04.png) in tabs instead of shifting them as in tabbar.el (in which a scrolling mechanism can retrieve the tabs "hidden")...

[-- Attachment #2: tabs.tar.gz --]
[-- Type: application/gzip, Size: 40250 bytes --]

Re: Tabs

[Eli Zaretskii]

> Date: Sun, 13 Oct 2019 16:49:48 +0200 (CEST)
> From: Angelo Graziosi <angelo.g0@libero.it>
> Cc: emacs-devel@gnu.org
> 
> How can I see the visited files in tabs? When I click in the box whose tooltip says 'New tab', it seems that the same buffer is in more than a tab.

If you want to visit a file in another tab, you should visit it with
"C-x t f" (or "C-x 6 f"), not with "C-x C-f".  This is similar to
visiting a file in another frame with "C-x 5 f": unless you do that,
"C-x C-f" visits the file in the current frame and current window.

Another possibility is to turn on global-tab-line-mode.  Then each
_window_ will have tabs, and every time you visit a file in that
window, another tab appears for that window.

This is in NEWS, btw.

> When I use C-x 6 b ... I see another file in tab (tab-bar-03.png) but to switch between the I have to click more times, at least initially, and why all those empty box?

The empty boxes seem to indicate that Emacs is unable to load the
icons for closing and opening tabs, they should be displayed instead
of the empty boxes.  If you are running an installed Emacs, perhaps
"make install" have a bug whereby it doesn't install the tab-related
images?

Re: Tabs

[Angelo Graziosi]

> Il 13 ottobre 2019 alle 17.07 Eli Zaretskii ha scritto:
>
> Another possibility is to turn on global-tab-line-mode.

Yes, as I wrote it seems that works better from my POV but just visiting four files truncates their name in tabs because tabs shrink when buffers increase. We need a scrolling mechanism to avoid this 'shrinkage'.
 
>
> The empty boxes seem to indicate that Emacs is unable to load the
> icons for closing and opening tabs, they should be displayed instead
> of the empty boxes.  If you are running an installed Emacs, perhaps
> "make install" have a bug whereby it doesn't install the tab-related
> images?

I build using emacs-master.tar.gz as source and my script has something like this:

  make DESTDIR=/foo/inst install-strip

then it creates a compressed archive (a 'package') with the installation tree (the --prefix is something like /bar/Emacs). I use this 'package' to install/update Emacs on W10 Pro and Home. I have a task bar link to start Emacs..

Anyway, I am following this thread since it was born and my opinion is that it looks too complicated to use this kind of tabs. Do you really think that users not belonging to the set of developers will use them?

Re: Tabs

[Eli Zaretskii]

> Date: Sun, 13 Oct 2019 23:09:29 +0200 (CEST)
> From: Angelo Graziosi <angelo.g0@libero.it>
> Cc: juri@linkov.net, emacs-devel@gnu.org
> 
> Anyway, I am following this thread since it was born and my opinion is that it looks too complicated to use this kind of tabs. Do you really think that users not belonging to the set of developers will use them?

Which part(s) seem too complicated?

Most of the discussions you saw here dealt with initial bugs and
misfeatures, which is reasonable for a significant new feature.  I
don't see why ordinary users would find the feature complicated.  All
it presents is a small number of basic facilities:

  . turn tab bar on and off
  . visit a file in a new tab
  . switch between tabs
  . close a tab

Everything else is customization, sophisticated facilities for those
who want them, etc.  It isn't different from similar commands to use
frames, for example.

Re: Tabs

[Angelo Graziosi]

> Il 14 ottobre 2019 alle 10.23 Eli Zaretskii ha scritto:
>
>  All it presents is a small number of basic facilities:
> 
>   . turn tab bar on and off
>   . visit a file in a new tab
>   . switch between tabs
>   . close a tab
> 

turn tab bar on and off   ==> M-x tab-bar-mode
visit a file in a new tab ==> ???
switch between tabs       ==> ???
close a tab               ==> ???

Please, explicit the '???'...

Thanks

Re: Tabs

[Eli Zaretskii]

> Date: Tue, 15 Oct 2019 23:38:37 +0200 (CEST)
> From: Angelo Graziosi <angelo.g0@libero.it>
> Cc: juri@linkov.net, emacs-devel@gnu.org
> 
> >  All it presents is a small number of basic facilities:
> > 
> >   . turn tab bar on and off
> >   . visit a file in a new tab
> >   . switch between tabs
> >   . close a tab
> > 
> 
> turn tab bar on and off   ==> M-x tab-bar-mode
> visit a file in a new tab ==> ???

C-x t f FILENAME RET

> switch between tabs       ==> ???

Click with the mouse on a tab, or C-TAB to switch to the next tab,
S-C-TAB to switch to the previous tab

> close a tab               ==> ???

Click the mouse on the "x" image at the right corner of a tab, or type
C-x t 0

These are in NEWS (although we still advertise the "C-x 6" prefix
there instead of "C-x t", which will change soon).

Re: Tabs

[Juri Linkov]

>> When I use C-x 6 b ... I see another file in tab (tab-bar-03.png) but
>> to switch between the I have to click more times, at least initially,
>> and why all those empty box?
>
> The empty boxes seem to indicate that Emacs is unable to load the
> icons for closing and opening tabs, they should be displayed instead
> of the empty boxes.  If you are running an installed Emacs, perhaps
> "make install" have a bug whereby it doesn't install the tab-related
> images?

The problem is that tab-bar.el is pre-loaded by loadup.el and
dumped with the value of data-directory from the source location.
So running from the dump file even in the install directory
still uses source data-directory.

A pre-loaded definition looks like:

  (defvar tab-bar-new-button
    (propertize " + "
                'display `(image :type xpm
                                 :file ,(expand-file-name
                                         "images/tabs/new.xpm"
                                         data-directory)
                                 :margin (2 . 0)
                                 :ascent center))
    "Button for creating a new tab.")

and indeed I checked in the dump file that it contains
the expanded source data-directory.

I don't know how this case should be handled.
Maybe to create the image on the first use of the tab-bar?

Re: Tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Angelo Graziosi <angelo.g0@libero.it>,  emacs-devel@gnu.org
> Date: Mon, 14 Oct 2019 01:08:55 +0300
> 
> > The empty boxes seem to indicate that Emacs is unable to load the
> > icons for closing and opening tabs, they should be displayed instead
> > of the empty boxes.  If you are running an installed Emacs, perhaps
> > "make install" have a bug whereby it doesn't install the tab-related
> > images?
> 
> The problem is that tab-bar.el is pre-loaded by loadup.el and
> dumped with the value of data-directory from the source location.
> So running from the dump file even in the install directory
> still uses source data-directory.

Why can't you compute the value at run time, rather than at dump time?
Like the first time the tab bar is activated?

Re: Tabs

[Eli Zaretskii]

> Date: Mon, 14 Oct 2019 09:37:07 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: angelo.g0@libero.it, emacs-devel@gnu.org
> 
> > The problem is that tab-bar.el is pre-loaded by loadup.el and
> > dumped with the value of data-directory from the source location.
> > So running from the dump file even in the install directory
> > still uses source data-directory.
> 
> Why can't you compute the value at run time, rather than at dump time?
> Like the first time the tab bar is activated?

I see that you have done so, thanks.

However, there should be no need to explicitly expand-file-name for
the image files, as the documentation of the :file attribute says:

  ‘:file FILE’
       This says to load the image from file FILE.  If FILE is not an
       absolute file name, it is expanded relative to the ‘images’
       subdirectory of ‘data-directory’, and failing that, relative to the
       directories listed by ‘x-bitmap-file-path’ (*note Face
       Attributes::).

So by explicitly calling expand-file-name, you introduce a subtle
misfeature, whereby x-bitmap-file-path will not be consulted.

Re: Tabs

[Juri Linkov]

>> > The problem is that tab-bar.el is pre-loaded by loadup.el and
>> > dumped with the value of data-directory from the source location.
>> > So running from the dump file even in the install directory
>> > still uses source data-directory.
>> 
>> Why can't you compute the value at run time, rather than at dump time?
>> Like the first time the tab bar is activated?
>
> I see that you have done so, thanks.
>
> However, there should be no need to explicitly expand-file-name for
> the image files, as the documentation of the :file attribute says:
>
>   ‘:file FILE’
>        This says to load the image from file FILE.  If FILE is not an
>        absolute file name, it is expanded relative to the ‘images’
>        subdirectory of ‘data-directory’, and failing that, relative to the
>        directories listed by ‘x-bitmap-file-path’ (*note Face
>        Attributes::).
>
> So by explicitly calling expand-file-name, you introduce a subtle
> misfeature, whereby x-bitmap-file-path will not be consulted.

I thought first to check with file-exists-p, but it seems
with relative file names this is unnecessary, so I removed this.

Or maybe even better would be to use find-image?

What still worries me is that when the image file doesn't exist
then large rectangles are displayed instead.  I'd like to not put
display property when the image file doesn't exist.

Re: Tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: emacs-devel@gnu.org
> Date: Tue, 15 Oct 2019 22:44:41 +0300
> 
> Or maybe even better would be to use find-image?

I don't see a reason, we don't do that for tool-bar images, do we?

> What still worries me is that when the image file doesn't exist
> then large rectangles are displayed instead.  I'd like to not put
> display property when the image file doesn't exist.

What reason would there be for the image file not to exist if it is
part of the Emacs distribution?

Re: Tabs

[Juri Linkov]

>> Or maybe even better would be to use find-image?
>
> I don't see a reason, we don't do that for tool-bar images, do we?

tool-bar--image-expression uses find-image.

>> What still worries me is that when the image file doesn't exist
>> then large rectangles are displayed instead.  I'd like to not put
>> display property when the image file doesn't exist.
>
> What reason would there be for the image file not to exist if it is
> part of the Emacs distribution?

I don't know, the reasons could be various.

Re: Tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: emacs-devel@gnu.org
> Date: Thu, 17 Oct 2019 01:17:15 +0300
> 
> >> Or maybe even better would be to use find-image?
> >
> > I don't see a reason, we don't do that for tool-bar images, do we?
> 
> tool-bar--image-expression uses find-image.

Then I guess there's a valid reason to do the same for the tabs.

> >> What still worries me is that when the image file doesn't exist
> >> then large rectangles are displayed instead.  I'd like to not put
> >> display property when the image file doesn't exist.
> >
> > What reason would there be for the image file not to exist if it is
> > part of the Emacs distribution?
> 
> I don't know, the reasons could be various.

What does the tool bar do in those cases?

Re: Tabs

[Juri Linkov]

> When I start Emacs, it displays the scratch buffer and after M-x
> tab-bar-mode I see two empty box (see tab-bar-01.png in attachment).

This is bug#37685, please help to fix it.

> I visited another file, and another using the sr-sppedbar and would
> expect to see these in their own tabs but the result is that
> 'scratch(2)' is replaced by the first and then the other file name
> with the ending '(2)' (Why this '(2)'?). See tab-bar-02.png.

Since no one likes this vim-like indication for total number of windows,
I removed it from the default value.

> How can I see the visited files in tabs? When I click in the box whose
> tooltip says 'New tab', it seems that the same buffer is in more than
> a tab.

When you open a new frame with 'C-x 6 2', the same buffer is in more than
one frame.

> It seems that 'M-x global-tab-line-mode' works similarly to tabbar.el from
> MELPA but just visiting four files truncates their names (tab-bar-04.png)
> in tabs instead of shifting them as in tabbar.el (in which a scrolling
> mechanism can retrieve the tabs "hidden")...

This is bug#37667, please help to fix it.

RE: Tabs

[Drew Adams]

> 4. tab -- (a short strip of material attached to or projecting from
> something in order to facilitate opening or identifying or handling it;
> "pull the tab to open the can"; "files with a red tab will be stored
> separately"; "the collar has a tab with a button hole"; "the filing cards
> were organized by cards having indexed tabs")

Insert tab A into slot X and tab B into slot Y.

Re: Tabs

[Angelo Graziosi]

Eli Zaretskii wrote:

> Why cannot we support the mouse in text-mode frames?  We have several
> possible features for such support, including GPM, xterm-mouse, the
> MS-Windows and MS-DOS text-mode mouse functionality, etc.  I think we
> the tab bar should be able to support these.

When in early 90s I used my first IDEs (Turbo Pascal, C. C++...), the mouse was already supported to select text, menu, menu items etc., and at that time apps were only in text mode... there was also a menu called Window with which one could navigate between loaded 'buffers'...

Tabs

[Juri Linkov]

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

There is a long story of several attempts to implement tabs in Emacs.
Finally now a complete implementation is available for these
etc/TODO tasks:

  ** "Perspectives" are named persistent window configurations.  We have
  had the window configuration mechanism in GNU Emacs since the
  beginning but we have never developed a good user interface to take
  advantage of them.  Eclipse's user interface seems to be good.
  Perspectives also need to interact with the tabs.

  ** Having tabs above a window to switch buffers in it.

Frame-local tabs represent window configurations.
Window-local tabs represent window buffers.

Using such data structures means there is no need in special handling
of saving tabs in the desktop file - both persistence of frame tabs
and persistence of window tabs is already supported by the existing
code in master, because frame tabs are implemented as presentation of
window configurations in the frame parameter saved by frameset as
window states, and window tabs are implemented as presentation of
window buffers already saved by frameset.

Also both implementation of frame tabs and implementation of
window tabs doesn't require using hooks - frame-local tabs for
window-configuration switching doesn't rely on hooks and
window-local tabs for switching window-buffers doesn't use hooks:
window-configuration-change-hook is not used, no hook
window-size-change-functions, no buffer-list-update-hook, no
post-command-hook is used, none of the hooks.

All this makes the implementation as simple as possible,
providing only code for displaying and manipulating the already
existing data structures of window configurations and window buffers
represented in the new display elements tab-bar and tab-line
based on the existing elements tool-bar and header-line.

The prefix '-bar' in tab-bar is by analogy with frame tool-bar, menu-bar.
The prefix '-line' in tab-line is by analogy with window header-line, mode-line.

The tab-bar is located above the tool-bar like in web browsers.
The tab-line is located above the header-line
that is more related to the current buffer.

Frame-local horizontal interface elements are in this order:
--- menu-bar ---
--- tab-bar ---
--- tool-bar ---

Window-local horizontal interface elements are in this order:
--- tab-line ---
--- header-line ---
--- mode-line ---

The implementation of the tab-bar replicates the existing tool-bar.
The implementation of the tab-line replicates the existing header-line.

Tabs on the frame tab-bar represent window configurations.
Tabs on the window tab-line represent window buffers: previous on the
left side from the current tab (current-buffer) and next on the right.

Clicking on the tab in the tab-bar selects its window configuration.
Clicking on the tab in the tab-line selects its window buffer.
Clicking on the close button closes the clicked tab.

Keybindings for the tab-bar:
  C-TAB     - switches to the next frame tab;
S-C-TAB     - switches to the previous frame tab.
Clicking on the plus sign adds a new window configuration tab to the tab-bar.

Keybindings for the tab-line:
C-x <left>  - switches to the previous window tab;
C-x <right> - switches to the next window tab.
Clicking on the plus sign adds a new buffer tab to the tab-line.

'C-x 6 2' creates a new frame-local tab;
'C-x 6 b' switches to buffer in another frame-local tab;
'C-x 6 f' and 'C-x 6 C-f' edit file in another frame-local tab.

I invite everyone to try the new branch named 'feature/tabs'
and to report all found problems.

Authors of all packages that currently had no choice other than to
misuse the header-line for displaying window tabs are welcome now to
adapt their packages for displaying window tabs on the new dedicated
tab-line that doesn't conflict with the header-line anymore.
For example, I tried just to replace header-line-format with
tab-line-format in the package awesome-tabs and the result
shows two separate rows - tab-line and header-line of Info buffer:


[-- Attachment #2: tabs.png --]
[-- Type: image/png, Size: 41241 bytes --]

Re: Tabs

[martin rudalics]

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

 > Finally

... some ten years after you started ...

 > now a complete implementation is available for these
 > etc/TODO tasks:

To make your branch build on Windows you need to install the attached
patch at least (blindly copied from its X counterparts).  Therafter,
Emacs builds and comes up normally.

After clicking on the Show/Hide Tab Bar menu entry, I see

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
   toggle-tab-bar-mode-from-frame(toggle)
   funcall-interactively(toggle-tab-bar-mode-from-frame toggle)
   call-interactively(toggle-tab-bar-mode-from-frame nil nil)
   command-execute(toggle-tab-bar-mode-from-frame)

When clicking on a tab in a tab lines entry I get

<nil> <down-mouse-1> is undefined
<nil> <mouse-1> is undefined

I didn't look into the details of how these are implemented.

Please also provide a simple recipe for testing your branch.

Thanks for all the work, martin

[-- Attachment #2: tabs.diff --]
[-- Type: text/plain, Size: 4596 bytes --]

diff --git a/src/w32fns.c b/src/w32fns.c
index 4b95b255f1..0d6369461c 100644
--- a/src/w32fns.c
+++ b/src/w32fns.c
@@ -1773,6 +1773,94 @@ w32_set_menu_bar_lines (struct frame *f, Lisp_Object value, Lisp_Object oldval)
 }
 
 
+/* Set the number of lines used for the tab bar of frame F to VALUE.
+   VALUE not an integer, or < 0 means set the lines to zero.  OLDVAL
+   is the old number of tab bar lines.  This function changes the
+   height of all windows on frame F to match the new tab bar height.
+   The frame's height doesn't change.  */
+
+static void
+w32_set_tab_bar_lines (struct frame *f, Lisp_Object value, Lisp_Object oldval)
+{
+  int nlines;
+
+  /* Treat tab bars like menu bars.  */
+  if (FRAME_MINIBUF_ONLY_P (f))
+    return;
+
+  /* Use VALUE only if an int >= 0.  */
+  if (RANGED_FIXNUMP (0, value, INT_MAX))
+    nlines = XFIXNAT (value);
+  else
+    nlines = 0;
+
+  w32_change_tab_bar_height (f, nlines * FRAME_LINE_HEIGHT (f));
+}
+
+
+/* Set the pixel height of the tab bar of frame F to HEIGHT.  */
+void
+w32_change_tab_bar_height (struct frame *f, int height)
+{
+  int unit = FRAME_LINE_HEIGHT (f);
+  int old_height = FRAME_TAB_BAR_HEIGHT (f);
+  int lines = (height + unit - 1) / unit;
+  Lisp_Object fullscreen;
+
+  /* Make sure we redisplay all windows in this frame.  */
+  fset_redisplay (f);
+
+  /* Recalculate tab bar and frame text sizes.  */
+  FRAME_TAB_BAR_HEIGHT (f) = height;
+  FRAME_TAB_BAR_LINES (f) = lines;
+  /* Store the `tab-bar-lines' and `height' frame parameters.  */
+  store_frame_param (f, Qtab_bar_lines, make_fixnum (lines));
+  store_frame_param (f, Qheight, make_fixnum (FRAME_LINES (f)));
+
+  /* We also have to make sure that the internal border at the top of
+     the frame, below the menu bar or tab bar, is redrawn when the
+     tab bar disappears.  This is so because the internal border is
+     below the tab bar if one is displayed, but is below the menu bar
+     if there isn't a tab bar.  The tab bar draws into the area
+     below the menu bar.  */
+  if (FRAME_W32_WINDOW (f) && FRAME_TAB_BAR_HEIGHT (f) == 0)
+    {
+      clear_frame (f);
+      clear_current_matrices (f);
+    }
+
+  if ((height < old_height) && WINDOWP (f->tab_bar_window))
+    clear_glyph_matrix (XWINDOW (f->tab_bar_window)->current_matrix);
+
+  /* Recalculate tabbar height.  */
+  f->n_tab_bar_rows = 0;
+  if (old_height == 0
+      && (!f->after_make_frame
+	  || NILP (frame_inhibit_implied_resize)
+	  || (CONSP (frame_inhibit_implied_resize)
+	      && NILP (Fmemq (Qtab_bar_lines, frame_inhibit_implied_resize)))))
+    f->tab_bar_redisplayed = f->tab_bar_resized = false;
+
+  adjust_frame_size (f, -1, -1,
+		     ((!f->tab_bar_resized
+		       && (NILP (fullscreen =
+				 get_frame_param (f, Qfullscreen))
+			   || EQ (fullscreen, Qfullwidth))) ? 1
+		      : (old_height == 0 || height == 0) ? 2
+		      : 4),
+		     false, Qtab_bar_lines);
+
+  f->tab_bar_resized = f->tab_bar_redisplayed;
+
+  /* adjust_frame_size might not have done anything, garbage frame
+     here.  */
+  adjust_frame_glyphs (f);
+  SET_FRAME_GARBAGED (f);
+  if (FRAME_W32_WINDOW (f))
+    w32_clear_under_internal_border (f);
+}
+
+
 /* Set the number of lines used for the tool bar of frame F to VALUE.
    VALUE not an integer, or < 0 means set the lines to zero.  OLDVAL is
    the old number of tool bar lines (and is unused).  This function may
diff --git a/src/w32term.c b/src/w32term.c
index 82c7e211bf..1f57635f6d 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -7192,6 +7192,7 @@ w32_create_terminal (struct w32_display_info *dpyinfo)
   terminal->menu_show_hook = w32_menu_show;
   terminal->activate_menubar_hook = w32_activate_menubar;
   terminal->popup_dialog_hook = w32_popup_dialog;
+  terminal->change_tab_bar_height_hook = w32_change_tab_bar_height;
   terminal->change_tool_bar_height_hook = w32_change_tool_bar_height;
   terminal->set_vertical_scroll_bar_hook = w32_set_vertical_scroll_bar;
   terminal->set_horizontal_scroll_bar_hook = w32_set_horizontal_scroll_bar;
diff --git a/src/w32term.h b/src/w32term.h
index 6133e100c1..378f274d7e 100644
--- a/src/w32term.h
+++ b/src/w32term.h
@@ -233,6 +233,7 @@ extern void w32_real_positions (struct frame *f, int *xptr, int *yptr);
 
 extern void w32_clear_under_internal_border (struct frame *);
 
+extern void w32_change_tab_bar_height (struct frame *, int);
 extern void w32_change_tool_bar_height (struct frame *, int);
 extern void w32_implicitly_set_name (struct frame *, Lisp_Object, Lisp_Object);
 extern void w32_set_scroll_bar_default_width (struct frame *);

Re: Tabs

[Eli Zaretskii]

> From: martin rudalics <rudalics@gmx.at>
> Date: Sun, 1 Sep 2019 10:12:41 +0200
> 
>  > now a complete implementation is available for these
>  > etc/TODO tasks:
> 
> To make your branch build on Windows you need to install the attached
> patch at least (blindly copied from its X counterparts).  Therafter,
> Emacs builds and comes up normally.

Thanks, but I think we should avoid duplicating GUI code like that.
The code should refactored to keep the frame-type specific code
separate, called via hooks by generic code, and generic code should
not be in xfns.c, w32fns.c etc., but in general platform-independent
source file, such as window.c.

Re: Tabs

[Juri Linkov]

>> Finally
>
> ... some ten years after you started ...

Thanks to your help, 3 months ago I have been able finally to understand
how persistence of window configurations/states should be implemented.
Also such implementation would not be possible earlier before other
improvements including window states and framesets were implemented.
So it seems now is the right time :)

>> now a complete implementation is available for these
>> etc/TODO tasks:
>
> To make your branch build on Windows you need to install the attached
> patch at least (blindly copied from its X counterparts).  Therafter,
> Emacs builds and comes up normally.

Thanks, I pushed your patch to the branch.  I hope it would be possible
to do refactoring on top of your patch to avoid duplicating GUI code
like Eli asked.

> After clicking on the Show/Hide Tab Bar menu entry, I see
>
> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>   toggle-tab-bar-mode-from-frame(toggle)
>   funcall-interactively(toggle-tab-bar-mode-from-frame toggle)
>   call-interactively(toggle-tab-bar-mode-from-frame nil nil)
>   command-execute(toggle-tab-bar-mode-from-frame)

There is no such problem on X, so I guess it's Windows-specific?

> When clicking on a tab in a tab lines entry I get
>
> <nil> <down-mouse-1> is undefined
> <nil> <mouse-1> is undefined

This looks like Windows-specific too.

> I didn't look into the details of how these are implemented.
>
> Please also provide a simple recipe for testing your branch.

The simplest recipe is this:

0. emacs -Q
1. M-x tab-bar-mode RET
2. Click on the plus sign to create a new tab
3. Click on the previous tab
4. Click on the close icon

0. emacs -Q
1. M-x global-tab-line-mode
2. Click on the plus sign and select a buffer to create a new tab
3. Click on the previous tab
4. Click on the close icon

This covers the basic parts of the user interface.

Re: Tabs

[Stefan Kangas]

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

Hi Juri,

Juri Linkov <juri@linkov.net> writes:

>>> Finally
>>
>> ... some ten years after you started ...

Thanks for working on this.  I think this feature would be an
important step forward for Emacs.  I've now checked out and built the
branch and report my findings below.

(FWIW, I find the names tab-bar-mode and global-tab-line-mode
confusingly similar.  Could we find better and more descriptive names?
 For example, global-tab-line-mode could be global-buffer-tab-mode.)

Are you also looking for input regarding potential improvements the
user interface at this stage?  For example, would feedback similar to
"I think the width of the tabs under tab-bar-mode should be fixed" be
helpful?

> 0. emacs -Q
> 1. M-x tab-bar-mode RET
> 2. Click on the plus sign to create a new tab
> 3. Click on the previous tab
> 4. Click on the close icon

When saying M-x tab-bar-mode here, the window flickers as if redrawing
but no tabs show up.  The tabs do show up as soon as I resize the
window, or move it to a different workspace.  (My window manager is
XMonad, a tiling window manager, and the Emacs frame is automatically
set to full screen and moved to a particular workspace after launch.
Not sure if that helps.)

I installed a tool that was available in Debian to capture my screen
while reproducing this bug.  I've uploaded the resulting video here:

https://drive.google.com/file/d/10-9DpKEseOUtYjrHUJ2bEMifvSOf98Ri/view

> 0. emacs -Q
> 1. M-x global-tab-line-mode
> 2. Click on the plus sign and select a buffer to create a new tab
> 3. Click on the previous tab
> 4. Click on the close icon

This basic use case seems to work for me.

My tabs don't look as sleek as yours; not sure why.  Please see the
attached screenshot.

These are my build details:

In GNU Emacs 27.0.50 (build 11, x86_64-pc-linux-gnu, GTK+ Version 3.24.5)
 of 2019-09-02 built on joffe
Repository revision: 5bf45ec48b781a1165e882e7216892bf201d15f4
Repository branch: feature/tabs
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux 10 (buster)

Configured using:
 'configure --with-imagemagick
 PKG_CONFIG_PATH=/home/skangas/usr/lib/pkgconfig:'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB
NOTIFY INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT
LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS LIBSYSTEMD
PDUMPER LCMS2 GMP

Important settings:
  value of $LC_COLLATE: C
  value of $LC_CTYPE: sv_SE.UTF-8
  value of $LC_TIME: C
  locale-coding-system: utf-8-unix

Best regards,
Stefan Kangas

[-- Attachment #2: tabs-screenshot.png --]
[-- Type: image/png, Size: 17325 bytes --]

Re: Tabs

[Elias Mårtenson]

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

On Mon, 2 Sep 2019 at 08:41, Stefan Kangas <stefan@marxist.se> wrote:

(FWIW, I find the names tab-bar-mode and global-tab-line-mode
> confusingly similar.  Could we find better and more descriptive names?
>  For example, global-tab-line-mode could be global-buffer-tab-mode.)
>

This may be the very definition of a bikeshedding comment, but I do feel
the need ask the question:

Is it truly wise to have the word “tab” as part of the name of this
feature? The word “tab” (when not referring to codepoint U+0009 CHARACTER
TABULATION) usually refers to the specific visual indication that resembles
a row of tabs in old filing cabinets. The feature itself doesn't really
have that much to do with tabs of either kind.

I'm raising this because I initially had no idea what this was about
(thinking it referred to U+0009) and even after figuring it out, I'm still
confused by the names of the functions and modes.

A term that uniquely describes the actual feature would be very helpful in
reducing confusion. Especially among people who have never heard about the
functionality before.

Regards,
Elias

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

Re: Tabs

[Dmitry Gutov]

On 02.09.2019 13:11, Elias Mårtenson wrote:
> Is it truly wise to have the word “tab” as part of the name of this 
> feature? The word “tab” (when not referring to codepoint U+0009 
> CHARACTER TABULATION) usually refers to the specific visual indication 
> that resembles a row of tabs in old filing cabinets. The feature itself 
> doesn't really have that much to do with tabs of either kind.

If you look at common software outside of Emacs, "tab" is very often 
used for this kind of feature. E.g. browser tabs. Or similar tabs in 
other text editors.

Re: Tabs

[Juri Linkov]

> Is it truly wise to have the word “tab” as part of the name of this
> feature? The word “tab” (when not referring to codepoint U+0009 CHARACTER
> TABULATION) usually refers to the specific visual indication that resembles
> a row of tabs in old filing cabinets. The feature itself doesn't really
> have that much to do with tabs of either kind.

A row of tabs in filing cabinets and notebooks is a good analogy to what
these visual elements are intended for.

> I'm raising this because I initially had no idea what this was about
> (thinking it referred to U+0009) and even after figuring it out, I'm still
> confused by the names of the functions and modes.
>
> A term that uniquely describes the actual feature would be very helpful in
> reducing confusion. Especially among people who have never heard about the
> functionality before.

Actually there is not much confusion between two terms - on the
Wikipedia disambiguation page there are two separate definitions:

  Computing and technology
    Tab (interface), a visual marker in a computer application
    Tab key, on a keyboard

Even the Emacs Glossary at (info "(emacs) Glossary") defines the TAB
using a special syntax where all letters are in upper case:

  <TAB>
       <TAB> is the tab character.  In Emacs it is typically used for
       indentation or completion.

So in the documentation when mentioned as a key, the term is usually
in upper-case as TAB, or more disambiguation is added such as in
“tab key” or “tab character” - these are different things too: the
former is a key on the keyboard, the latter is a character usually
displayed as 8 spaces, but there is not much confusion between them too.

Re: Tabs

[Jean Louis]

From Wordnet, see definition 4.

* Overview of noun tab

The noun tab has 5 senses (no senses from tagged texts)
1. check, chit, tab -- (the bill in a restaurant; "he asked the waiter for the check")
2. yellow journalism, tabloid, tab -- (sensationalist journalism)
3. tab key, tab -- (the key on a typewriter or a word processor that causes a tabulation)
4. tab -- (a short strip of material attached to or projecting from something in order to facilitate opening or identifying or handling it; "pull the tab to open the can"; "files with a red tab will be stored separately"; "the collar has a tab with a button hole"; "the filing cards were organized by cards having indexed tabs")
5. pill, lozenge, tablet, tab -- (a dose of medicine in the form of a small pellet)

Re: Tabs

[Juri Linkov]

> From Wordnet, see definition 4.
>
> * Overview of noun tab
>
> The noun tab has 5 senses (no senses from tagged texts)
> 1. check, chit, tab -- (the bill in a restaurant; "he asked the waiter for the check")
> 2. yellow journalism, tabloid, tab -- (sensationalist journalism)
> 3. tab key, tab -- (the key on a typewriter or a word processor that causes a tabulation)
> 4. tab -- (a short strip of material attached to or projecting from
> something in order to facilitate opening or identifying or handling it;
> "pull the tab to open the can"; "files with a red tab will be stored
> separately"; "the collar has a tab with a button hole"; "the filing cards
> were organized by cards having indexed tabs")
> 5. pill, lozenge, tablet, tab -- (a dose of medicine in the form of a small pellet)

Wordnet is the most complete indeed and contains definition 4
that describes this feature, as well as definition 3 of the tab key,
but it still lacks a third computer-related definition, namely the
same definition that exists in The Free On-line Dictionary of Computing
(FOLDOC):

  TAB
     <character> (tab, Control-I, HT, ASCII 9) A character which
     when displayed or printed causes the following character to be
     placed at the next "tabstop" - the column whose number is a
     multiple of the current tab width.  Commonly (especially in
     Unix(?)) the tab width is eight, so, counting from the left
     margin (column zero), the tab stops are at columns 8, 16, 24,
     up to the width of the screen or page.
     A tab width of four or two is often preferred when indenting
     program source code to conserve indentation.
     Represented as "\t" in C, Unix, and derivatives.

Re: Tabs

[Jean Louis]

Hello Juri,

Yes, sure it can lack special definitions, but we speak in a context
of definition 4. Isn't it?

We speak of tabs in Emacs as in the definition 4. as virtualized into
some 4-x definition where similar concept is applied virtually for
computing.

Just like a "folder" is not a folder, so "tab" is not a real world
tab, but concept is known from real world and people use it in many
software programs.

The problem that lies in the user who does not know the definition is
solved by looking up the definition. Authors shall not accommodate the
user, but just make sure that the word is used in the context which
indicates the right definition.

Jean

* Juri Linkov <juri@linkov.net> [2019-09-03 21:59]:
> > From Wordnet, see definition 4.
> >
> > * Overview of noun tab
> >
> > The noun tab has 5 senses (no senses from tagged texts)
> > 1. check, chit, tab -- (the bill in a restaurant; he asked the waiter for the check)
> > 2. yellow journalism, tabloid, tab -- (sensationalist journalism)
> > 3. tab key, tab -- (the key on a typewriter or a word processor that causes a tabulation)
> > 4. tab -- (a short strip of material attached to or projecting from
> > something in order to facilitate opening or identifying or handling it;
> > pull the tab to open the can; files with a red tab will be stored
> > separately; the collar has a tab with a button hole; the filing cards
> > were organized by cards having indexed tabs)
> > 5. pill, lozenge, tablet, tab -- (a dose of medicine in the form of a small pellet)
> 
> Wordnet is the most complete indeed and contains definition 4
> that describes this feature, as well as definition 3 of the tab key,
> but it still lacks a third computer-related definition, namely the
> same definition that exists in The Free On-line Dictionary of Computing
> (FOLDOC):
> 
>   TAB
>      <character> (tab, Control-I, HT, ASCII 9) A character which
>      when displayed or printed causes the following character to be
>      placed at the next tabstop - the column whose number is a
>      multiple of the current tab width.  Commonly (especially in
>      Unix(?)) the tab width is eight, so, counting from the left
>      margin (column zero), the tab stops are at columns 8, 16, 24,
>      up to the width of the screen or page.
>      A tab width of four or two is often preferred when indenting
>      program source code to conserve indentation.
>      Represented as \t in C, Unix, and derivatives.

Re: Tabs

[Juri Linkov]

> Thanks for working on this.  I think this feature would be an
> important step forward for Emacs.  I've now checked out and built the
> branch and report my findings below.
>
> (FWIW, I find the names tab-bar-mode and global-tab-line-mode
> confusingly similar.  Could we find better and more descriptive names?
>  For example, global-tab-line-mode could be global-buffer-tab-mode.)

Actually it's more related to window than to buffer.  But
global-window-tab-line-mode would be too long and not easy
to type in e.g. M-x prompt.

> Are you also looking for input regarding potential improvements the
> user interface at this stage?

Yes, please, now is the right time.

> For example, would feedback similar to "I think the width of the tabs
> under tab-bar-mode should be fixed" be helpful?

In browsers the width of each tab depends on the number of tabs
to share tab-bar space proportionally between all tabs.  But we could
add a numeric option for the fixed width.

>> 0. emacs -Q
>> 1. M-x tab-bar-mode RET
>> 2. Click on the plus sign to create a new tab
>> 3. Click on the previous tab
>> 4. Click on the close icon
>
> When saying M-x tab-bar-mode here, the window flickers as if redrawing
> but no tabs show up.  The tabs do show up as soon as I resize the
> window, or move it to a different workspace.  (My window manager is
> XMonad, a tiling window manager, and the Emacs frame is automatically
> set to full screen and moved to a particular workspace after launch.
> Not sure if that helps.)

Thanks, it seems this is an essential detail that might be specific
to your window manager.  Do you see the same problem when saying
M-x tool-bar-mode several times to turn the tool-bar on/off?

Re: Tabs

[Yuri Khan]

On Tue, Sep 3, 2019 at 2:48 AM Juri Linkov <juri@linkov.net> wrote:

> In browsers the width of each tab depends on the number of tabs
> to share tab-bar space proportionally between all tabs.

That is not entirely accurate.

* Tabs start out at some pre-set maximum width (~200–300px?).
* As new tabs are added, after they start pushing against the window
edge, they shrink proportionally to fit, down to some pre-set minimum
width.
* When tabs don’t fit even at their minimum width:
  * Chrome shows the N leftmost tabs that fit, and does not bother
with the rest.
  * Firefox adds scroll arrows at the ends of its tab bar.
    * A somewhat popular mod for Firefox enables multi-row tab bar;
the tab bar grows vertically to accommodate all tabs, until some
pre-set maximum row count. After that, it adds a vertical scroll bar.

Re: Tabs

[Juri Linkov]

>> In browsers the width of each tab depends on the number of tabs
>> to share tab-bar space proportionally between all tabs.
>
> That is not entirely accurate.
>
> * Tabs start out at some pre-set maximum width (~200–300px?).
> * As new tabs are added, after they start pushing against the window
> edge, they shrink proportionally to fit, down to some pre-set minimum
> width.
> * When tabs don’t fit even at their minimum width:
>   * Chrome shows the N leftmost tabs that fit, and does not bother
> with the rest.

This is what surprised me that Chrome does not bother to cope with the
large number of tabs, this looks unprofessional.

>   * Firefox adds scroll arrows at the ends of its tab bar.

Scroll arrows are really more helpful in Firefox.

>     * A somewhat popular mod for Firefox enables multi-row tab bar;
> the tab bar grows vertically to accommodate all tabs, until some
> pre-set maximum row count. After that, it adds a vertical scroll bar.

Perhaps you meant Tab Mix Plus - it can't use Firefox without this
highly useful addon.

Re: Tabs

[Stefan Kangas]

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

Juri Linkov <juri@linkov.net> writes:

> > (FWIW, I find the names tab-bar-mode and global-tab-line-mode
> > confusingly similar.  Could we find better and more descriptive names?
> >  For example, global-tab-line-mode could be global-buffer-tab-mode.)
>
> Actually it's more related to window than to buffer.  But
> global-window-tab-line-mode would be too long and not easy
> to type in e.g. M-x prompt.

What I'm trying to say is that I find the distinction between "tab
bar" and "tab line" confusing.  Of course, one could learn the
difference, but I think this will be somewhat frustrating for new
users.  Perhaps naming them something like "window tabs" and "buffer
tabs" would be more intuitive to also better explain what they are
used for.

> > For example, would feedback similar to "I think the width of the tabs
> > under tab-bar-mode should be fixed" be helpful?
>
> In browsers the width of each tab depends on the number of tabs
> to share tab-bar space proportionally between all tabs.  But we could
> add a numeric option for the fixed width.

In Firefox, the tab is set to a fixed maximum width when there is only
one tab.  When there are too many tabs, it shrinks them to fit them.
There is a minimum width, and once that is reached, Firefox adds
arrows to scroll left or right in the tab bar.  Perhaps we could do
something similar.

> >> 0. emacs -Q
> >> 1. M-x tab-bar-mode RET
> >> 2. Click on the plus sign to create a new tab
> >> 3. Click on the previous tab
> >> 4. Click on the close icon
> >
> > When saying M-x tab-bar-mode here, the window flickers as if redrawing
> > but no tabs show up.  The tabs do show up as soon as I resize the
> > window, or move it to a different workspace.  (My window manager is
> > XMonad, a tiling window manager, and the Emacs frame is automatically
> > set to full screen and moved to a particular workspace after launch.
> > Not sure if that helps.)

I've tested it a bit more, and in addition to the above, I've found
the following cases after running tab-bar-mode:

1. As described above: If I move it to another workspace where it is
the only full screen window, the tab bar will immediately show up.

2. However, I also have workspaces with window manager tabs.  If I
move it to one of these windows after saying M-x tab-bar-mode, I see
the tab bar painted *over* the buffer text.  I can move the point to
the line where the tab bar is painted, and moving the point around
will erase the tab bar and show the buffer text instead.  I've
attached two screenshots to demonstrate (1) before and (2) after
moving the point.  In 2, I moved to the top line in *scratch* and then
moved point to the right a bit.

(In this case too, if I resize the window, the buffer text will "pop
down" (below the tab bar) and the tab bar works as expected -- I can
no longer move point above the tab bar.)

3. I also get the same result (the tab bar painted over the buffer
text) if I put it as the sole window on a full screen workspace, say
M-x tab-bar-mode, and then switch to another workspace and back.

> Thanks, it seems this is an essential detail that might be specific
> to your window manager.  Do you see the same problem when saying
> M-x tool-bar-mode several times to turn the tool-bar on/off?

If I run tool-bar-mode after tab-bar-mode, the tab bar pops up.  If I
run tool-bar-mode to turn it on again, it stays visible.

Best regards,
Stefan Kangas

[-- Attachment #2: tab-bar1.png --]
[-- Type: image/png, Size: 19401 bytes --]

[-- Attachment #3: tab-bar2.png --]
[-- Type: image/png, Size: 20758 bytes --]

Re: Tabs

[Juri Linkov]

>> > (FWIW, I find the names tab-bar-mode and global-tab-line-mode
>> > confusingly similar.  Could we find better and more descriptive names?
>> >  For example, global-tab-line-mode could be global-buffer-tab-mode.)
>>
>> Actually it's more related to window than to buffer.  But
>> global-window-tab-line-mode would be too long and not easy
>> to type in e.g. M-x prompt.
>
> What I'm trying to say is that I find the distinction between "tab
> bar" and "tab line" confusing.

The name "tab bar" resembles frame-local "tool bar" and "menu bar",
whereas "tab line" evokes associations with window-local "header line"
and "mode line".

> Of course, one could learn the
> difference, but I think this will be somewhat frustrating for new
> users.  Perhaps naming them something like "window tabs" and "buffer
> tabs" would be more intuitive to also better explain what they are
> used for.

"buffer tabs" is a wrong name.  Actually there are "frame tab bar"
and "window tab line".  But adding more prefixes "frame-tab-bar-"
and "window-tab-line-" would add more inconvenience, especially
in completion.  Currently it's easy to complete "tab-" <TAB>
then continue either with "bar-" or "line-".  Using "frame-"
and "window-" prefixes for tabs would add more confusion with
frame and window commands.

>> > For example, would feedback similar to "I think the width of the tabs
>> > under tab-bar-mode should be fixed" be helpful?
>>
>> In browsers the width of each tab depends on the number of tabs
>> to share tab-bar space proportionally between all tabs.  But we could
>> add a numeric option for the fixed width.
>
> In Firefox, the tab is set to a fixed maximum width when there is only
> one tab.  When there are too many tabs, it shrinks them to fit them.
> There is a minimum width, and once that is reached, Firefox adds
> arrows to scroll left or right in the tab bar.  Perhaps we could do
> something similar.

I agree.  Is the maximum width measured in pixels or characters?

>> >> 0. emacs -Q
>> >> 1. M-x tab-bar-mode RET
>> >> 2. Click on the plus sign to create a new tab
>> >> 3. Click on the previous tab
>> >> 4. Click on the close icon
>> >
>> > When saying M-x tab-bar-mode here, the window flickers as if redrawing
>> > but no tabs show up.  The tabs do show up as soon as I resize the
>> > window, or move it to a different workspace.  (My window manager is
>> > XMonad, a tiling window manager, and the Emacs frame is automatically
>> > set to full screen and moved to a particular workspace after launch.
>> > Not sure if that helps.)
>
> I've tested it a bit more, and in addition to the above, I've found
> the following cases after running tab-bar-mode:
>
> 1. As described above: If I move it to another workspace where it is
> the only full screen window, the tab bar will immediately show up.
>
> 2. However, I also have workspaces with window manager tabs.  If I
> move it to one of these windows after saying M-x tab-bar-mode, I see
> the tab bar painted *over* the buffer text.  I can move the point to
> the line where the tab bar is painted, and moving the point around
> will erase the tab bar and show the buffer text instead.  I've
> attached two screenshots to demonstrate (1) before and (2) after
> moving the point.  In 2, I moved to the top line in *scratch* and then
> moved point to the right a bit.
>
> (In this case too, if I resize the window, the buffer text will "pop
> down" (below the tab bar) and the tab bar works as expected -- I can
> no longer move point above the tab bar.)
>
> 3. I also get the same result (the tab bar painted over the buffer
> text) if I put it as the sole window on a full screen workspace, say
> M-x tab-bar-mode, and then switch to another workspace and back.

Have you had similar problems in the past with this window manager
and other Emacs components like menus, tool bars, scroll bars?
This might help to debug peculiarities of your window manager.

>> Thanks, it seems this is an essential detail that might be specific
>> to your window manager.  Do you see the same problem when saying
>> M-x tool-bar-mode several times to turn the tool-bar on/off?
>
> If I run tool-bar-mode after tab-bar-mode, the tab bar pops up.  If I
> run tool-bar-mode to turn it on again, it stays visible.

You mean first running of tool-bar-mode disables it?  So the tab bar
pops up and takes place previously used by tool-bar? This means there
is no such problem with tool-bar?

Re: Tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Sun, 01 Sep 2019 22:57:24 +0300
> Cc: emacs-devel@gnu.org
> 
> > To make your branch build on Windows you need to install the attached
> > patch at least (blindly copied from its X counterparts).  Therafter,
> > Emacs builds and comes up normally.
> 
> Thanks, I pushed your patch to the branch.  I hope it would be possible
> to do refactoring on top of your patch to avoid duplicating GUI code
> like Eli asked.

I think such refactoring should be done before the branch is merged.

Thanks.

Re: Tabs

[Juri Linkov]

>> > To make your branch build on Windows you need to install the attached
>> > patch at least (blindly copied from its X counterparts).  Therafter,
>> > Emacs builds and comes up normally.
>> 
>> Thanks, I pushed your patch to the branch.  I hope it would be possible
>> to do refactoring on top of your patch to avoid duplicating GUI code
>> like Eli asked.
>
> I think such refactoring should be done before the branch is merged.

I gather this is opportunity for refactoring of tool-bar code as well.

Re: Tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: rudalics@gmx.at,  emacs-devel@gnu.org
> Date: Mon, 02 Sep 2019 22:29:55 +0300
> 
> >> > To make your branch build on Windows you need to install the attached
> >> > patch at least (blindly copied from its X counterparts).  Therafter,
> >> > Emacs builds and comes up normally.
> >> 
> >> Thanks, I pushed your patch to the branch.  I hope it would be possible
> >> to do refactoring on top of your patch to avoid duplicating GUI code
> >> like Eli asked.
> >
> > I think such refactoring should be done before the branch is merged.
> 
> I gather this is opportunity for refactoring of tool-bar code as well.

Could be, yes.  Although the tool bar is already implemented via
frame-type specific hooks, so some of that work has been done already.

Re: Tabs

[Alan Mackenzie]

Hello, Juri.

On Sat, Aug 31, 2019 at 23:45:07 +0300, Juri Linkov wrote:
> There is a long story of several attempts to implement tabs in Emacs.

I know tabs as things which move visually to the next column 8n.  I only
know vaguely what "tabs" means in this new sense.  A @dfn{tabs} would be
greatly appreciated.

> Finally now a complete implementation is available for these
> etc/TODO tasks:

The documentation in the Emacs manual still needs to be finished.

I've tried several of the new commands on a Linux tty, including
tab-bar-mode, and C-x 6 b.  Although they didn't throw any errors, none
of them appeared to do anything.  Is the new mode intended to work on a
tty?

[ .... ]

> Keybindings for the tab-bar:
>   C-TAB     - switches to the next frame tab;
> S-C-TAB     - switches to the previous frame tab.

I don't think C-TAB and S-C-TAB exist on a typical tty keyboard.  They
don't on the default Linux tty keyboard.

> Clicking on the plus sign adds a new window configuration tab to the tab-bar.

Is there a keyboard equivalent?

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Tabs

[Juri Linkov]

>> There is a long story of several attempts to implement tabs in Emacs.
>
> I know tabs as things which move visually to the next column 8n.  I only
> know vaguely what "tabs" means in this new sense.  A @dfn{tabs} would be
> greatly appreciated.

In text editors and tiling window managers, Tab is a graphical control
element that allows multiple window layouts to be contained within a single
frame, using the tab-bar as a navigational widget for switching between them.

The branch implements two kinds of tabs: frame tabs and window tabs.

Frame tabs are named persistent window configurations that can be
represented visually as rectangular areas on the tab-bar row at the top
of the frame for easy switching, but switching should be also possible
without using the tab-bar.

Window tabs are buffers associated with the window and can be
represented visually as rectangular areas on the tab-line row
at the top of each window.

>> Finally now a complete implementation is available for these
>> etc/TODO tasks:
>
> The documentation in the Emacs manual still needs to be finished.

Agreed, will work on this.

> I've tried several of the new commands on a Linux tty, including
> tab-bar-mode, and C-x 6 b.  Although they didn't throw any errors, none
> of them appeared to do anything.  Is the new mode intended to work on a
> tty?

Thanks for trying.  I guess you tried only frame tabs on a tty
since window tabs are already supported on a tty.

But in case of frame tabs indeed, tab-bar-mode should not be
necessary to be able to use tabs that are just named persistent
window configurations.

So I added to the branch a new mode that can be used by
`M-x list-tabs RTE'.  Like `list-buffers' displays a list of buffers,
`list-tabs' displays a list of named window configurations - the same list
that can be displayed as tabs in the tab-bar when tab-bar-mode is enabled.
Or another analogy of its look is like a widget displayed in the center
of the screen when switching windows in a window manager.

In the list of window configurations, usual keybindings are supported:
RET -- select current line's window configuration.
d -- mark that window configuration to be deleted, and move down.
x -- delete marked window configurations.

>> Keybindings for the tab-bar:
>>   C-TAB     - switches to the next frame tab;
>> S-C-TAB     - switches to the previous frame tab.
>
> I don't think C-TAB and S-C-TAB exist on a typical tty keyboard.  They
> don't on the default Linux tty keyboard.

Web browsers support alternative keys C-<PgUp> and C-<PgDn>.
Are these keys available on a tty?

>> Clicking on the plus sign adds a new window configuration tab to the tab-bar.
>
> Is there a keyboard equivalent?

Yes, 'C-x 6 2' or `M-x make-tab RET'.  And 'C-x 6 0' ('M-x delete-tab RET')
deletes the current tab with its window configuration.

Re: Tabs

[Ergus]

Hi Juri:

Very thanks for this. I have tried your feature branch but it seems to
be working only on gui interface. I tried with -nw in xterm and they are
not working. And disabling the toolbar in gui they didn't work either.

Is this supposed to work like this?

On Sat, Aug 31, 2019 at 11:45:07PM +0300, Juri Linkov wrote:
>There is a long story of several attempts to implement tabs in Emacs.
>Finally now a complete implementation is available for these
>etc/TODO tasks:
>
>  ** "Perspectives" are named persistent window configurations.  We have
>  had the window configuration mechanism in GNU Emacs since the
>  beginning but we have never developed a good user interface to take
>  advantage of them.  Eclipse's user interface seems to be good.
>  Perspectives also need to interact with the tabs.
>
>  ** Having tabs above a window to switch buffers in it.
>
>Frame-local tabs represent window configurations.
>Window-local tabs represent window buffers.
>
>Using such data structures means there is no need in special handling
>of saving tabs in the desktop file - both persistence of frame tabs
>and persistence of window tabs is already supported by the existing
>code in master, because frame tabs are implemented as presentation of
>window configurations in the frame parameter saved by frameset as
>window states, and window tabs are implemented as presentation of
>window buffers already saved by frameset.
>
>Also both implementation of frame tabs and implementation of
>window tabs doesn't require using hooks - frame-local tabs for
>window-configuration switching doesn't rely on hooks and
>window-local tabs for switching window-buffers doesn't use hooks:
>window-configuration-change-hook is not used, no hook
>window-size-change-functions, no buffer-list-update-hook, no
>post-command-hook is used, none of the hooks.
>
>All this makes the implementation as simple as possible,
>providing only code for displaying and manipulating the already
>existing data structures of window configurations and window buffers
>represented in the new display elements tab-bar and tab-line
>based on the existing elements tool-bar and header-line.
>
>The prefix '-bar' in tab-bar is by analogy with frame tool-bar, menu-bar.
>The prefix '-line' in tab-line is by analogy with window header-line, mode-line.
>
>The tab-bar is located above the tool-bar like in web browsers.
>The tab-line is located above the header-line
>that is more related to the current buffer.
>
>Frame-local horizontal interface elements are in this order:
>--- menu-bar ---
>--- tab-bar ---
>--- tool-bar ---
>
>Window-local horizontal interface elements are in this order:
>--- tab-line ---
>--- header-line ---
>--- mode-line ---
>
>The implementation of the tab-bar replicates the existing tool-bar.
>The implementation of the tab-line replicates the existing header-line.
>
>Tabs on the frame tab-bar represent window configurations.
>Tabs on the window tab-line represent window buffers: previous on the
>left side from the current tab (current-buffer) and next on the right.
>
>Clicking on the tab in the tab-bar selects its window configuration.
>Clicking on the tab in the tab-line selects its window buffer.
>Clicking on the close button closes the clicked tab.
>
>Keybindings for the tab-bar:
>  C-TAB     - switches to the next frame tab;
>S-C-TAB     - switches to the previous frame tab.
>Clicking on the plus sign adds a new window configuration tab to the tab-bar.
>
>Keybindings for the tab-line:
>C-x <left>  - switches to the previous window tab;
>C-x <right> - switches to the next window tab.
>Clicking on the plus sign adds a new buffer tab to the tab-line.
>
>'C-x 6 2' creates a new frame-local tab;
>'C-x 6 b' switches to buffer in another frame-local tab;
>'C-x 6 f' and 'C-x 6 C-f' edit file in another frame-local tab.
>
>I invite everyone to try the new branch named 'feature/tabs'
>and to report all found problems.
>
>Authors of all packages that currently had no choice other than to
>misuse the header-line for displaying window tabs are welcome now to
>adapt their packages for displaying window tabs on the new dedicated
>tab-line that doesn't conflict with the header-line anymore.
>For example, I tried just to replace header-line-format with
>tab-line-format in the package awesome-tabs and the result
>shows two separate rows - tab-line and header-line of Info buffer:
>

Re: Tabs

[Juri Linkov]

> Very thanks for this. I have tried your feature branch but it seems to
> be working only on gui interface. I tried with -nw in xterm and they are
> not working. And disabling the toolbar in gui they didn't work either.
>
> Is this supposed to work like this?

I pushed now to the branch a new mode that supports switching tabs
without using the tab-bar in xterm:

'list-tabs' displays a list of named window configurations for switching;
'make-tab' creates a new window configuration;
'delete-tab' deletes the current window configuration;
'switch-to-tab' switches to the window configuration by its name;
'previous-tab' switches to the previous window configuration;
'next-tab' switches to the next window configuration.

All created tabs are still saved in the desktop file.

Re: Tabs

[Ergus]

On Sun, Sep 01, 2019 at 10:31:29PM +0300, Juri Linkov wrote:
>> Very thanks for this. I have tried your feature branch but it seems to
>> be working only on gui interface. I tried with -nw in xterm and they are
>> not working. And disabling the toolbar in gui they didn't work either.
>>
>> Is this supposed to work like this?
>
>I pushed now to the branch a new mode that supports switching tabs
>without using the tab-bar in xterm:
>
>'list-tabs' displays a list of named window configurations for switching;
>'make-tab' creates a new window configuration;
>'delete-tab' deletes the current window configuration;
>'switch-to-tab' switches to the window configuration by its name;
>'previous-tab' switches to the previous window configuration;
>'next-tab' switches to the next window configuration.
>
>All created tabs are still saved in the desktop file.
>
Hi Juri:

All the commands seems to work not throwing any error, but still no
visible tabs are present in xterm at all.

Re: Tabs

[Juri Linkov]

> All the commands seems to work not throwing any error, but still no
> visible tabs are present in xterm at all.

There are no visible tabs present in xterm indeed.
I wonder why would you expect to see tabs even when
can't click them with the mouse in xterm?

Re: Tabs

[Stefan Monnier]

>> All the commands seems to work not throwing any error, but still no
>> visible tabs are present in xterm at all.
>
> There are no visible tabs present in xterm indeed.
> I wonder why would you expect to see tabs even when
> can't click them with the mouse in xterm?

You should be able to make clicks work with xterm-mouse-mode, of
course ;-)


        Stefan "who has no intention to use visible tabs in a tty (nor
                in a GUI, actually)"

Re: Tabs

[Juri Linkov]

>>> All the commands seems to work not throwing any error, but still no
>>> visible tabs are present in xterm at all.
>>
>> There are no visible tabs present in xterm indeed.
>> I wonder why would you expect to see tabs even when
>> can't click them with the mouse in xterm?
>
> You should be able to make clicks work with xterm-mouse-mode, of
> course ;-)

Ah, I see now xterm-mouse-mode works fine - a while ago I tried it
but failed to get it working, so I thought it's something too
specific for some other terminals.

So now I implemented the display of the tab-bar on xterm
and added support for clicking on it to xterm-mouse-mode.

Re: Tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Mon, 02 Sep 2019 22:33:03 +0300
> Cc: emacs-devel@gnu.org
> 
> > All the commands seems to work not throwing any error, but still no
> > visible tabs are present in xterm at all.
> 
> There are no visible tabs present in xterm indeed.
> I wonder why would you expect to see tabs even when
> can't click them with the mouse in xterm?

Why cannot we support the mouse in text-mode frames?  We have several
possible features for such support, including GPM, xterm-mouse, the
MS-Windows and MS-DOS text-mode mouse functionality, etc.  I think we
the tab bar should be able to support these.

Re: Tabs

[Juri Linkov]

>> > All the commands seems to work not throwing any error, but still no
>> > visible tabs are present in xterm at all.
>>
>> There are no visible tabs present in xterm indeed.
>> I wonder why would you expect to see tabs even when
>> can't click them with the mouse in xterm?
>
> Why cannot we support the mouse in text-mode frames?  We have several
> possible features for such support, including GPM, xterm-mouse, the
> MS-Windows and MS-DOS text-mode mouse functionality, etc.  I think we
> the tab bar should be able to support these.

I implemented now the display and support of the mouse in text-mode frames
and pushed to the feature/tabs branch in commit a365251d01.

Re: Tabs

[Ergus]

On Mon, Sep 02, 2019 at 10:33:03PM +0300, Juri Linkov wrote:
>> All the commands seems to work not throwing any error, but still no
>> visible tabs are present in xterm at all.
>
>There are no visible tabs present in xterm indeed.
>I wonder why would you expect to see tabs even when

Actually because vim has them.

>can't click them with the mouse in xterm?

elscreen actually allows me to use the mouse (I don't do, but I could)
emacs interacts with the mouse in xterm very fine... no reason to not
support that I think.

Re: Tabs

[Ergus]

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

Hi Juri:

They are working pretty well now, mouse interaction too. Very thanks. I
just have 2 more questions/suggestions mainly relates with aesthetics.

1) Is it possible to avoid changing the current tab name to "Current
Tab"; and just change the background color for example? I know the
current tab name is in the mode-line ; but that's the behavior of most
tabs around. Maybe we can just add a bollean variable to customize the
changes (if not too complex) in case you prefer it like this.

2) In xterm I observe a padding between consecutive tabs (attached
pictures) and the close circle is incomplete. That's usually a
consequence of displaying some unicode characters in terminal. Can we
avoid that somehow?

Very thanks for this package.
It is very useful!!

On Mon, Sep 02, 2019 at 10:33:03PM +0300, Juri Linkov wrote:
>> All the commands seems to work not throwing any error, but still no
>> visible tabs are present in xterm at all.
>
>There are no visible tabs present in xterm indeed.
>I wonder why would you expect to see tabs even when
>can't click them with the mouse in xterm?

[-- Attachment #2: Screenshot_2019-09-06_00-21-15.png --]
[-- Type: image/png, Size: 8270 bytes --]

Re: Tabs

[Juri Linkov]

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

> They are working pretty well now, mouse interaction too. Very thanks. I
> just have 2 more questions/suggestions mainly relates with aesthetics.
>
> 1) Is it possible to avoid changing the current tab name to "Current
> Tab"; and just change the background color for example? I know the
> current tab name is in the mode-line ; but that's the behavior of most
> tabs around. Maybe we can just add a bollean variable to customize the
> changes (if not too complex) in case you prefer it like this.

Thanks for the suggestion.  I completely agree that your described
behavior is better.  With the fixed tab name I tried to avoid tab
jumping when tab location moves due to changes in tab width that
shifts other tabs after the current one.

Now this is fixed to avoid changing the current tab name.

> 2) In xterm I observe a padding between consecutive tabs (attached
> pictures) and the close circle is incomplete. That's usually a
> consequence of displaying some unicode characters in terminal.

Yeah, this is how Unicode characters are treated by terminals.
And this problem is not specific to Emacs.  The same clobbering
can be seen even in terminal shell:


[-- Attachment #2: xterm-unicode.png --]
[-- Type: image/png, Size: 3957 bytes --]

[-- Attachment #3: Type: text/plain, Size: 116 bytes --]


> Can we avoid that somehow?

Now to avoid this I added space after Unicode characters
only on non-window systems.

Re: Tabs

[Stefan Monnier]

> 'list-tabs' displays a list of named window configurations for switching;
> 'make-tab' creates a new window configuration;
> 'delete-tab' deletes the current window configuration;
> 'switch-to-tab' switches to the window configuration by its name;
> 'previous-tab' switches to the previous window configuration;
> 'next-tab' switches to the next window configuration.

Any chance you could use "tab-<foo>" instead of "<foo>-tab"?


        Stefan

Re: Tabs

[Juri Linkov]

>> 'list-tabs' displays a list of named window configurations for switching;
>> 'make-tab' creates a new window configuration;
>> 'delete-tab' deletes the current window configuration;
>> 'switch-to-tab' switches to the window configuration by its name;
>> 'previous-tab' switches to the previous window configuration;
>> 'next-tab' switches to the next window configuration.
>
> Any chance you could use "tab-<foo>" instead of "<foo>-tab"?

These names were created by analogy with the existing frame/buffer commands:

list-tabs like list-buffers
make-tab like make-frame
delete-tab like delete-frame
switch-to-tab like switch-to-buffer
previous-tab like previous-buffer
next-tab like next-buffer

But I don't like such naming convention too much.  I'd rather like
to type M-x tab- TAB to see all available related commands as completions:

tab-list
tab-make
tab-delete
tab-switch
tab-previous
tab-next

Re: Tabs

[Stefan Monnier]

> These names were created by analogy with the existing frame/buffer commands:

Yeah, I don't like their lack of prefix-naming either.  :-(


        Stefan

Re: Tabs

[Robert Pluim]

>>>>> On Sat, 31 Aug 2019 23:45:07 +0300, Juri Linkov <juri@linkov.net> said:

    Juri> There is a long story of several attempts to implement tabs in Emacs.
    Juri> Finally now a complete implementation is available for these
    Juri> etc/TODO tasks:

Hi Juri, this fails to compile for me on macOS 10.14. Iʼm
Cocoa-ignorant, are there some flags I need to pass to get access to
the tabbar types?

make[1]: Nothing to be done for `all'.
/Library/Developer/CommandLineTools/usr/bin/make -C src VCSWITNESS='' all
  CC       nsterm.o
In file included from nsterm.m:49:
./nsterm.h:529:36: error: cannot find protocol declaration for 'NSTabbarDelegate'; did
      you mean 'NSToolbarDelegate'?
@interface EmacsTabbar : NSTabbar <NSTabbarDelegate>
                                   ^~~~~~~~~~~~~~~~
                                   NSToolbarDelegate
/System/Library/Frameworks/AppKit.framework/Headers/NSToolbar.h:172:11: note: 
      'NSToolbarDelegate' declared here
@protocol NSToolbarDelegate <NSObject>
          ^
In file included from nsterm.m:49:
./nsterm.h:529:26: error: cannot find interface declaration for 'NSTabbar', superclass
      of 'EmacsTabbar'
@interface EmacsTabbar : NSTabbar <NSTabbarDelegate>
~~~~~~~~~~~~~~~~~~~~~~   ^
./nsterm.h:551:4: error: expected a type
- (NSTabbarItem *)tabbar: (NSTabbar *)tabbar
   ^
./nsterm.h:551:28: error: expected a type
- (NSTabbarItem *)tabbar: (NSTabbar *)tabbar
                           ^
./nsterm.h:554:45: error: expected a type
- (NSArray *)tabbarDefaultItemIdentifiers: (NSTabbar *)tabbar;
                                            ^
./nsterm.h:555:45: error: expected a type
- (NSArray *)tabbarAllowedItemIdentifiers: (NSTabbar *)tabbar;
                                            ^
nsterm.m:1092:27: warning: implicit declaration of function 'FRAME_EXTERNAL_TAB_BAR' is
      invalid in C99 [-Wimplicit-function-declaration]
    BOOL tarbar_visible = FRAME_EXTERNAL_TAB_BAR (f) ? YES : NO;
                          ^
nsterm.m:1093:5: error: use of undeclared identifier 'NSTabbar'
    NSTabbar *tabbar = [FRAME_NS_VIEW (f) tabbar];
    ^
nsterm.m:1093:15: error: use of undeclared identifier 'tabbar'; did you mean
      'Qtab_bar'?
    NSTabbar *tabbar = [FRAME_NS_VIEW (f) tabbar];
              ^~~~~~
              Qtab_bar
./globals.h:3139:21: note: 'Qtab_bar' declared here
DEFINE_LISP_SYMBOL (Qtab_bar)
                    ^
nsterm.m:1094:32: error: use of undeclared identifier 'tabbar'; did you mean
      'Qtab_bar'?
    if (! tarbar_visible != ! [tabbar isVisible])
                               ^~~~~~
                               Qtab_bar
./globals.h:3139:21: note: 'Qtab_bar' declared here
DEFINE_LISP_SYMBOL (Qtab_bar)
                    ^
nsterm.m:1094:32: warning: receiver type 'Lisp_Object' (aka 'union Lisp_X *') is not
      'id' or interface pointer, consider casting it to 'id' [-Wreceiver-expr]
    if (! tarbar_visible != ! [tabbar isVisible])
                               ^~~~~~
nsterm.m:1095:8: error: use of undeclared identifier 'tabbar'; did you mean 'Qtab_bar'?
      [tabbar setVisible: tarbar_visible];
       ^~~~~~
       Qtab_bar
./globals.h:3139:21: note: 'Qtab_bar' declared here
DEFINE_LISP_SYMBOL (Qtab_bar)
                    ^
nsterm.m:1095:8: warning: receiver type 'Lisp_Object' (aka 'union Lisp_X *') is not
      'id' or interface pointer, consider casting it to 'id' [-Wreceiver-expr]
      [tabbar setVisible: tarbar_visible];
       ^~~~~~
nsterm.m:1690:18: warning: 'NSWindow' may not respond to 'tabbar'
               - FRAME_TABBAR_HEIGHT (f) - FRAME_TOOLBAR_HEIGHT (f))
                 ^~~~~~~~~~~~~~~~~~~~~~~
./nsterm.h:1086:33: note: expanded from macro 'FRAME_TABBAR_HEIGHT'
  (([[FRAME_NS_VIEW (f) window] tabbar] == nil                          \
     ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
nsterm.m:1690:18: warning: 'NSWindow' may not respond to 'tabbar'
               - FRAME_TABBAR_HEIGHT (f) - FRAME_TOOLBAR_HEIGHT (f))
                 ^~~~~~~~~~~~~~~~~~~~~~~
./nsterm.h:1087:38: note: expanded from macro 'FRAME_TABBAR_HEIGHT'
    || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ?               \
          ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
nsterm.m:1690:18: error: property 'isVisible' not found on object of type
      'EmacsTabbar *'
./nsterm.h:1087:46: note: expanded from macro 'FRAME_TABBAR_HEIGHT'
    || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ?               \
                                             ^
nsterm.m:1708:56: warning: 'NSWindow' may not respond to 'tabbar'
  ...f->top_pos = FRAME_PIXEL_HEIGHT (parent) + FRAME_TABBAR_HEIGHT (parent) + FRAME...
                                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
./nsterm.h:1086:33: note: expanded from macro 'FRAME_TABBAR_HEIGHT'
  (([[FRAME_NS_VIEW (f) window] tabbar] == nil                          \
     ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
nsterm.m:1708:56: warning: 'NSWindow' may not respond to 'tabbar'
  ...f->top_pos = FRAME_PIXEL_HEIGHT (parent) + FRAME_TABBAR_HEIGHT (parent) + FRAME...
                                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
./nsterm.h:1087:38: note: expanded from macro 'FRAME_TABBAR_HEIGHT'
    || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ?               \
          ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
nsterm.m:1708:56: error: property 'isVisible' not found on object of type
      'EmacsTabbar *'
./nsterm.h:1087:46: note: expanded from macro 'FRAME_TABBAR_HEIGHT'
    || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ?               \
                                             ^
nsterm.m:1771:9: warning: 'NSWindow' may not respond to 'tabbar'
      + FRAME_TABBAR_HEIGHT (f)
        ^~~~~~~~~~~~~~~~~~~~~~~
./nsterm.h:1086:33: note: expanded from macro 'FRAME_TABBAR_HEIGHT'
  (([[FRAME_NS_VIEW (f) window] tabbar] == nil                          \
     ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
nsterm.m:1771:9: warning: 'NSWindow' may not respond to 'tabbar'
      + FRAME_TABBAR_HEIGHT (f)
        ^~~~~~~~~~~~~~~~~~~~~~~
./nsterm.h:1087:38: note: expanded from macro 'FRAME_TABBAR_HEIGHT'
    || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ?               \
          ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
nsterm.m:1771:9: error: property 'isVisible' not found on object of type
      'EmacsTabbar *'
./nsterm.h:1087:46: note: expanded from macro 'FRAME_TABBAR_HEIGHT'
    || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ?               \
                                             ^
nsterm.m:1788:18: warning: 'NSWindow' may not respond to 'tabbar'
           make_fixnum (FRAME_TABBAR_HEIGHT (f) + FRAME_TOOLBAR_HEIGHT (f))));
                        ^~~~~~~~~~~~~~~~~~~~~~~
./nsterm.h:1086:33: note: expanded from macro 'FRAME_TABBAR_HEIGHT'
  (([[FRAME_NS_VIEW (f) window] tabbar] == nil                          \
     ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
nsterm.m:1788:18: warning: 'NSWindow' may not respond to 'tabbar'
           make_fixnum (FRAME_TABBAR_HEIGHT (f) + FRAME_TOOLBAR_HEIGHT (f))));
                        ^~~~~~~~~~~~~~~~~~~~~~~
./nsterm.h:1087:38: note: expanded from macro 'FRAME_TABBAR_HEIGHT'
    || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ?               \
          ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
nsterm.m:1788:18: error: property 'isVisible' not found on object of type
      'EmacsTabbar *'
./nsterm.h:1087:46: note: expanded from macro 'FRAME_TABBAR_HEIGHT'
    || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ?               \
                                             ^
nsterm.m:1830:19: warning: instance method '-setTabbar:' not found (return type
      defaults to 'id') [-Wobjc-method-access]
          [window setTabbar: nil];
                  ^~~~~~~~~
/System/Library/Frameworks/AppKit.framework/Headers/NSWindow.h:184:12: note: receiver
      is instance of class declared here
@interface NSWindow : NSResponder <NSAnimatablePropertyContainer, NSMenuItemVal...
           ^
nsterm.m:2415:47: warning: 'NSWindow' may not respond to 'tabbar'
                FRAME_NS_TITLEBAR_HEIGHT(f) + FRAME_TABBAR_HEIGHT(f) + FRAME_TO...
                                              ^~~~~~~~~~~~~~~~~~~~~~
./nsterm.h:1086:33: note: expanded from macro 'FRAME_TABBAR_HEIGHT'
  (([[FRAME_NS_VIEW (f) window] tabbar] == nil                          \
     ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
nsterm.m:2415:47: warning: 'NSWindow' may not respond to 'tabbar'
                FRAME_NS_TITLEBAR_HEIGHT(f) + FRAME_TABBAR_HEIGHT(f) + FRAME_TO...
                                              ^~~~~~~~~~~~~~~~~~~~~~
./nsterm.h:1087:38: note: expanded from macro 'FRAME_TABBAR_HEIGHT'
    || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ?               \
          ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
nsterm.m:2415:47: error: property 'isVisible' not found on object of type
      'EmacsTabbar *'
./nsterm.h:1087:46: note: expanded from macro 'FRAME_TABBAR_HEIGHT'
    || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ?               \
                                             ^
nsterm.m:2778:26: warning: 'scrollRect:by:' is deprecated: first deprecated in macOS
      10.14 - Use NSScrollView to achieve scrolling views. [-Wdeprecated-declarations]
      [FRAME_NS_VIEW (f) scrollRect: src by: delta];
                         ^
/System/Library/Frameworks/AppKit.framework/Headers/NSView.h:260:1: note: 
      'scrollRect:by:' has been explicitly marked deprecated here
- (void)scrollRect:(NSRect)rect by:(NSSize)delta NS_DEPRECATED_MAC(10_0, 10_14...
^
nsterm.m:5449:29: warning: 'NSFilenamesPboardType' is deprecated: first deprecated in
      macOS 10.14 - Create multiple pasteboard items with NSPasteboardTypeFileURL or
      kUTTypeFileURL instead [-Wdeprecated-declarations]
                            NSFilenamesPboardType,
                            ^
/System/Library/Frameworks/AppKit.framework/Headers/NSPasteboard.h:323:32: note: 
      'NSFilenamesPboardType' has been explicitly marked deprecated here
APPKIT_EXTERN NSPasteboardType NSFilenamesPboardType NS_DEPRECATED_MAC(10_0, 10...
                               ^
nsterm.m:6972:23: warning: 'NSWindow' may not respond to 'tabbar'
      tabbar_height = FRAME_TABBAR_HEIGHT (emacsframe);
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./nsterm.h:1086:33: note: expanded from macro 'FRAME_TABBAR_HEIGHT'
  (([[FRAME_NS_VIEW (f) window] tabbar] == nil                          \
     ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
nsterm.m:6972:23: warning: 'NSWindow' may not respond to 'tabbar'
      tabbar_height = FRAME_TABBAR_HEIGHT (emacsframe);
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./nsterm.h:1087:38: note: expanded from macro 'FRAME_TABBAR_HEIGHT'
    || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ?               \
          ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
nsterm.m:6972:23: error: property 'isVisible' not found on object of type
      'EmacsTabbar *'
./nsterm.h:1087:46: note: expanded from macro 'FRAME_TABBAR_HEIGHT'
    || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ?               \
                                             ^
nsterm.m:6988:11: warning: 'NSWindow' may not respond to 'tabbar'
      if (FRAME_TABBAR_HEIGHT (emacsframe) == 0
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./nsterm.h:1086:33: note: expanded from macro 'FRAME_TABBAR_HEIGHT'
  (([[FRAME_NS_VIEW (f) window] tabbar] == nil                          \
     ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
nsterm.m:6988:11: warning: 'NSWindow' may not respond to 'tabbar'
      if (FRAME_TABBAR_HEIGHT (emacsframe) == 0
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./nsterm.h:1087:38: note: expanded from macro 'FRAME_TABBAR_HEIGHT'
    || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ?               \
          ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
nsterm.m:6988:11: error: property 'isVisible' not found on object of type
      'EmacsTabbar *'
./nsterm.h:1087:46: note: expanded from macro 'FRAME_TABBAR_HEIGHT'
    || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ?               \
                                             ^
nsterm.m:7091:11: warning: 'NSWindow' may not respond to 'tabbar'
        + FRAME_TABBAR_HEIGHT (emacsframe)
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./nsterm.h:1086:33: note: expanded from macro 'FRAME_TABBAR_HEIGHT'
  (([[FRAME_NS_VIEW (f) window] tabbar] == nil                          \
     ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
nsterm.m:7091:11: warning: 'NSWindow' may not respond to 'tabbar'
        + FRAME_TABBAR_HEIGHT (emacsframe)
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./nsterm.h:1087:38: note: expanded from macro 'FRAME_TABBAR_HEIGHT'
    || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ?               \
          ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
nsterm.m:7091:11: error: property 'isVisible' not found on object of type
      'EmacsTabbar *'
./nsterm.h:1087:46: note: expanded from macro 'FRAME_TABBAR_HEIGHT'
    || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ?               \
                                             ^
nsterm.m:7323:26: warning: class method '+alloc' not found (return type defaults to
      'id') [-Wobjc-method-access]
  tabbar = [[EmacsTabbar alloc] initForView: self withIdentifier:
                         ^~~~~
nsterm.m:7326:11: warning: 'EmacsTabbar' may not respond to 'setVisible:'
  [tabbar setVisible: NO];
   ~~~~~~ ^
nsterm.m:7327:11: warning: instance method '-setTabbar:' not found (return type
      defaults to 'id') [-Wobjc-method-access]
  [window setTabbar: tabbar];
          ^~~~~~~~~
/System/Library/Frameworks/AppKit.framework/Headers/NSWindow.h:184:12: note: receiver
      is instance of class declared here
@interface NSWindow : NSResponder <NSAnimatablePropertyContainer, NSMenuItemVal...
           ^
nsterm.m:7331:7: warning: implicit declaration of function 'FRAME_EXTERNAL_TAB_BAR' is
      invalid in C99 [-Wimplicit-function-declaration]
  if (FRAME_EXTERNAL_TAB_BAR (f)) wait_for_tab_bar = YES;
      ^
nsterm.m:7338:50: error: use of undeclared identifier 'NSWindowTabbarButton'; did you
      mean 'NSWindowToolbarButton'?
    toggleButton = [window standardWindowButton: NSWindowTabbarButton];
                                                 ^~~~~~~~~~~~~~~~~~~~
                                                 NSWindowToolbarButton
/System/Library/Frameworks/AppKit.framework/Headers/NSWindow.h:153:5: note: 
      'NSWindowToolbarButton' declared here
    NSWindowToolbarButton,
    ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
26 warnings and 20 errors generated.
make[1]: *** [nsterm.o] Error 1
make: *** [src] Error 2

Compilation exited abnormally with code 2 at Tue Sep  3 14:15:42

Re: Tabs

[Juri Linkov]

> Hi Juri, this fails to compile for me on macOS 10.14. Iʼm
> Cocoa-ignorant, are there some flags I need to pass to get access to
> the tabbar types?

Thanks for sending the compilation log.  I have no access to macOS,
so I really count on your help in this area.  I tried to fix these
compilation errors only by looking at your log, please try to compile again.

Re: Tabs

[Stefan Kangas]

Hi Juri,

Again, thanks for working on this.  I have now tested the tabs branch, and I
have some feedback for the tab line (buffer tabs).

Juri Linkov <juri@linkov.net> writes:

> Keybindings for the tab-line:
> C-x <left>  - switches to the previous window tab;
> C-x <right> - switches to the next window tab.

1. When I run C-x <left> or C-x <right>, it automatically creates a new tab with
the next buffer.  I'd rather it switched between the open tabs, and have a
separate command to create a new tab.  I believe this would be more in line with
how tabs work in other software, and therefore more intuitive.

2. None of these interactive commands work when run with M-x:

command-execute: tab-line-add-tab must be bound to an event with parameters
command-execute: tab-line-close-tab must be bound to an event with parameters
command-execute: tab-line-select-tab must be bound to an event with parameters
command-execute: tab-line-switch-to-next-tab must be bound to an event
with parameters
command-execute: tab-line-switch-to-prev-tab must be bound to an event
with parameters

3. It would then be good to have key bindings for the above commands.

> Clicking on the plus sign adds a new buffer tab to the tab-line.

4. I'm not super fond of that you have to navigate a menu in order to create a
new tab.  In e.g. Firefox you get a new "empty tab" when clicking the plus to
add a new tab.  I suppose in Emacs that would correspond to a window with no
buffer, but I don't think this makes much sense (if it's even possible).

Perhaps the tab could just show the next buffer like C-x <left> and C-x <right>
does right now?  This behaviour could of course be configurable, so that you
optionally display the menu for users who like that.  I suggest that the menu is
the optional non-default behaviour.

-----

Here are some suggestions that are less fundamental, listed in no particular
order.

5. When I hover inactive tabs with the mouse, only the name of the tab is
highlighted.  Can we get the entire tab highlighted instead, including the
section where the close button is?

6. When I hover the close button on the currently active tab, I get a grey line
between the tab name and the button.  Could we get rid of that line?

7. The active tab seems to be the same color in both the currently active window
and in other windows.  Could we perhaps color the active tab differently
depending on if it's in the active window or not?

8. In Firefox, the close tab button is not visible unless that tab is selected.
Perhaps that behaviour makes more sense, especially if we also implement the
"fixed size tabs that shrinks to fit" behaviour discussed elsewhere (because
smaller tabs make it too easy to accidentally click the close button).

9. It would probably look better if there was a couple of pixels of padding
between the tab name and the edge of the tab.

10. Could we make the "+" sign (to add more tabs) more visually
distinct from the
tabs?  For example, it could have no borders.

11. Could we add a tooltip with the name of the buffer to the tabs?

12. The inactive tabs seem to have a shade to the bottom and right.  I think
that makes them look more like "buttons" than "tabs".  Perhaps we could rethink
this and just make them one solid color without the shading.

13. It would be nice if the tabs had rounded corners on the top by default.

14. Could we add a vertical line below the tabs to separate it from the buffer?
I find that the name of the tab visually melts into the buffer.  (This effect
would probably be less visible if the tab line was in an even darker color -- I
checked some screenshots of Eclipse and that's the solution they seem to have.)
Perhaps a vertical bar could be optional.  Perhaps we could somehow allow to
configure the color of the tab line.

Best regards,
Stefan Kangas

Re: Tabs

[Juri Linkov]

> I have now tested the tabs branch, and I have some feedback

Thanks for valuable feedback.

>> Keybindings for the tab-line:
>> C-x <left>  - switches to the previous window tab;
>> C-x <right> - switches to the next window tab.
>
> 1. When I run C-x <left> or C-x <right>, it automatically creates a new tab with
> the next buffer.  I'd rather it switched between the open tabs, and have a
> separate command to create a new tab.  I believe this would be more in line with
> how tabs work in other software, and therefore more intuitive.

If an inactive tab is displayed to the left from the currently active tab,
do you mean that 'C-x <left>' doesn't switch to it but instead creates a new tab?

> 2. None of these interactive commands work when run with M-x:
>
> command-execute: tab-line-add-tab must be bound to an event with parameters
> command-execute: tab-line-close-tab must be bound to an event with parameters
> command-execute: tab-line-select-tab must be bound to an event with parameters
> command-execute: tab-line-switch-to-next-tab must be bound to an event
> with parameters
> command-execute: tab-line-switch-to-prev-tab must be bound to an event
> with parameters

Mouse commands don't work with M-x.  For example, try M-x Buffer-menu-mouse-select
but we could declare the EVENT arg optional for these commands,
and perform non-mouse logic when it's nil.

> 3. It would then be good to have key bindings for the above commands.

tab-line-switch-to-prev-tab is already the same as 'C-x <left>'
tab-line-switch-to-next-tab is already the same as 'C-x <right>'
tab-line-add-tab is the same as 'C-x b' or any other buffer switching command
tab-line-close-tab is the same as bury-buffer or quit-window (`q')
only tab-line-select-tab could have a keybinding for referring tab by its
absolute position.

>> Clicking on the plus sign adds a new buffer tab to the tab-line.
>
> 4. I'm not super fond of that you have to navigate a menu in order to create a
> new tab.  In e.g. Firefox you get a new "empty tab" when clicking the plus to
> add a new tab.  I suppose in Emacs that would correspond to a window with no
> buffer, but I don't think this makes much sense (if it's even possible).
>
> Perhaps the tab could just show the next buffer like C-x <left> and C-x <right>
> does right now?  This behaviour could of course be configurable, so that you
> optionally display the menu for users who like that.  I suggest that the menu is
> the optional non-default behaviour.

I agree this should be configurable, like in e.g. Firefox a new tab page
is configurable.

> -----
>
> Here are some suggestions that are less fundamental, listed in no particular
> order.
>
> 5. When I hover inactive tabs with the mouse, only the name of the tab is
> highlighted.  Can we get the entire tab highlighted instead, including the
> section where the close button is?

This is fixed now in the branch.

> 6. When I hover the close button on the currently active tab, I get a grey line
> between the tab name and the button.  Could we get rid of that line?

This is fixed now.

> 7. The active tab seems to be the same color in both the currently active window
> and in other windows.  Could we perhaps color the active tab differently
> depending on if it's in the active window or not?

This is an interesting suggestion, I'd never thought about such distinction,
but it could be useful for additional indication of the currently selected
window, like different faces of the mode-line indicate the selected window.

> 8. In Firefox, the close tab button is not visible unless that tab is selected.
> Perhaps that behaviour makes more sense, especially if we also implement the
> "fixed size tabs that shrinks to fit" behaviour discussed elsewhere (because
> smaller tabs make it too easy to accidentally click the close button).

This Firefox behaviour is very inconvenient - to be able to close
several tabs in a row I have first to switch to each of them that starts
loading the page, so browser hangs for a while - very frustrating experience.
Chromium close buttons on every tab are much better.  However, you can set
the close button variable to nil to disable close buttons.

> 9. It would probably look better if there was a couple of pixels of padding
> between the tab name and the edge of the tab.

Is this possible in Emacs?  Could you please show an example of a text property
that would put e.g. 5 pixels between characters in string.

> 10. Could we make the "+" sign (to add more tabs) more visually
> distinct from the tabs?  For example, it could have no borders.

This is fixed now in the branch.

> 11. Could we add a tooltip with the name of the buffer to the tabs?

A tooltip is added only when the buffer name is truncated.

> 12. The inactive tabs seem to have a shade to the bottom and right.  I think
> that makes them look more like "buttons" than "tabs".  Perhaps we could rethink
> this and just make them one solid color without the shading.

This is fixed now in the branch.

> 13. It would be nice if the tabs had rounded corners on the top by default.

I agree, this is on my TODO list, hope to implement next week if I'll have time.

> 14. Could we add a vertical line below the tabs to separate it from the buffer?
> I find that the name of the tab visually melts into the buffer.  (This effect
> would probably be less visible if the tab line was in an even darker color -- I
> checked some screenshots of Eclipse and that's the solution they seem to have.)
> Perhaps a vertical bar could be optional.  Perhaps we could somehow allow to
> configure the color of the tab line.

This is fixed now in the branch, please try it.

Re: Tabs

[Yuri Khan]

On Mon, 16 Sep 2019 at 05:13, Juri Linkov <juri@linkov.net> wrote:

> > 8. In Firefox, the close tab button is not visible unless that tab is selected.
>
> This Firefox behaviour is very inconvenient - to be able to close
> several tabs in a row I have first to switch to each of them that starts
> loading the page, so browser hangs for a while - very frustrating experience.
> Chromium close buttons on every tab are much better.  However, you can set
> the close button variable to nil to disable close buttons.

Don’t people mostly close tabs using the middle button click or a
keyboard shortcut? This removes the need for close buttons altogether.

Re: Tabs

[Juri Linkov]

>> > 8. In Firefox, the close tab button is not visible unless that tab is selected.
>>
>> This Firefox behaviour is very inconvenient - to be able to close
>> several tabs in a row I have first to switch to each of them that starts
>> loading the page, so browser hangs for a while - very frustrating experience.
>> Chromium close buttons on every tab are much better.  However, you can set
>> the close button variable to nil to disable close buttons.
>
> Don’t people mostly close tabs using the middle button click or a
> keyboard shortcut? This removes the need for close buttons altogether.

I didn't know that the middle button click can close the tab in browser,
because clicking on the close icon is more reliable since clicking
the same mouse button caused different actions in different browsers with
no consistent behaviour (maybe they are more consistent now I don't know).
But after trying I see that pressing the wheel button requires more effort
and is less reliable since might cause scrolling before pressing
(BTW, tab scrolling with the wheel is already supported in the branch).
Currently in the branch Ctrl key in combination with mouse click
closes the tab, but the middle button click could be supported as well.
Regarding a keyboard shortcut, do you mean C-w?

Tabs

[Yuri Khan]

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

On Tue, Sep 17, 2019, 04:15 Juri Linkov <juri@linkov.net> wrote:

> But after trying I see that pressing the wheel button requires more effort
> and is less reliable since might cause scrolling before pressing

This is a deficiency of your mouse. Good mice let you middle-click easily
and reliably. Excellent mice have a middle button separate from the wheel.

> Regarding a keyboard shortcut, do you mean C-w?

In browsers, yes (sometimes also Ctrl+F4). In Emacs, that would probably
translate to the usual ‘kill-buffer’ binding the user prefers.

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

Re: Tabs

[Juri Linkov]

>> But after trying I see that pressing the wheel button requires more effort
>> and is less reliable since might cause scrolling before pressing
>
> This is a deficiency of your mouse. Good mice let you middle-click easily
> and reliably. Excellent mice have a middle button separate from the wheel.

Yeah, but mice with more buttons grow larger and compete with keyboards
by their dimensions :)

>> Regarding a keyboard shortcut, do you mean C-w?
>
> In browsers, yes (sometimes also Ctrl+F4). In Emacs, that would probably
> translate to the usual ‘kill-buffer’ binding the user prefers.

Since C-w can't be used then this is what remains indeed.

Fortunately, C-S-t is free to use for tab close undo feature
since only C-t is bound to transpose-chars, not C-S-t.

RE: Tabs

[Drew Adams]

> Fortunately, C-S-t is free to use for tab close undo feature
> since only C-t is bound to transpose-chars, not C-S-t.

[Caveat: I'm no expert on any of this; I haven't followed
this (long!) thread much]; and I don't use a tab bar.]

I thought you guys were discussing key bindings local to
the tab bar.  But when you speak of `C-t' being bound to
`transpose-chars' I wonder - sounds like you're talking
about the global keymap instead.

FWIW, I'm not a fan of dedicating a global key, by default,
for this kind of thing.

Also, it can be overridden by major and minor modes.  In
Dired buffers, for example, `C-t' is a prefix key for
`image-dired-*' commands.  Sure, `C-S-t' could be made
to do something different from `C-t', but do we really
want that here?

In addition, `C-t' and `C-S-t' are repeatable keys (just
hold them down to repeat the command).  If we're talking
now about using `C-S-t' for something other than the
longstanding global`C-t' behavior (`transpose-char') then
I'd prefer that it be saved for some repeatable command,
i.e., a command that it makes sense to be able to repeat
by just holding a key/chord pressed.

Re: Tabs

[Stefan Kangas]

Juri Linkov <juri@linkov.net> writes:

> > 1. When I run C-x <left> or C-x <right>, it automatically creates a new tab with
> > the next buffer.  I'd rather it switched between the open tabs, and have a
> > separate command to create a new tab.  I believe this would be more in line with
> > how tabs work in other software, and therefore more intuitive.
>
> If an inactive tab is displayed to the left from the currently active tab,
> do you mean that 'C-x <left>' doesn't switch to it but instead creates a new tab?

When I do:

0. emacs -Q
1. M-x global-tab-line-mode
1. C-x <left>

I see a new tab open up with the *Messages* buffer.  I would expect it
to not open up a new tab when I just ask to see the next or previous
tab.

> > 2. None of these interactive commands work when run with M-x:
> >
> > command-execute: tab-line-add-tab must be bound to an event with parameters
> > command-execute: tab-line-close-tab must be bound to an event with parameters
> > command-execute: tab-line-select-tab must be bound to an event with parameters
> > command-execute: tab-line-switch-to-next-tab must be bound to an event
> > with parameters
> > command-execute: tab-line-switch-to-prev-tab must be bound to an event
> > with parameters
>
> Mouse commands don't work with M-x.  For example, try M-x Buffer-menu-mouse-select

True.

> but we could declare the EVENT arg optional for these commands,
> and perform non-mouse logic when it's nil.

This is what I would prefer.  I think users will naturally try to use
these commands and be surprised when they don't work.

> > 3. It would then be good to have key bindings for the above commands.
>
> tab-line-switch-to-prev-tab is already the same as 'C-x <left>'
> tab-line-switch-to-next-tab is already the same as 'C-x <right>'
> tab-line-add-tab is the same as 'C-x b' or any other buffer switching command
> tab-line-close-tab is the same as bury-buffer or quit-window (`q')

Interesting.  Could the doc strings for the tab-line-* commands refer
to the corresponding functions?  I think that would help lessen the
confusion.

> only tab-line-select-tab could have a keybinding for referring tab by its
> absolute position.

That would be good, yes.

> > I suggest that the menu is
> > the optional non-default behaviour.
>
> I agree this should be configurable, like in e.g. Firefox a new tab page
> is configurable.

Fair enough.

> > Here are some suggestions that are less fundamental, listed in no particular
> > order.
> >
> > 5. When I hover inactive tabs with the mouse, only the name of the tab is
> > highlighted.  Can we get the entire tab highlighted instead, including the
> > section where the close button is?
>
> This is fixed now in the branch.

Looks great.  It might look even better if there is an "extra"
highlight on just the button when hovering only that.  That would
provide the feedback that there is something clickable there.  The
same goes for the active tab, where I see no highlight when I hover
the close button.

> > 6. When I hover the close button on the currently active tab, I get a grey line
> > between the tab name and the button.  Could we get rid of that line?
>
> This is fixed now.

Looks great.

> > 7. The active tab seems to be the same color in both the currently active window
> > and in other windows.  Could we perhaps color the active tab differently
> > depending on if it's in the active window or not?
>
> This is an interesting suggestion, I'd never thought about such distinction,
> but it could be useful for additional indication of the currently selected
> window, like different faces of the mode-line indicate the selected window.

Indeed.

> > 8. In Firefox, the close tab button is not visible unless that tab is selected.
> > Perhaps that behaviour makes more sense, especially if we also implement the
> > "fixed size tabs that shrinks to fit" behaviour discussed elsewhere (because
> > smaller tabs make it too easy to accidentally click the close button).
>
> This Firefox behaviour is very inconvenient - to be able to close
> several tabs in a row I have first to switch to each of them that starts
> loading the page, so browser hangs for a while - very frustrating experience.
> Chromium close buttons on every tab are much better.  However, you can set
> the close button variable to nil to disable close buttons.

In my experience, there is rarely any significant loading time when
switching buffer in Emacs.

In my opinion, removing the close buttons makes it easier to quickly
select tabs without worrying about accidentally closing them.  Setting
tab-bar-close-button to nil gets rid of them altogether; what I want
is to only have a close button on the currently active tab.  Perhaps
we could add a separate defcustom to make my preferred behaviour
optional?

That makes me wonder how we can best track these feature suggestions
for this branch?  Wait until it lands on master and then file wishlist
bugs?

> > 9. It would probably look better if there was a couple of pixels of padding
> > between the tab name and the edge of the tab.
>
> Is this possible in Emacs?  Could you please show an example of a text property
> that would put e.g. 5 pixels between characters in string.

Sorry, I don't know how to do that.

Is it possible to use variable-pitch-mode for the tab-bar only?  In
that case C-x 8 RET THIN SPACE RET would probably do the trick.

In any case, having a variable width font for the tabs in my opinion
would be a fantastic feature to have, and will probably go a long way
to make it look more polished and professional.

> > 10. Could we make the "+" sign (to add more tabs) more visually
> > distinct from the tabs?  For example, it could have no borders.
>
> This is fixed now in the branch.

Sorry to nit-pick so much, but I suggest to make it a bit bigger, to
make the background the same color as the surrounding tab bar, and to
make the lines thicker.  (I also think that the close buttons could be
a bit bigger and thicker, too.)

> > 14. Could we add a vertical line below the tabs to separate it from the buffer?
[...]
>
> This is fixed now in the branch, please try it.

Yes, this looks good.

I also see some other areas where you could perhaps look over the behaviour:

A)
0. emacs -Q
1. C-x b *Messages* RET
2. M-x global-tab-bar-mode

I now see two tabs -- but I would expect to see only one.

B)
0. emacs -Q
1. M-x global-tab-bar-mode
2. Create new tab using "+" (add tab button).
3. Run C-x <right>

The two tabs now switches places.  I would expect them to stay where
they are unless I ask to move them.

C)
0. emacs -Q
1. M-x global-tab-bar-mode
2. Click "+" (add tab button)

In the menu, I now see the "*scratch*" buffer as an option.  If I
click it, nothing happens.
Expected: I only see the other available but not open buffer.

D)
0. emacs -Q
1. M-x global-tab-bar-mode
2. Click "+" (add tab button)
3. Click "*Messages*"
4. Click "+" (add tab button)

(BTW, here I would expect to see an error message that there are no
more buffers to select or something...)

5. Click "*scratch"

Now I'm in the "*scratch*" buffer -- and the buffers switch places.  I
suppose this is a result of the behaviour I've described above.

E)
Finally, and I understand this could potentially be a lot of work, but
it would be fantastic if one could drag and drop tabs to have them
switch places (bonus points if one can drag them to other windows or
frames!).

Great to see that this feature is progressing so well!

Best regards,
Stefan Kangas

Re: Tabs

[Juri Linkov]

>> > 1. When I run C-x <left> or C-x <right>, it automatically creates a new tab with
>> > the next buffer.  I'd rather it switched between the open tabs, and have a
>> > separate command to create a new tab.  I believe this would be more in line with
>> > how tabs work in other software, and therefore more intuitive.
>>
>> If an inactive tab is displayed to the left from the currently active tab,
>> do you mean that 'C-x <left>' doesn't switch to it but instead creates a new tab?
>
> When I do:
>
> 0. emacs -Q
> 1. M-x global-tab-line-mode
> 1. C-x <left>
>
> I see a new tab open up with the *Messages* buffer.  I would expect it
> to not open up a new tab when I just ask to see the next or previous
> tab.

This is intentional.  This feature allows you to add more tabs from the
frame's buffer-list and buried-buffer-list.  If you don't want to use
this feature, just don't type C-x <left> on the first tab.  Also you can
close unwanted tabs by clicking on the close buttons.

>> > 2. None of these interactive commands work when run with M-x:
>> >
>> > command-execute: tab-line-add-tab must be bound to an event with parameters
>> > command-execute: tab-line-close-tab must be bound to an event with parameters
>> > command-execute: tab-line-select-tab must be bound to an event with parameters
>> > command-execute: tab-line-switch-to-next-tab must be bound to an event
>> > with parameters
>> > command-execute: tab-line-switch-to-prev-tab must be bound to an event
>> > with parameters
>>
>> Mouse commands don't work with M-x.  For example, try M-x Buffer-menu-mouse-select
>
> True.
>
>> but we could declare the EVENT arg optional for these commands,
>> and perform non-mouse logic when it's nil.
>
> This is what I would prefer.  I think users will naturally try to use
> these commands and be surprised when they don't work.

But the EVENT arg in these commands already is optional.
And executing them with M-x fails because interactive spec is
(interactive "e").  Do you know what interactive spec to use
to not raise the error "must be bound to an event with parameters"
when executing with M-x?

>> > 3. It would then be good to have key bindings for the above commands.
>>
>> tab-line-switch-to-prev-tab is already the same as 'C-x <left>'
>> tab-line-switch-to-next-tab is already the same as 'C-x <right>'
>> tab-line-add-tab is the same as 'C-x b' or any other buffer switching command
>> tab-line-close-tab is the same as bury-buffer or quit-window (`q')
>
> Interesting.  Could the doc strings for the tab-line-* commands refer
> to the corresponding functions?  I think that would help lessen the
> confusion.

Yes, this should be mentioned in the doc strings.

>> only tab-line-select-tab could have a keybinding for referring tab by its
>> absolute position.
>
> That would be good, yes.
>
>> > I suggest that the menu is
>> > the optional non-default behaviour.
>>
>> I agree this should be configurable, like in e.g. Firefox a new tab page
>> is configurable.
>
> Fair enough.

Implemented now in the branch.

>> > Here are some suggestions that are less fundamental, listed in no particular
>> > order.
>> >
>> > 5. When I hover inactive tabs with the mouse, only the name of the tab is
>> > highlighted.  Can we get the entire tab highlighted instead, including the
>> > section where the close button is?
>>
>> This is fixed now in the branch.
>
> Looks great.  It might look even better if there is an "extra"
> highlight on just the button when hovering only that.  That would
> provide the feedback that there is something clickable there.  The
> same goes for the active tab, where I see no highlight when I hover
> the close button.

Do you know is it possible to change image on mouse hover in Emacs?

>> > 6. When I hover the close button on the currently active tab, I get a grey line
>> > between the tab name and the button.  Could we get rid of that line?
>>
>> This is fixed now.
>
> Looks great.
>
>> > 7. The active tab seems to be the same color in both the currently active window
>> > and in other windows.  Could we perhaps color the active tab differently
>> > depending on if it's in the active window or not?
>>
>> This is an interesting suggestion, I'd never thought about such distinction,
>> but it could be useful for additional indication of the currently selected
>> window, like different faces of the mode-line indicate the selected window.
>
> Indeed.
>
>> > 8. In Firefox, the close tab button is not visible unless that tab is selected.
>> > Perhaps that behaviour makes more sense, especially if we also implement the
>> > "fixed size tabs that shrinks to fit" behaviour discussed elsewhere (because
>> > smaller tabs make it too easy to accidentally click the close button).
>>
>> This Firefox behaviour is very inconvenient - to be able to close
>> several tabs in a row I have first to switch to each of them that starts
>> loading the page, so browser hangs for a while - very frustrating experience.
>> Chromium close buttons on every tab are much better.  However, you can set
>> the close button variable to nil to disable close buttons.
>
> In my experience, there is rarely any significant loading time when
> switching buffer in Emacs.
>
> In my opinion, removing the close buttons makes it easier to quickly
> select tabs without worrying about accidentally closing them.  Setting
> tab-bar-close-button to nil gets rid of them altogether; what I want
> is to only have a close button on the currently active tab.  Perhaps
> we could add a separate defcustom to make my preferred behaviour
> optional?

This is implemented now by new defcustom tab-line-close-button-show
that has these options:

- On all tabs
- On selected tab
- On non-selected tabs
- None

> That makes me wonder how we can best track these feature suggestions
> for this branch?  Wait until it lands on master and then file wishlist
> bugs?

Yes, it's better to merge to master before adding more features because
it would be more difficult to merge with additional non-major features.

>> > 9. It would probably look better if there was a couple of pixels of padding
>> > between the tab name and the edge of the tab.
>>
>> Is this possible in Emacs?  Could you please show an example of a text property
>> that would put e.g. 5 pixels between characters in string.
>
> Sorry, I don't know how to do that.
>
> Is it possible to use variable-pitch-mode for the tab-bar only?  In
> that case C-x 8 RET THIN SPACE RET would probably do the trick.
>
> In any case, having a variable width font for the tabs in my opinion
> would be a fantastic feature to have, and will probably go a long way
> to make it look more polished and professional.

Please try to customize the `tab-line' face with a variable width font.
Do you like the result?

>> > 10. Could we make the "+" sign (to add more tabs) more visually
>> > distinct from the tabs?  For example, it could have no borders.
>>
>> This is fixed now in the branch.
>
> Sorry to nit-pick so much, but I suggest to make it a bit bigger, to
> make the background the same color as the surrounding tab bar, and to
> make the lines thicker.  (I also think that the close buttons could be
> a bit bigger and thicker, too.)

What font size do you use?

>> > 14. Could we add a vertical line below the tabs to separate it from the buffer?
> [...]
>>
>> This is fixed now in the branch, please try it.
>
> Yes, this looks good.
>
> I also see some other areas where you could perhaps look over the behaviour:
>
> A)
> 0. emacs -Q
> 1. C-x b *Messages* RET
> 2. M-x global-tab-bar-mode
>
> I now see two tabs -- but I would expect to see only one.

The *scratch* buffer was displayed in the same window,
so it belongs to window's buffer list.

> B)
> 0. emacs -Q
> 1. M-x global-tab-bar-mode
> 2. Create new tab using "+" (add tab button).
> 3. Run C-x <right>
>
> The two tabs now switches places.  I would expect them to stay where
> they are unless I ask to move them.

C-x <right> tries to bring buffers from the global buffer-list
and there are no more buffers except *scratch*.
If you want to switch to the left tab, just press C-x <left>.

> C)
> 0. emacs -Q
> 1. M-x global-tab-bar-mode
> 2. Click "+" (add tab button)
>
> In the menu, I now see the "*scratch*" buffer as an option.  If I
> click it, nothing happens.
> Expected: I only see the other available but not open buffer.

The same question applies to `mouse-buffer-menu'.
If you click <C-down-mouse-1> inside the buffer,
do you expect the current buffer in the list?

> D)
> 0. emacs -Q
> 1. M-x global-tab-bar-mode
> 2. Click "+" (add tab button)
> 3. Click "*Messages*"
> 4. Click "+" (add tab button)
>
> (BTW, here I would expect to see an error message that there are no
> more buffers to select or something...)

This is the same question as above.

> 5. Click "*scratch"
>
> Now I'm in the "*scratch*" buffer -- and the buffers switch places.  I
> suppose this is a result of the behaviour I've described above.
>
> E)
> Finally, and I understand this could potentially be a lot of work, but
> it would be fantastic if one could drag and drop tabs to have them
> switch places (bonus points if one can drag them to other windows or
> frames!).

I already started to implement this additional feature but
better to commit it after merge because it's easier to merge
with less code.

> Great to see that this feature is progressing so well!

Thanks!

Re: Tabs

[Juri Linkov]

>>> > 2. None of these interactive commands work when run with M-x:
>>> >
>>> > command-execute: tab-line-add-tab must be bound to an event with parameters
>>> > command-execute: tab-line-close-tab must be bound to an event with parameters
>>> > command-execute: tab-line-select-tab must be bound to an event with parameters
>>> > command-execute: tab-line-switch-to-next-tab must be bound to an event
>>> > with parameters
>>> > command-execute: tab-line-switch-to-prev-tab must be bound to an event
>>> > with parameters
>>>
>>> Mouse commands don't work with M-x.  For example, try M-x Buffer-menu-mouse-select
>>
>> True.
>>
>>> but we could declare the EVENT arg optional for these commands,
>>> and perform non-mouse logic when it's nil.
>>
>> This is what I would prefer.  I think users will naturally try to use
>> these commands and be surprised when they don't work.
>
> But the EVENT arg in these commands already is optional.
> And executing them with M-x fails because interactive spec is
> (interactive "e").  Do you know what interactive spec to use
> to not raise the error "must be bound to an event with parameters"
> when executing with M-x?

I realized this is possible to do by replacing ‘(interactive "e")’
with ‘(interactive (list last-nonmenu-event))’, implemented.

Re: Tabs

[Juri Linkov]

>> > 7. The active tab seems to be the same color in both the currently active window
>> > and in other windows.  Could we perhaps color the active tab differently
>> > depending on if it's in the active window or not?
>>
>> This is an interesting suggestion, I'd never thought about such distinction,
>> but it could be useful for additional indication of the currently selected
>> window, like different faces of the mode-line indicate the selected window.
>
> Indeed.

Now thanks to Martin suggested to use old-selected-window
in https://lists.gnu.org/archive/html/emacs-devel/2019-10/msg01066.html
(I didn't know about old-selected-window, or maybe forgot
if it was implemented for other purpose, maybe for some hook)

Anyway, now it's possible to use it to indicate the selected window
in the tab-line using the 'tab-line-tab-selected' face.

Re: Tabs

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> There is a long story of several attempts to implement tabs in Emacs.
> Finally now a complete implementation is available for these
> etc/TODO tasks:

Sorry, I didn't try your implementation, but I have a question:

My usage is like this: I want tabs in w3m, for w3m buffers, tabs for
eww buffers in a frame "dedicated" to browsing with eww (like a firefox
window), tabs in *info* showing *info* buffers, etc.  I don't want
tabs always and everywhere, I want tabs only for certain modes and then
they should only show related buffers.  And I don't (necessarily) want
to save any desktop file or frame configurations or so.  I just want to
have missing tab support for e.g. eww or info, preferably without losing
the header line.

Does your implementation cover such a user behavior?

Thanks,

Michael.

Re: Tabs

[Juri Linkov]

> My usage is like this: I want tabs in w3m, for w3m buffers, tabs for
> eww buffers in a frame "dedicated" to browsing with eww (like a firefox
> window), tabs in *info* showing *info* buffers, etc.  I don't want
> tabs always and everywhere, I want tabs only for certain modes and then
> they should only show related buffers.  And I don't (necessarily) want
> to save any desktop file or frame configurations or so.  I just want to
> have missing tab support for e.g. eww or info, preferably without losing
> the header line.
>
> Does your implementation cover such a user behavior?

Yes, it's already customizable enough to cover many different needs.

At the core it provides a new place at the top of the frame for
the frame-local tab-bar, and also places for window-local tab-lines
at the top of each window.  So authors of many existing packages that
currently had no choice other than taking space from the header-line,
now can adapt packages to use new locations reserved specially for tabs.

If you are already using one of these packages you might want to
continue using them with the new tabs locations that doesn't conflict
with the header-line.  These packages provide dozens of user options,
and it makes no sense to copy all them to the core.  Instead of trying
to cover an infinite set of possible customization preferences, the core
should be general to allow adapting to the customization needs easily.

The current implementation is already flexible enough, so for example,
what you asked for *info* buffers, is possible to do with the current
implementation with just a few lines:

  (advice-add 'tab-line-tabs :around
              (lambda (orig-fun &optional window)
                (if (derived-mode-p 'Info-mode)
                    (mapcan (lambda (b)
                              (with-current-buffer b
                                (when (derived-mode-p 'Info-mode)
                                  (list b))))
                            (buffer-list))
                  (funcall orig-fun window))))

Later this could be generalized to provide e.g. an option for the list
of modes where to enable this behavior.

Also I already implemented more features such as tab close undo,
tab history back, etc.  But it would be better to add them later
after merging the branch to master, so merging will be easier
with minimal set of changes.  Thus perhaps now I should start
preparations for merging the feature/tabs branch to master
that includes mostly writing documentation for the Info manual.

Re: Tabs

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> The current implementation is already flexible enough, so for example,
> what you asked for *info* buffers, is possible to do with the current
> implementation with just a few lines:
>
>   (advice-add 'tab-line-tabs :around
>               (lambda (orig-fun &optional window)
>                 (if (derived-mode-p 'Info-mode)
>                     (mapcan (lambda (b)
>                               (with-current-buffer b
>                                 (when (derived-mode-p 'Info-mode)
>                                   (list b))))
>                             (buffer-list))
>                   (funcall orig-fun window))))

This seems exactly what I imagined - sounds very promising.  Looking
forward for it to appear in master.

Thanks,

Michael.

Re: Tabs

[Juri Linkov]

>> The current implementation is already flexible enough, so for example,
>> what you asked for *info* buffers, is possible to do with the current
>> implementation with just a few lines:
>>
>>   (advice-add 'tab-line-tabs :around
>>               (lambda (orig-fun &optional window)
>>                 (if (derived-mode-p 'Info-mode)
>>                     (mapcan (lambda (b)
>>                               (with-current-buffer b
>>                                 (when (derived-mode-p 'Info-mode)
>>                                   (list b))))
>>                             (buffer-list))
>>                   (funcall orig-fun window))))
>
> This seems exactly what I imagined - sounds very promising.

Now configuration is even simpler:

  (add-hook 'Info-mode-hook
            (lambda ()
              (setq-local tab-line-tabs-function
                          (lambda ()
                            (mapcan
                             (lambda (b)
                               (when (with-current-buffer b (derived-mode-p 'Info-mode))
                                 (list b)))
                             (buffer-list))))))

And you can even use the tab-bar as well for the same purpose
(if you don't need to switch window configurations):

  (add-hook 'Info-mode-hook
            (lambda ()
              (setq-local tab-bar-tabs-function
                          (lambda ()
                            (mapcan
                             (lambda (b)
                               (when (with-current-buffer b (derived-mode-p 'Info-mode))
                                 (list `(,(if (eq b (current-buffer)) 'current-tab 'tab)
                                         (name . ,(buffer-name b))
                                         (binding . (lambda () (interactive) (switch-to-buffer ,b)))
                                         (close-binding . (lambda () (interactive) (kill-buffer ,b) (force-mode-line-update)))))))
                             (buffer-list))))))

> Looking forward for it to appear in master.

After thorough testing and improving customization the work on the
branch is finished, and it is mostly ready for merge, but writing
documentation is the most time-consuming process.  I hope to finish
writing documentation by the weekend.

Re: Tabs

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> Now configuration is even simpler:
>
>   (add-hook 'Info-mode-hook
>             (lambda ()
>               (setq-local tab-line-tabs-function
>                           (lambda ()
>                             (mapcan
>                              (lambda (b)
>                                (when (with-current-buffer b (derived-mode-p 'Info-mode))
>                                  (list b)))
>                              (buffer-list))))))

Works for me, thanks.

What I didn't get working is to show tabs only for Info buffers and hide
it for all others.  Whatever I tried tabs are either displayed in every
window or in none.

This is what I have so far:

#+begin_src emacs-lisp
(customize-set-variable 'tab-bar-show 1)
(setq-default tab-bar-tabs-function #'ignore)
(add-hook 'Info-mode-hook
          (defun my-Info-mode-hook-configure-tab-bar ()
            (setq-local
             tab-bar-tabs-function
             (lambda ()
               (mapcan
                (lambda (b)
                  (when (with-current-buffer b (derived-mode-p 'Info-mode))
                    (list `(,(if (eq b (current-buffer)) 'current-tab 'tab)
                            (name . ,(buffer-name b))
                            (binding . (lambda () (interactive) (switch-to-buffer ,b)))
                            (close-binding . (lambda () (interactive) (kill-buffer ,b) (force-mode-line-update)))))))
                (buffer-list))))))
#+end_src

Can I get it work?

TIA,

Michael.

Re: Tabs

[Juri Linkov]

> What I didn't get working is to show tabs only for Info buffers and hide
> it for all others.  Whatever I tried tabs are either displayed in every
> window or in none.
>
> This is what I have so far:
>
> #+begin_src emacs-lisp
> (customize-set-variable 'tab-bar-show 1)
> (setq-default tab-bar-tabs-function #'ignore)
> (add-hook 'Info-mode-hook
>           (defun my-Info-mode-hook-configure-tab-bar ()
>             (setq-local
>              tab-bar-tabs-function
>              (lambda ()
>                (mapcan
>                 (lambda (b)
>                   (when (with-current-buffer b (derived-mode-p 'Info-mode))
>                     (list `(,(if (eq b (current-buffer)) 'current-tab 'tab)
>                             (name . ,(buffer-name b))
>                             (binding . (lambda () (interactive) (switch-to-buffer ,b)))
>                             (close-binding . (lambda () (interactive) (kill-buffer ,b) (force-mode-line-update)))))))
>                 (buffer-list))))))
> #+end_src
>
> Can I get it work?

I tried your code, and it works fine: tabs are shown only when
the current buffer is in Info mode, and hidden when the selected window's
buffer is in other modes.

Re: Tabs

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> > #+begin_src emacs-lisp
> > (customize-set-variable 'tab-bar-show 1)
> > (setq-default tab-bar-tabs-function #'ignore)
> > (add-hook 'Info-mode-hook
> >           (defun my-Info-mode-hook-configure-tab-bar ()
> >             (setq-local
> >              tab-bar-tabs-function
> >              (lambda ()
> >                (mapcan
> >                 (lambda (b)
> >                   (when (with-current-buffer b (derived-mode-p 'Info-mode))
> >                     (list `(,(if (eq b (current-buffer)) 'current-tab 'tab)
> >                             (name . ,(buffer-name b))
> >                             (binding . (lambda () (interactive) (switch-to-buffer ,b)))
> >                             (close-binding . (lambda () (interactive) (kill-buffer ,b) (force-mode-line-update)))))))
> >                 (buffer-list))))))
> > #+end_src
> >
> > Can I get it work?
>
> I tried your code, and it works fine: tabs are shown only when
> the current buffer is in Info mode, and hidden when the selected window's
> buffer is in other modes.

Hmm, no not for me, I never get tabs with this code.  I also tried with
emacs -Q.  This is with current master - or do I still have to use a
different branch?

I see that (funcall tab-bar-tabs-function) in info buffers returns a
list with multiple elements, so it /should/ work.

Regards,

Michael.

Re: Tabs

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> I see that (funcall tab-bar-tabs-function) in info buffers returns a
> list with multiple elements, so it /should/ work.

One more thing: with the posted setup, although I don't see any tab bar,
whenever I switch to a different workspace and back, and also under some
under conditions I don't fully understand, Emacs gets stuck, it
apparently infloops in redisplay.  I need to send three SIGUSR2 to get
control back.  This with with my config loaded FWIW.

Michael.

Re: Tabs

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> One more thing: with the posted setup, although I don't see any tab bar,
> whenever I switch to a different workspace and back, and also under some
> under conditions I don't fully understand, Emacs gets stuck, it
> apparently infloops in redisplay.  I need to send three SIGUSR2 to get
> control back.  This with with my config loaded FWIW.

It's probably not your fault: this still happens with tab-lines turned
off.

Michael.

Re: Tabs

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Sun, 06 Oct 2019 14:09:30 +0200
> Cc: emacs-devel@gnu.org
> One more thing: with the posted setup, although I don't see any tab bar,
> whenever I switch to a different workspace and back, and also under some
> under conditions I don't fully understand, Emacs gets stuck, it
> apparently infloops in redisplay.

When this happens, please attach a debugger and use the technique
described in etc/DEBUG to find out where it loops.

TIA

Re: Tabs

[Juri Linkov]

>> One more thing: with the posted setup, although I don't see any tab bar,
>> whenever I switch to a different workspace and back, and also under some
>> under conditions I don't fully understand, Emacs gets stuck, it
>> apparently infloops in redisplay.
>
> When this happens, please attach a debugger and use the technique
> described in etc/DEBUG to find out where it loops.

I can reproduce the redisplay issue, I never seen this before,
maybe some recent change broke redisplaying.

I tried to debug and in redisplay_internal, the value of
garbaged_frame_retries has a very large number - about thousands
order of magnitude.  It never resets the 'garbaged' flag set in the
selected frame.  And I have no idea how to force the 'garbaged' flag
to be reset.  It infloops in these lines:

		  /* On some platforms (at least MS-Windows), the
		     scroll_run_hook called from scrolling_window
		     called from update_frame could set the frame's
		     garbaged flag, in which case we need to
		     redisplay the frame.  */
                  if (FRAME_GARBAGED_P (f))
		    goto retry_frame;

Re: Tabs

[Juri Linkov]

>>> One more thing: with the posted setup, although I don't see any tab bar,
>>> whenever I switch to a different workspace and back, and also under some
>>> under conditions I don't fully understand, Emacs gets stuck, it
>>> apparently infloops in redisplay.
>>
>> When this happens, please attach a debugger and use the technique
>> described in etc/DEBUG to find out where it loops.
>
> I can reproduce the redisplay issue, I never seen this before,
> maybe some recent change broke redisplaying.
>
> I tried to debug and in redisplay_internal, the value of
> garbaged_frame_retries has a very large number - about thousands
> order of magnitude.  It never resets the 'garbaged' flag set in the
> selected frame.  And I have no idea how to force the 'garbaged' flag
> to be reset.  It infloops in these lines:
>
> 		  /* On some platforms (at least MS-Windows), the
> 		     scroll_run_hook called from scrolling_window
> 		     called from update_frame could set the frame's
> 		     garbaged flag, in which case we need to
> 		     redisplay the frame.  */
>                   if (FRAME_GARBAGED_P (f))
> 		    goto retry_frame;

This problem can be reproduced easily by just resizing the frame
several times.

Re: Tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Michael Heerdegen <michael_heerdegen@web.de>,  emacs-devel@gnu.org
> Date: Sun, 06 Oct 2019 21:05:12 +0300
> 
> > 		  /* On some platforms (at least MS-Windows), the
> > 		     scroll_run_hook called from scrolling_window
> > 		     called from update_frame could set the frame's
> > 		     garbaged flag, in which case we need to
> > 		     redisplay the frame.  */
> >                   if (FRAME_GARBAGED_P (f))
> > 		    goto retry_frame;
> 
> This problem can be reproduced easily by just resizing the frame
> several times.

Doesn't happen here, no matter how many times I try.

Re: Tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Michael Heerdegen <michael_heerdegen@web.de>,  emacs-devel@gnu.org
> Date: Sun, 06 Oct 2019 21:05:12 +0300
> 
> > 		  /* On some platforms (at least MS-Windows), the
> > 		     scroll_run_hook called from scrolling_window
> > 		     called from update_frame could set the frame's
> > 		     garbaged flag, in which case we need to
> > 		     redisplay the frame.  */
> >                   if (FRAME_GARBAGED_P (f))
> > 		    goto retry_frame;
> 
> This problem can be reproduced easily by just resizing the frame
> several times.

In "emacs -Q"?  Just start Emacs and resize the frame by dragging its
edge with the mouse?  Or something else?

Re: Tabs

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> In "emacs -Q"?  Just start Emacs and resize the frame by dragging its
> edge with the mouse?

Yes, exactly that.  Happens for the seconds drag here.

I count on Juri for further debugging since I'm not good at it.


Michael.

Re: Tabs

[Juri Linkov]

>> > 		  /* On some platforms (at least MS-Windows), the
>> > 		     scroll_run_hook called from scrolling_window
>> > 		     called from update_frame could set the frame's
>> > 		     garbaged flag, in which case we need to
>> > 		     redisplay the frame.  */
>> >                   if (FRAME_GARBAGED_P (f))
>> > 		    goto retry_frame;
>>
>> This problem can be reproduced easily by just resizing the frame
>> several times.
>
> In "emacs -Q"?  Just start Emacs and resize the frame by dragging its
> edge with the mouse?  Or something else?

In "emacs -Q" build with GTK+ Version 3.22.30 it infloops after resizing
by quickly dragging its edge with the mouse.

Maybe this requires a slow computer that makes frame updating even slower
by configuring without optimization:

--enable-checking='yes,glyphs' --enable-check-lisp-object-type CFLAGS='-O0 -g3 -gdwarf-4'

Re: Tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: michael_heerdegen@web.de,  emacs-devel@gnu.org
> Date: Sun, 06 Oct 2019 22:11:43 +0300
> 
> > In "emacs -Q"?  Just start Emacs and resize the frame by dragging its
> > edge with the mouse?  Or something else?
> 
> In "emacs -Q" build with GTK+ Version 3.22.30 it infloops after resizing
> by quickly dragging its edge with the mouse.

I guess it's somehow specific to the GTK build (or maybe more
generally to X).

> Maybe this requires a slow computer that makes frame updating even slower
> by configuring without optimization:
> 
> --enable-checking='yes,glyphs' --enable-check-lisp-object-type CFLAGS='-O0 -g3 -gdwarf-4'

No, because that's how I built mine.

OK, can you set a watchpoint on the frame's garbaged flag, and show me
both C and Lisp backtraces each time the flag is set or reset while we
loop for two iterations there?

Thanks.

Re: Tabs

[Juri Linkov]

>> > In "emacs -Q"?  Just start Emacs and resize the frame by dragging its
>> > edge with the mouse?  Or something else?
>> 
>> In "emacs -Q" build with GTK+ Version 3.22.30 it infloops after resizing
>> by quickly dragging its edge with the mouse.
>
> I guess it's somehow specific to the GTK build (or maybe more
> generally to X).
>
>> Maybe this requires a slow computer that makes frame updating even slower
>> by configuring without optimization:
>> 
>> --enable-checking='yes,glyphs' --enable-check-lisp-object-type CFLAGS='-O0 -g3 -gdwarf-4'
>
> No, because that's how I built mine.
>
> OK, can you set a watchpoint on the frame's garbaged flag, and show me
> both C and Lisp backtraces each time the flag is set or reset while we
> loop for two iterations there?

It's very strange but a watchpoint is hit only on setting flag to false:

(gdb) bt
#0  0x000055555560a8eb in redisplay_internal () at xdisp.c:15707
#1  0x000055555560b243 in redisplay_preserve_echo_area (from_where=11) at xdisp.c:15946
#2  0x00005555559e7922 in wait_reading_process_output (time_limit=30, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0)
    at process.c:5429
#3  0x00005555555aa009 in sit_for (timeout=make_fixnum(30), reading=true, display_option=1) at dispnew.c:6021
#4  0x00005555557e119f in read_char (commandflag=1, map=XIL(0x555556e0e2b3), prev_event=XIL(0), used_mouse_menu=0x7fffffffd5e5, end_time=0x0) at keyboard.c:2718
#5  0x00005555557f3bcb in read_key_sequence (keybuf=0x7fffffffd7d0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9527
#6  0x00005555557dca01 in command_loop_1 () at keyboard.c:1345
#7  0x000055555594bb94 in internal_condition_case (bfun=0x5555557dc583 <command_loop_1>, handlers=XIL(0x90), hfun=0x5555557dbb4f <cmd_error>) at eval.c:1355
#8  0x00005555557dc16a in command_loop_2 (ignore=XIL(0)) at keyboard.c:1091
#9  0x000055555594afee in internal_catch (tag=XIL(0xcf00), func=0x5555557dc13d <command_loop_2>, arg=XIL(0)) at eval.c:1116
#10 0x00005555557dc108 in command_loop () at keyboard.c:1070
#11 0x00005555557db636 in recursive_edit_1 () at keyboard.c:714
#12 0x00005555557db82e in Frecursive_edit () at keyboard.c:786
#13 0x00005555557d1725 in main (argc=3, argv=0x7fffffffdc28) at emacs.c:2055

Lisp Backtrace:
"redisplay_internal (C function)" (0x0)
(gdb) l
15702		    {
15703		      struct frame *f = XFRAME (frame);
15704	              if (f->updated_p)
15705	                {
15706			  f->redisplay = false;
15707			  f->garbaged = false;
15708	                  mark_window_display_accurate (f->root_window, true);
15709	                  if (FRAME_TERMINAL (f)->frame_up_to_date_hook)
15710	                    FRAME_TERMINAL (f)->frame_up_to_date_hook (f);
15711	                }

but never on setting flag to true, yet f->garbaged becomes true in redisplay_internal
somehow.

Re: Tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: michael_heerdegen@web.de,  emacs-devel@gnu.org
> Date: Sun, 06 Oct 2019 22:58:28 +0300
> 
> > OK, can you set a watchpoint on the frame's garbaged flag, and show me
> > both C and Lisp backtraces each time the flag is set or reset while we
> > loop for two iterations there?
> 
> It's very strange but a watchpoint is hit only on setting flag to false:

Hmm... I guess that's the problem, then.

Please try the latest master, I hope this is now fixed.

Re: Tabs

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Please try the latest master, I hope this is now fixed.

Seems fixed for me indeed.  Thank you!

Michael.

Re: Tabs

[Ergus]

Hi I am trying to open a file in a new tab: C-x 6 f and I am getting a
segfault:

---------------------------------------

Core was generated by `emacs -Q -nw'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007fef54a957b5 in raise () from /usr/lib/libpthread.so.0
[Current thread is 1 (Thread 0x7fef5016ce80 (LWP 149751))]
(gdb) where
#0  0x00007fef54a957b5 in raise () at /usr/lib/libpthread.so.0
#1  0x0000561288381ff1 in terminate_due_to_signal (sig=sig@entry=11, backtrace_limit=backtrace_limit@entry=40) at ../../src/emacs.c:401
#2  0x0000561288382434 in handle_fatal_signal (sig=sig@entry=11) at ../../src/sysdep.c:1790
#3  0x000056128847983d in deliver_thread_signal (sig=sig@entry=11, handler=0x561288382429 <handle_fatal_signal>) at ../../src/sysdep.c:1764
#4  0x00005612884798b9 in deliver_fatal_thread_signal (sig=11) at ../../src/sysdep.c:1887
#5  0x00005612884798b9 in handle_sigsegv (sig=11, siginfo=<optimized out>, arg=<optimized out>) at ../../src/sysdep.c:1887
#6  0x00007fef54a95930 in <signal handler called> () at /usr/lib/libpthread.so.0
#7  0x00007fef5486a743 in __memmove_avx_unaligned_erms () at /usr/lib/libc.so.6
#8  0x000056128838f30a in memcpy (__len=8160, __src=<optimized out>, __dest=<optimized out>) at /usr/include/bits/string_fortified.h:34
#9  0x000056128838f30a in save_current_matrix (f=0x561288fcf140) at ../../src/dispnew.c:1919
#10 0x000056128838f30a in adjust_frame_glyphs_for_frame_redisplay (f=0x561288fcf140) at ../../src/dispnew.c:2078
#11 0x000056128838f30a in adjust_frame_glyphs (f=f@entry=0x561288fcf140) at ../../src/dispnew.c:1821
#12 0x0000561288394be2 in adjust_frame_size
    (f=0x561288fcf140, new_width=<optimized out>, new_height=<optimized out>, inhibit=inhibit@entry=5, pretend=pretend@entry=false, parameter=parameter@entry=0x3cc0)
    at ../../src/frame.c:821
#13 0x0000561288389a63 in change_frame_size_1
    (f=<optimized out>, new_width=<optimized out>, new_height=<optimized out>, pretend=pretend@entry=false, delay=delay@entry=false, safe=safe@entry=true, pixelwise=<optimized out>) at ../../src/lisp.h:1032
#14 0x0000561288391c28 in change_frame_size
    (pixelwise=<optimized out>, safe=true, delay=false, pretend=false, new_height=<optimized out>, new_width=<optimized out>, f=<optimized out>)
    at ../../src/dispnew.c:5795
#15 0x0000561288391c28 in do_pending_window_change (safe=safe@entry=true) at ../../src/dispnew.c:5721
#16 0x00005612883c694f in redisplay_internal () at ../../src/xdisp.c:15234
#17 0x000056128846c21f in read_char (commandflag=1, map=0x56128905d643, prev_event=0x0, used_mouse_menu=0x7ffc179c3b3b, end_time=0x0) at ../../src/keyboard.c:2473
#18 0x000056128846ea6a in read_key_sequence
    (keybuf=<optimized out>, prompt=0x0, dont_downcase_last=<optimized out>, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=<optimized out>)
    at ../../src/keyboard.c:9527
#19 0x000056128847010c in command_loop_1 () at ../../src/lisp.h:1032
#20 0x00005612884d7277 in internal_condition_case
    (bfun=bfun@entry=0x56128846ff10 <command_loop_1>, handlers=handlers@entry=0x90, hfun=hfun@entry=0x5612884670a0 <cmd_error>) at ../../src/eval.c:1355
#21 0x0000561288461e84 in command_loop_2 (ignore=ignore@entry=0x0) at ../../src/lisp.h:1032
#22 0x00005612884d71d1 in internal_catch (tag=tag@entry=0xd500, func=func@entry=0x561288461e60 <command_loop_2>, arg=arg@entry=0x0) at ../../src/eval.c:1116
#23 0x0000561288461e2b in command_loop () at ../../src/lisp.h:1032
#24 0x0000561288466cb6 in recursive_edit_1 () at ../../src/keyboard.c:714
#25 0x0000561288466fe2 in Frecursive_edit () at ../../src/keyboard.c:786
#26 0x0000561288388e37 in main (argc=3, argv=<optimized out>) at ../../src/emacs.c:2055

-------------------------------------------------

This used to work fine before... I just pull and recompiled (since
saturday)... Anyone else getting similar error?

The previous bt was when -nw, but in gui I am getting nothing.. C-x 6 f
opens the file but not creates a tab... What happened?? This was fine
before.

Best,
Ergus

Re: Tabs

[Eli Zaretskii]

> Date: Mon, 7 Oct 2019 19:12:30 +0200
> From: Ergus <spacibba@aol.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org,
> 	Juri Linkov <juri@linkov.net>
> 
> Hi I am trying to open a file in a new tab: C-x 6 f and I am getting a
> segfault:

Should be fixed now.

> The previous bt was when -nw, but in gui I am getting nothing.. C-x 6 f
> opens the file but not creates a tab... What happened?? This was fine
> before.

I cannot reproduce this part: C-x 6 f works for me in GUI sessions as
expected.

Re: Tabs

[Ergus]

On Mon, Oct 07, 2019 at 09:24:39PM +0300, Eli Zaretskii wrote:
>> Date: Mon, 7 Oct 2019 19:12:30 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org,
>> 	Juri Linkov <juri@linkov.net>
>>
>> Hi I am trying to open a file in a new tab: C-x 6 f and I am getting a
>> segfault:
>
>Should be fixed now.
>

I get the same error... 

>> The previous bt was when -nw, but in gui I am getting nothing.. C-x 6 f
>> opens the file but not creates a tab... What happened?? This was fine
>> before.
>
>I cannot reproduce this part: C-x 6 f works for me in GUI sessions as
>expected.
>

Re: Tabs

[Eli Zaretskii]

> Date: Mon, 7 Oct 2019 21:28:36 +0200
> From: Ergus <spacibba@aol.com>
> Cc: michael_heerdegen@web.de, juri@linkov.net, emacs-devel@gnu.org
> 
> On Mon, Oct 07, 2019 at 09:24:39PM +0300, Eli Zaretskii wrote:
> >> Date: Mon, 7 Oct 2019 19:12:30 +0200
> >> From: Ergus <spacibba@aol.com>
> >> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org,
> >> 	Juri Linkov <juri@linkov.net>
> >>
> >> Hi I am trying to open a file in a new tab: C-x 6 f and I am getting a
> >> segfault:
> >
> >Should be fixed now.
> >
> 
> I get the same error... 

Then please bisect to see which commit caused this.

Re: Tabs

[Ergus]

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

Hi Eli:

The segfault actually disappeared today after your fix... Not sure why
on yesterday it was still there... 

But the issue of not having the tabs in gui is still there. The tabs are
only visible when I type M-x and the minibuffer is active and they are
incomplete and look weird (with wrong information actually). (Picture
attached)

When no minibuffer is active I get no tabs at all. I am moving back in
history and the issue seems to be there since ever. (I just haven't try
gui before)

My build options are:

../configure --prefix=/mnt/casa/install_arch/emacs --with-xwidgets
--with-x-toolkit=gtk3 --with-xft --with-modules --with-mailutil

Best,
Ergus.

[-- Attachment #2: Screenshot_2019-10-08_10-41-38.png --]
[-- Type: image/png, Size: 30498 bytes --]

Re: Tabs

[Eli Zaretskii]

> Date: Tue, 8 Oct 2019 10:56:04 +0200
> From: Ergus <spacibba@aol.com>
> Cc: michael_heerdegen@web.de, emacs-devel@gnu.org, juri@linkov.net
> 
> The segfault actually disappeared today after your fix... Not sure why
> on yesterday it was still there... 

That's what I thought yesterday.  But today I see it with my fix, so I
think it's some kind of Heisenbug related to memory allocation
problems.  Expect it to come back.  I will look more into it.

> But the issue of not having the tabs in gui is still there. The tabs are
> only visible when I type M-x and the minibuffer is active and they are
> incomplete and look weird (with wrong information actually). (Picture
> attached)
> 
> When no minibuffer is active I get no tabs at all. I am moving back in
> history and the issue seems to be there since ever. (I just haven't try
> gui before)

Please show an exact recipe starting from "emacs -Q".

Re: Tabs

[Eli Zaretskii]

> Date: Tue, 08 Oct 2019 12:18:01 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: michael_heerdegen@web.de, juri@linkov.net, emacs-devel@gnu.org
> 
> > Date: Tue, 8 Oct 2019 10:56:04 +0200
> > From: Ergus <spacibba@aol.com>
> > Cc: michael_heerdegen@web.de, emacs-devel@gnu.org, juri@linkov.net
> > 
> > The segfault actually disappeared today after your fix... Not sure why
> > on yesterday it was still there... 
> 
> That's what I thought yesterday.  But today I see it with my fix, so I
> think it's some kind of Heisenbug related to memory allocation
> problems.  Expect it to come back.  I will look more into it.

I hope I fixed this tricky bug now.

Re: Tabs

[Ergus]

On Tue, Oct 08, 2019 at 12:18:01PM +0300, Eli Zaretskii wrote:
>> Date: Tue, 8 Oct 2019 10:56:04 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: michael_heerdegen@web.de, emacs-devel@gnu.org, juri@linkov.net
>>
>> The segfault actually disappeared today after your fix... Not sure why
>> on yesterday it was still there...
>
>That's what I thought yesterday.  But today I see it with my fix, so I
>think it's some kind of Heisenbug related to memory allocation
>problems.  Expect it to come back.  I will look more into it.
>
>> But the issue of not having the tabs in gui is still there. The tabs are
>> only visible when I type M-x and the minibuffer is active and they are
>> incomplete and look weird (with wrong information actually). (Picture
>> attached)
>>
>> When no minibuffer is active I get no tabs at all. I am moving back in
>> history and the issue seems to be there since ever. (I just haven't try
>> gui before)
>
>Please show an exact recipe starting from "emacs -Q".


emacs -Q

C-x 6 f file RET

The file is opened but it not visible tabs.

C-TAB switches between scratch and file as expected, but no visible
tabs.

M-x

Enables the minibuffer and makes the tab-bar visible as in the picture. With
a hole in the beginning.

The visible tab content is actually the one not actually active I
think... but randomly after a while it becomes visible.   

Re: Tabs

[Eli Zaretskii]

> Date: Tue, 8 Oct 2019 18:00:38 +0200
> From: Ergus <spacibba@aol.com>
> Cc: michael_heerdegen@web.de, emacs-devel@gnu.org, juri@linkov.net
> 
> >Please show an exact recipe starting from "emacs -Q".
> 
> 
> emacs -Q
> 
> C-x 6 f file RET
> 
> The file is opened but it not visible tabs.

If you run this under GDB with a breakpoint on
x_change_tab_bar_height, do you see that function called after you
press RET?  If so, please show the backtrace from the call.  I expect
it to be called twice, so please show both backtraces.

Re: Tabs

[Ergus]

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

gdb log attached. Tell me if you need something else:



On Tue, Oct 08, 2019 at 07:18:40PM +0300, Eli Zaretskii wrote:
>> Date: Tue, 8 Oct 2019 18:00:38 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: michael_heerdegen@web.de, emacs-devel@gnu.org, juri@linkov.net
>>
>> >Please show an exact recipe starting from "emacs -Q".
>>
>>
>> emacs -Q
>>
>> C-x 6 f file RET
>>
>> The file is opened but it not visible tabs.
>
>If you run this under GDB with a breakpoint on
>x_change_tab_bar_height, do you see that function called after you
>press RET?  If so, please show the backtrace from the call.  I expect
>it to be called twice, so please show both backtraces.
>

[-- Attachment #2: gdb.txt --]
[-- Type: text/plain, Size: 12895 bytes --]

Breakpoint 1 at 0x1c9e9b: file ../../src/xfns.c, line 1634.
Starting program: /mnt/almacen/repo/gits/emacs/build/src/emacs -Q
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff119a700 (LWP 678317)]
[New Thread 0x7fffebf67700 (LWP 678318)]
[New Thread 0x7fffeb766700 (LWP 678319)]

Thread 1 "emacs" hit Breakpoint 1, x_change_tab_bar_height (f=0x5555560da410, height=0) at ../../src/xfns.c:1634
1634	  int unit = FRAME_LINE_HEIGHT (f);
#0  0x000055555571de9b in x_change_tab_bar_height (f=0x5555560da410, height=0) at ../../src/xfns.c:1634
#1  0x000055555571de84 in x_set_tab_bar_lines (f=0x5555560da410, value=0x2, oldval=0x0) at ../../src/xfns.c:1626
#2  0x00005555555b8262 in gui_set_frame_parameters (f=0x5555560da410, alist=0x0) at ../../src/frame.c:4106
#3  0x00005555555bbe25 in gui_default_parameter (f=0x5555560da410, alist=0x555555fca783, prop=0xcd50, deflt=0x2, xprop=0x0, xclass=0x0, type=RES_TYPE_NUMBER) at ../../src/frame.c:5276
#4  0x0000555555722f66 in Fx_create_frame (parms=0x555555fca783) at ../../src/xfns.c:4013
#5  0x000055555589ab85 in funcall_subr (subr=0x555555eddd20 <Sx_create_frame>, numargs=1, args=0x7fffffffa618) at ../../src/eval.c:2867
#6  0x000055555589a744 in Ffuncall (nargs=2, args=0x7fffffffa610) at ../../src/eval.c:2794
#7  0x0000555555908f9c in exec_byte_code (bytestr=0x7ffff1a910ec, vector=0x7ffff1a8fee5, maxdepth=0x36, args_template=0x402, nargs=1, args=0x7fffffffab30) at ../../src/bytecode.c:633
#8  0x000055555589b24b in funcall_lambda (fun=0x7ffff1a8feb5, nargs=1, arg_vector=0x7fffffffab28) at ../../src/eval.c:2989
#9  0x000055555589a788 in Ffuncall (nargs=2, args=0x7fffffffab20) at ../../src/eval.c:2796
#10 0x0000555555908f9c in exec_byte_code (bytestr=0x7ffff1a9112c, vector=0x7ffff1a8fe75, maxdepth=0xe, args_template=0x406, nargs=1, args=0x7fffffffb150) at ../../src/bytecode.c:633
#11 0x000055555589b24b in funcall_lambda (fun=0x7ffff1a8fe25, nargs=1, arg_vector=0x7fffffffb148) at ../../src/eval.c:2989
#12 0x000055555589a788 in Ffuncall (nargs=2, args=0x7fffffffb140) at ../../src/eval.c:2796
#13 0x0000555555899656 in Fapply (nargs=2, args=0x7fffffffb140) at ../../src/eval.c:2381
#14 0x000055555589aa90 in funcall_subr (subr=0x555555ee68e0 <Sapply>, numargs=2, args=0x7fffffffb140) at ../../src/eval.c:2847
#15 0x000055555589a744 in Ffuncall (nargs=3, args=0x7fffffffb138) at ../../src/eval.c:2794
#16 0x0000555555908f9c in exec_byte_code (bytestr=0x7ffff190cf54, vector=0x7ffff1a8cc3d, maxdepth=0x3e, args_template=0x202, nargs=1, args=0x7fffffffb678) at ../../src/bytecode.c:633
#17 0x000055555589b24b in funcall_lambda (fun=0x7ffff1a8cc0d, nargs=1, arg_vector=0x7fffffffb678) at ../../src/eval.c:2989
#18 0x000055555589a788 in Ffuncall (nargs=2, args=0x7fffffffb670) at ../../src/eval.c:2796
#19 0x0000555555908f9c in exec_byte_code (bytestr=0x7ffff1aa065c, vector=0x7ffff188702d, maxdepth=0x3a, args_template=0x402, nargs=1, args=0x7fffffffbc58) at ../../src/bytecode.c:633
#20 0x000055555589b24b in funcall_lambda (fun=0x7ffff1886ff5, nargs=1, arg_vector=0x7fffffffbc50) at ../../src/eval.c:2989
#21 0x000055555589a788 in Ffuncall (nargs=2, args=0x7fffffffbc48) at ../../src/eval.c:2796
#22 0x0000555555908f9c in exec_byte_code (bytestr=0x7ffff1c5b12c, vector=0x7ffff1c5b085, maxdepth=0x1a, args_template=0x2, nargs=0, args=0x7fffffffc140) at ../../src/bytecode.c:633
#23 0x000055555589b24b in funcall_lambda (fun=0x7ffff1c5b055, nargs=0, arg_vector=0x7fffffffc140) at ../../src/eval.c:2989
#24 0x000055555589a788 in Ffuncall (nargs=1, args=0x7fffffffc138) at ../../src/eval.c:2796
#25 0x0000555555908f9c in exec_byte_code (bytestr=0x7ffff1c611e4, vector=0x7ffff1c5d20d, maxdepth=0x3a, args_template=0x2, nargs=0, args=0x7fffffffcc88) at ../../src/bytecode.c:633
#26 0x000055555589b24b in funcall_lambda (fun=0x7ffff1c5d1dd, nargs=0, arg_vector=0x7fffffffcc88) at ../../src/eval.c:2989
#27 0x000055555589a788 in Ffuncall (nargs=1, args=0x7fffffffcc80) at ../../src/eval.c:2796
#28 0x0000555555908f9c in exec_byte_code (bytestr=0x7ffff1c61eac, vector=0x7ffff1c613b5, maxdepth=0x32, args_template=0x2, nargs=0, args=0x7fffffffd2c0) at ../../src/bytecode.c:633
#29 0x000055555589b24b in funcall_lambda (fun=0x7ffff1c61385, nargs=0, arg_vector=0x7fffffffd2c0) at ../../src/eval.c:2989
#30 0x000055555589af73 in apply_lambda (fun=0x7ffff1c61385, args=0x0, count=4) at ../../src/eval.c:2926
#31 0x000055555589929f in eval_sub (form=0x7ffff1db931b) at ../../src/eval.c:2318
#32 0x00005555558986d7 in Feval (form=0x7ffff1db931b, lexical=0x0) at ../../src/eval.c:2102
#33 0x0000555555772871 in top_level_2 () at ../../src/keyboard.c:1100
#34 0x0000555555896dd5 in internal_condition_case (bfun=0x55555577284e <top_level_2>, handlers=0x90, hfun=0x5555557722d3 <cmd_error>) at ../../src/eval.c:1355
#35 0x00005555557728b9 in top_level_1 (ignore=0x0) at ../../src/keyboard.c:1108
#36 0x0000555555896646 in internal_catch (tag=0xd470, func=0x555555772873 <top_level_1>, arg=0x0) at ../../src/eval.c:1116
#37 0x000055555577279a in command_loop () at ../../src/keyboard.c:1069
#38 0x0000555555771ea2 in recursive_edit_1 () at ../../src/keyboard.c:714
#39 0x0000555555772026 in Frecursive_edit () at ../../src/keyboard.c:786
#40 0x000055555576a491 in main (argc=2, argv=0x7fffffffd818) at ../../src/emacs.c:2055
Continuing.
[New Thread 0x7fffea8b2700 (LWP 678548)]
[Detaching after vfork from child process 678798]
[Detaching after vfork from child process 678799]
[Detaching after vfork from child process 678800]
[Detaching after vfork from child process 678801]

# Here Opens the window
# and type C-x 6 f file RET

Thread 1 "emacs" hit Breakpoint 1, x_change_tab_bar_height (f=0x5555560da410, height=18) at ../../src/xfns.c:1634
1634	  int unit = FRAME_LINE_HEIGHT (f);
#0  0x000055555571de9b in x_change_tab_bar_height (f=0x5555560da410, height=18) at ../../src/xfns.c:1634
#1  0x000055555571de84 in x_set_tab_bar_lines (f=0x5555560da410, value=0x6, oldval=0x2) at ../../src/xfns.c:1626
#2  0x00005555555b8262 in gui_set_frame_parameters (f=0x5555560da410, alist=0x0) at ../../src/frame.c:4106
#3  0x00005555555b6542 in Fmodify_frame_parameters (frame=0x5555560da415, alist=0x555556011fb3) at ../../src/frame.c:3324
#4  0x000055555589abaf in funcall_subr (subr=0x555555ed90a0 <Smodify_frame_parameters>, numargs=2, args=0x7fffffffafc8) at ../../src/eval.c:2869
#5  0x000055555589a744 in Ffuncall (nargs=3, args=0x7fffffffafc0) at ../../src/eval.c:2794
#6  0x0000555555908f9c in exec_byte_code (bytestr=0x7ffff1837134, vector=0x7ffff18370d5, maxdepth=0x1e, args_template=0xc0e, nargs=3, args=0x7fffffffb490) at ../../src/bytecode.c:633
#7  0x000055555589b24b in funcall_lambda (fun=0x7ffff18370a5, nargs=3, arg_vector=0x7fffffffb478) at ../../src/eval.c:2989
#8  0x000055555589a788 in Ffuncall (nargs=4, args=0x7fffffffb470) at ../../src/eval.c:2796
#9  0x0000555555908f9c in exec_byte_code (bytestr=0x7ffff1aba184, vector=0x7ffff183b2d5, maxdepth=0x2a, args_template=0x402, nargs=1, args=0x7fffffffb9b0) at ../../src/bytecode.c:633
#10 0x000055555589b24b in funcall_lambda (fun=0x7ffff183b29d, nargs=1, arg_vector=0x7fffffffb9a8) at ../../src/eval.c:2989
#11 0x000055555589a788 in Ffuncall (nargs=2, args=0x7fffffffb9a0) at ../../src/eval.c:2796
#12 0x0000555555908f9c in exec_byte_code (bytestr=0x7ffff1a7910c, vector=0x7ffff1a7895d, maxdepth=0x2e, args_template=0x2, nargs=0, args=0x7fffffffbf50) at ../../src/bytecode.c:633
#13 0x000055555589b24b in funcall_lambda (fun=0x7ffff1a78925, nargs=0, arg_vector=0x7fffffffbf50) at ../../src/eval.c:2989
#14 0x000055555589a788 in Ffuncall (nargs=1, args=0x7fffffffbf48) at ../../src/eval.c:2796
#15 0x0000555555908f9c in exec_byte_code (bytestr=0x7ffff1abdfd4, vector=0x7ffff1abdfa5, maxdepth=0x16, args_template=0x806, nargs=1, args=0x7fffffffc400) at ../../src/bytecode.c:633
#16 0x000055555589b24b in funcall_lambda (fun=0x7ffff1abdf05, nargs=1, arg_vector=0x7fffffffc3f8) at ../../src/eval.c:2989
#17 0x000055555589a788 in Ffuncall (nargs=2, args=0x7fffffffc3f0) at ../../src/eval.c:2796
#18 0x0000555555908f9c in exec_byte_code (bytestr=0x7ffff1a4f89c, vector=0x7ffff1abe17d, maxdepth=0x1e, args_template=0x806, nargs=2, args=0x7fffffffc9f0) at ../../src/bytecode.c:633
#19 0x000055555589b24b in funcall_lambda (fun=0x7ffff1abe0d5, nargs=2, arg_vector=0x7fffffffc9e0) at ../../src/eval.c:2989
#20 0x000055555589a788 in Ffuncall (nargs=3, args=0x7fffffffc9d8) at ../../src/eval.c:2796
#21 0x000055555588d20c in Ffuncall_interactively (nargs=3, args=0x7fffffffc9d8) at ../../src/callint.c:254
#22 0x000055555589aa90 in funcall_subr (subr=0x555555ee60e0 <Sfuncall_interactively>, numargs=3, args=0x7fffffffc9d8) at ../../src/eval.c:2847
#23 0x000055555589a744 in Ffuncall (nargs=4, args=0x7fffffffc9d0) at ../../src/eval.c:2794
#24 0x00005555558999b7 in Fapply (nargs=3, args=0x7fffffffcc50) at ../../src/eval.c:2424
#25 0x000055555588d5b6 in Fcall_interactively (function=0x2aaa9bb73ca0, record_flag=0x0, keys=0x7ffff1db9425) at ../../src/callint.c:342
#26 0x000055555589abe5 in funcall_subr (subr=0x555555ee6120 <Scall_interactively>, numargs=3, args=0x7fffffffce00) at ../../src/eval.c:2872
#27 0x000055555589a744 in Ffuncall (nargs=4, args=0x7fffffffcdf8) at ../../src/eval.c:2794
#28 0x0000555555908f9c in exec_byte_code (bytestr=0x7ffff195d8cc, vector=0x7ffff195d45d, maxdepth=0x36, args_template=0x1006, nargs=1, args=0x7fffffffd340) at ../../src/bytecode.c:633
#29 0x000055555589b24b in funcall_lambda (fun=0x7ffff195d42d, nargs=1, arg_vector=0x7fffffffd338) at ../../src/eval.c:2989
#30 0x000055555589a788 in Ffuncall (nargs=2, args=0x7fffffffd330) at ../../src/eval.c:2796
#31 0x0000555555899fdf in call1 (fn=0x4320, arg1=0x2aaa9bb73ca0) at ../../src/eval.c:2654
#32 0x000055555577338c in command_loop_1 () at ../../src/keyboard.c:1458
#33 0x0000555555896dd5 in internal_condition_case (bfun=0x555555772b60 <command_loop_1>, handlers=0x90, hfun=0x5555557722d3 <cmd_error>) at ../../src/eval.c:1355
#34 0x0000555555772825 in command_loop_2 (ignore=0x0) at ../../src/keyboard.c:1091
#35 0x0000555555896646 in internal_catch (tag=0xd470, func=0x5555557727f8 <command_loop_2>, arg=0x0) at ../../src/eval.c:1116
#36 0x00005555557727c3 in command_loop () at ../../src/keyboard.c:1070
#37 0x0000555555771ea2 in recursive_edit_1 () at ../../src/keyboard.c:714
#38 0x0000555555772026 in Frecursive_edit () at ../../src/keyboard.c:786
#39 0x000055555576a491 in main (argc=2, argv=0x7fffffffd818) at ../../src/emacs.c:2055
Continuing.

Thread 1 "emacs" hit Breakpoint 1, x_change_tab_bar_height (f=0x5555560da410, height=21) at ../../src/xfns.c:1634
1634	  int unit = FRAME_LINE_HEIGHT (f);
#0  0x000055555571de9b in x_change_tab_bar_height (f=0x5555560da410, height=21) at ../../src/xfns.c:1634
#1  0x00005555555f009a in redisplay_tab_bar (f=0x5555560da410) at ../../src/xdisp.c:13061
#2  0x00005555555ff187 in redisplay_window (window=0x5555562b8ba5, just_this_one_p=false) at ../../src/xdisp.c:18879
#3  0x00005555555f555a in redisplay_window_0 (window=0x5555562b8ba5) at ../../src/xdisp.c:16148
#4  0x0000555555896e7c in internal_condition_case_1 (bfun=0x5555555f5518 <redisplay_window_0>, arg=0x5555562b8ba5, handlers=0x7ffff1aeb853, hfun=0x5555555f54e0 <redisplay_window_error>)
    at ../../src/eval.c:1379
#5  0x00005555555f54b6 in redisplay_windows (window=0x5555562b8ba5) at ../../src/xdisp.c:16128
#6  0x00005555555f433f in redisplay_internal () at ../../src/xdisp.c:15598
#7  0x00005555555f2564 in redisplay () at ../../src/xdisp.c:14825
#8  0x0000555555775f59 in read_char (commandflag=1, map=0x555556010983, prev_event=0x0, used_mouse_menu=0x7fffffffd171, end_time=0x0) at ../../src/keyboard.c:2473
#9  0x00005555557858ba in read_key_sequence (keybuf=0x7fffffffd3a0, prompt=0x0, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false)
    at ../../src/keyboard.c:9527
#10 0x0000555555772fa8 in command_loop_1 () at ../../src/keyboard.c:1345
#11 0x0000555555896dd5 in internal_condition_case (bfun=0x555555772b60 <command_loop_1>, handlers=0x90, hfun=0x5555557722d3 <cmd_error>) at ../../src/eval.c:1355
#12 0x0000555555772825 in command_loop_2 (ignore=0x0) at ../../src/keyboard.c:1091
#13 0x0000555555896646 in internal_catch (tag=0xd470, func=0x5555557727f8 <command_loop_2>, arg=0x0) at ../../src/eval.c:1116
#14 0x00005555557727c3 in command_loop () at ../../src/keyboard.c:1070
#15 0x0000555555771ea2 in recursive_edit_1 () at ../../src/keyboard.c:714
#16 0x0000555555772026 in Frecursive_edit () at ../../src/keyboard.c:786
#17 0x000055555576a491 in main (argc=2, argv=0x7fffffffd818) at ../../src/emacs.c:2055
Continuing.
[Thread 0x7fffea8b2700 (LWP 678548) exited]
[Thread 0x7fffebf67700 (LWP 678318) exited]
[Thread 0x7ffff119a700 (LWP 678317) exited]
[Thread 0x7ffff2106e40 (LWP 678307) exited]
[Inferior 1 (process 678307) exited normally]

Re: Tabs

[Eli Zaretskii]

> Date: Tue, 8 Oct 2019 18:40:48 +0200
> From: Ergus <spacibba@aol.com>
> Cc: michael_heerdegen@web.de, juri@linkov.net, emacs-devel@gnu.org
> 
> 
> [1:text/plain Hide]
> 
> gdb log attached. Tell me if you need something else:

Thanks.  If you run the recipe with breakpoint on this line of
xdisp.c:

                  if (FRAME_GARBAGED_P (f))
		    {
		      fset_redisplay (f);
		      f->garbaged = false;  <<<<<<<<<<<<<<<<<<<<
		      goto retry_frame;
		    }

(if your repository is up to date and you are on the master branch,
this should be line 15690), does the breakpoint fire after you type
the "C-x 6 f FILENAME RET" command?

Re: Tabs

[Ergus]

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

On Tue, Oct 08, 2019 at 08:03:23PM +0300, Eli Zaretskii wrote:
>> Date: Tue, 8 Oct 2019 18:40:48 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: michael_heerdegen@web.de, juri@linkov.net, emacs-devel@gnu.org
>>
>>
>> [1:text/plain Hide]
>>
>> gdb log attached. Tell me if you need something else:
>
>Thanks.  If you run the recipe with breakpoint on this line of
>xdisp.c:
>
>                  if (FRAME_GARBAGED_P (f))
>		    {
>		      fset_redisplay (f);
>		      f->garbaged = false;  <<<<<<<<<<<<<<<<<<<<
>		      goto retry_frame;
>		    }
>
>(if your repository is up to date and you are on the master branch,
>this should be line 15690), does the breakpoint fire after you type
>the "C-x 6 f FILENAME RET" command?

No actually. I only get some messages:

(gdb) run
Starting program: /mnt/almacen/repo/gits/emacs/build/src/emacs -Q
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff119e700 (LWP 20903)]
[New Thread 0x7fffebf6b700 (LWP 20904)]
[New Thread 0x7fffeb76a700 (LWP 20905)]
[New Thread 0x7fffea8b6700 (LWP 20917)]
[Detaching after vfork from child process 21286]
[Detaching after vfork from child process 21287]
[Detaching after vfork from child process 21288]
[Detaching after vfork from child process 21289]


But nothing else; the breakpoint is not reached.

Something else I observe is that when I leave the desktop and return
back; the tab-bar is visible, but with the cursor there. When I move the
cursor horizontally, the tabs image is substituted with the text that is
supposed to be in the first visible line that is supposed to be bellow
the tab-bar (attached image with the config.log open.)

[-- Attachment #2: Screenshot_2019-10-09_01-37-46.png --]
[-- Type: image/png, Size: 43740 bytes --]

Re: Tabs

[Eli Zaretskii]

> Date: Wed, 9 Oct 2019 01:43:50 +0200
> From: Ergus <spacibba@aol.com>
> Cc: michael_heerdegen@web.de, juri@linkov.net, emacs-devel@gnu.org
> 
> >                  if (FRAME_GARBAGED_P (f))
> >		    {
> >		      fset_redisplay (f);
> >		      f->garbaged = false;  <<<<<<<<<<<<<<<<<<<<
> >		      goto retry_frame;
> >		    }
> >
> >(if your repository is up to date and you are on the master branch,
> >this should be line 15690), does the breakpoint fire after you type
> >the "C-x 6 f FILENAME RET" command?
> 
> No actually. I only get some messages:
> But nothing else; the breakpoint is not reached.

OK, so this is not due to the recent change which introduced the above
code.

In your original message you wrote:

> This used to work fine before... I just pull and recompiled (since
> saturday)...

Can you tell what was the latest date when this problem in GUI frames
didn't exist in your builds?

> Something else I observe is that when I leave the desktop and return
> back; the tab-bar is visible, but with the cursor there. When I move the
> cursor horizontally, the tabs image is substituted with the text that is
> supposed to be in the first visible line that is supposed to be bellow
> the tab-bar (attached image with the config.log open.)

Yes, these and other symptoms you described all tell one thing: that
some redisplay optimization is taken that shouldn't be used in this
case.  IOW, Emacs optimizes redisplay ignoring the fact that there is
now a tab bar, which usurps portions of display that previously
belonged to some window.  I just don't yet understand why this
happens, because the call to SET_FRAME_GARBAGED in
x_change_tab_bar_height should have had the effect of disabling all
the redisplay optimizations for this frame...

Does the change below fix this problem, per chance?

diff --git a/src/xfns.c b/src/xfns.c
index 20e63a2..f2264be 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -1660,6 +1660,8 @@ x_change_tab_bar_height (struct frame *f, int height)
 
   if ((height < old_height) && WINDOWP (f->tab_bar_window))
     clear_glyph_matrix (XWINDOW (f->tab_bar_window)->current_matrix);
+  else if (height > old_height)
+    clear_current_matrices (f);
 
   /* Recalculate tabbar height.  */
   f->n_tab_bar_rows = 0;

Re: Tabs

[Ergus]

Hi:

On Wed, Oct 09, 2019 at 11:37:09AM +0300, Eli Zaretskii wrote:
>> Date: Wed, 9 Oct 2019 01:43:50 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: michael_heerdegen@web.de, juri@linkov.net, emacs-devel@gnu.org
>>
>> >                  if (FRAME_GARBAGED_P (f))
>> >		    {
>> >		      fset_redisplay (f);
>> >		      f->garbaged = false;  <<<<<<<<<<<<<<<<<<<<
>> >		      goto retry_frame;
>> >		    }
>> >
>> >(if your repository is up to date and you are on the master branch,
>> >this should be line 15690), does the breakpoint fire after you type
>> >the "C-x 6 f FILENAME RET" command?
>>
>> No actually. I only get some messages:
>> But nothing else; the breakpoint is not reached.
>
>OK, so this is not due to the recent change which introduced the above
>code.
>
>In your original message you wrote:
>
>> This used to work fine before... I just pull and recompiled (since
>> saturday)...
>
>Can you tell what was the latest date when this problem in GUI frames
>didn't exist in your builds?
>
>> Something else I observe is that when I leave the desktop and return
>> back; the tab-bar is visible, but with the cursor there. When I move the
>> cursor horizontally, the tabs image is substituted with the text that is
>> supposed to be in the first visible line that is supposed to be bellow
>> the tab-bar (attached image with the config.log open.)
>
>Yes, these and other symptoms you described all tell one thing: that
>some redisplay optimization is taken that shouldn't be used in this
>case.  IOW, Emacs optimizes redisplay ignoring the fact that there is
>now a tab bar, which usurps portions of display that previously
>belonged to some window.  I just don't yet understand why this
>happens, because the call to SET_FRAME_GARBAGED in
>x_change_tab_bar_height should have had the effect of disabling all
>the redisplay optimizations for this frame...
>
>Does the change below fix this problem, per chance?
>
>diff --git a/src/xfns.c b/src/xfns.c
>index 20e63a2..f2264be 100644
>--- a/src/xfns.c
>+++ b/src/xfns.c
>@@ -1660,6 +1660,8 @@ x_change_tab_bar_height (struct frame *f, int height)
>
>   if ((height < old_height) && WINDOWP (f->tab_bar_window))
>     clear_glyph_matrix (XWINDOW (f->tab_bar_window)->current_matrix);
>+  else if (height > old_height)
>+    clear_current_matrices (f);
>
>   /* Recalculate tabbar height.  */
>   f->n_tab_bar_rows = 0;

It solved partially the problem, which is good.

1) The tabs does not become visible automatically after C-x 6 f, and
C-TAB works as yesterday.

2) But when I leave the desk and return they become visible but this
time they are clickable. (unlike yesterday)

They does not have a cursor as before and the first line is after the
tab-bar as they should. So it seems that the problem is related with
this.

Re: Tabs

[Eli Zaretskii]

> Date: Wed, 9 Oct 2019 12:39:36 +0200
> From: Ergus <spacibba@aol.com>
> Cc: michael_heerdegen@web.de, juri@linkov.net, emacs-devel@gnu.org
> 
> >Does the change below fix this problem, per chance?
> >
> >diff --git a/src/xfns.c b/src/xfns.c
> >index 20e63a2..f2264be 100644
> >--- a/src/xfns.c
> >+++ b/src/xfns.c
> >@@ -1660,6 +1660,8 @@ x_change_tab_bar_height (struct frame *f, int height)
> >
> >   if ((height < old_height) && WINDOWP (f->tab_bar_window))
> >     clear_glyph_matrix (XWINDOW (f->tab_bar_window)->current_matrix);
> >+  else if (height > old_height)
> >+    clear_current_matrices (f);
> >
> >   /* Recalculate tabbar height.  */
> >   f->n_tab_bar_rows = 0;
> 
> It solved partially the problem, which is good.
> 
> 1) The tabs does not become visible automatically after C-x 6 f, and
> C-TAB works as yesterday.
> 
> 2) But when I leave the desk and return they become visible but this
> time they are clickable. (unlike yesterday)

What about the change below?

If it still doesn't work, can you try disabling double-buffering?

diff --git a/src/xdisp.c b/src/xdisp.c
index 893ce92..f94f651 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -11796,7 +11796,7 @@ clear_garbaged_frames (void)
 
 	  if (FRAME_VISIBLE_P (f) && FRAME_GARBAGED_P (f))
 	    {
-	      if (f->resized_p
+	      if ((f->resized_p || f->tab_bar_resized)
 		  /* It makes no sense to redraw a non-selected TTY
 		     frame, since that will actually clear the
 		     selected frame, and might leave the selected

Re: Tabs

[Ergus]

On Wed, Oct 09, 2019 at 02:35:41PM +0300, Eli Zaretskii wrote:
>> Date: Wed, 9 Oct 2019 12:39:36 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: michael_heerdegen@web.de, juri@linkov.net, emacs-devel@gnu.org
>>
>> >Does the change below fix this problem, per chance?
>> >
>> >diff --git a/src/xfns.c b/src/xfns.c
>> >index 20e63a2..f2264be 100644
>> >--- a/src/xfns.c
>> >+++ b/src/xfns.c
>> >@@ -1660,6 +1660,8 @@ x_change_tab_bar_height (struct frame *f, int height)
>> >
>> >   if ((height < old_height) && WINDOWP (f->tab_bar_window))
>> >     clear_glyph_matrix (XWINDOW (f->tab_bar_window)->current_matrix);
>> >+  else if (height > old_height)
>> >+    clear_current_matrices (f);
>> >
>> >   /* Recalculate tabbar height.  */
>> >   f->n_tab_bar_rows = 0;
>>
>> It solved partially the problem, which is good.
>>
>> 1) The tabs does not become visible automatically after C-x 6 f, and
>> C-TAB works as yesterday.
>>
>> 2) But when I leave the desk and return they become visible but this
>> time they are clickable. (unlike yesterday)
>
>What about the change below?
>
>If it still doesn't work, can you try disabling double-buffering?
>
How?

>diff --git a/src/xdisp.c b/src/xdisp.c
>index 893ce92..f94f651 100644
>--- a/src/xdisp.c
>+++ b/src/xdisp.c
>@@ -11796,7 +11796,7 @@ clear_garbaged_frames (void)
>
> 	  if (FRAME_VISIBLE_P (f) && FRAME_GARBAGED_P (f))
> 	    {
>-	      if (f->resized_p
>+	      if ((f->resized_p || f->tab_bar_resized)
> 		  /* It makes no sense to redraw a non-selected TTY
> 		     frame, since that will actually clear the
> 		     selected frame, and might leave the selected

No, this does nothing, actually after trying it a little bit more the
other change the behavior is the same most of the cases. So, the
previous change didn't fix/change anything :(.

Re: Tabs

[Eli Zaretskii]

> Date: Wed, 9 Oct 2019 14:05:34 +0200
> From: Ergus <spacibba@aol.com>
> Cc: michael_heerdegen@web.de, juri@linkov.net, emacs-devel@gnu.org
> 
> >If it still doesn't work, can you try disabling double-buffering?
> >
> How?

Evaluate this (before invoking "C-x 6 f"):

  (modify-frame-parameters nil '((inhibit-double-buffering . t)))

Re: Tabs

[Eli Zaretskii]

Martin, can you please explain the rationale behind this code in
x_change_tool_bar_height (and similar code in the w32 variant)?

  /* Recalculate toolbar height.  */
  f->n_tool_bar_rows = 0;
  if (old_height == 0
      && (!f->after_make_frame
	  || NILP (frame_inhibit_implied_resize)
	  || (CONSP (frame_inhibit_implied_resize)
	      && NILP (Fmemq (Qtool_bar_lines, frame_inhibit_implied_resize)))))
    f->tool_bar_redisplayed = f->tool_bar_resized = false;

  adjust_frame_size (f, -1, -1,
		     ((!f->tool_bar_resized
		       && (NILP (fullscreen =
				 get_frame_param (f, Qfullscreen))
			   || EQ (fullscreen, Qfullwidth))) ? 1
		      : (old_height == 0 || height == 0) ? 2
		      : 4),
		     false, Qtool_bar_lines);

  f->tool_bar_resized = f->tool_bar_redisplayed;

Here are the questions that I couldn't answer myself:

 . why the tool_bar_resized flag is reset when
   frame-inhibit-implied-resize is nil, i.e. implied resizing is _NOT_
   inhibited? shouldn't it be the other way around?

 . the above resets the tool_bar_redisplayed flag, then uses it after
   the call to adjust_frame_size; but nothing in that call can ever
   change the value of the tool_bar_redisplayed flag, so I don't
   understand what the code tries to accomplish.

 . which code is supposed to reset the tool_bar_resized flag?  AFAICT,
   once set, it stays set, at least in "emacs -Q".  Did I miss
   something?  Same question regarding the tool_bar_redisplayed flag.

The real motivation for these questions is the problem with
redisplaying the frame when tab-bar is turned on by "C-x 6 f", but
since the tab-bar code was simply copied from the tool-bar code, I
find myself wondering about the latter, and hope you can show me the
light there.

TIA

Re: Tabs

[martin rudalics]

 > Martin, can you please explain the rationale behind this code in
 > x_change_tool_bar_height (and similar code in the w32 variant)?

It's also in GTK's update_frame_tool_bar.

 >    /* Recalculate toolbar height.  */
 >    f->n_tool_bar_rows = 0;
 >    if (old_height == 0
 >        && (!f->after_make_frame
 > 	  || NILP (frame_inhibit_implied_resize)
 > 	  || (CONSP (frame_inhibit_implied_resize)
 > 	      && NILP (Fmemq (Qtool_bar_lines, frame_inhibit_implied_resize)))))
 >      f->tool_bar_redisplayed = f->tool_bar_resized = false;
 >
 >    adjust_frame_size (f, -1, -1,
 > 		     ((!f->tool_bar_resized
 > 		       && (NILP (fullscreen =
 > 				 get_frame_param (f, Qfullscreen))
 > 			   || EQ (fullscreen, Qfullwidth))) ? 1
 > 		      : (old_height == 0 || height == 0) ? 2
 > 		      : 4),
 > 		     false, Qtool_bar_lines);
 >
 >    f->tool_bar_resized = f->tool_bar_redisplayed;
 >
 > Here are the questions that I couldn't answer myself:
 >
 >   . why the tool_bar_resized flag is reset when
 >     frame-inhibit-implied-resize is nil, i.e. implied resizing is _NOT_
 >     inhibited? shouldn't it be the other way around?

The original motivation was as follows.  A frame needs intially as
many text lines as the user wants.  On the Lucid, Motif, Windows
builds, as an ancient rule, a frame does not get resized when the tool
bar is activated or deactivated.  However, in the before make frame
phase the frame must be resized to get its number of lines.

So the idea was that redisplay eventually will set
tool_bar_redisplayed after calculating the tool bar height and that
value is copied to tool_bar_resized to make sure this frame never gets
resized again when the tool bar changes.  So these resets should
handle only this initial resize operation and no others.

In addition we should not resize if 'frame-inhibit-implied-resize' is
t, the frame is full height or full screen and the like.

 >   . the above resets the tool_bar_redisplayed flag,

... conditionally, though ...

 >     then uses it after
 >     the call to adjust_frame_size; but nothing in that call can ever
 >     change the value of the tool_bar_redisplayed flag, so I don't
 >     understand what the code tries to accomplish.

It's at least badly documented and maybe also badly ordered.  The idea
is that eventually the tool_bar_redisplayed and the tool_bar_resized
flag get both set and in the default case the frame is never resized
after that when the number of tool bar lines changes.

 >   . which code is supposed to reset the tool_bar_resized flag?  AFAICT,
 >     once set, it stays set, at least in "emacs -Q".  Did I miss
 >     something?  Same question regarding the tool_bar_redisplayed flag.

Once set for a particular frame, these are never reset.  The aim was
(after a row of complaints) a single one: To give all frames
regardless of build and window system the same initial number of text
lines regardless of whether tool bars are turned on or off initially.

 > The real motivation for these questions is the problem with
 > redisplaying the frame when tab-bar is turned on by "C-x 6 f", but
 > since the tab-bar code was simply copied from the tool-bar code, I
 > find myself wondering about the latter, and hope you can show me the
 > light there.

As you mentioned earlier, tab bars are initially off and the tool bar
is on.  Maybe that's the cause of the problem.

martin

Re: Tabs

[Eli Zaretskii]

> Cc: Ergus <spacibba@aol.com>, juri@linkov.net, emacs-devel@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 9 Oct 2019 20:12:44 +0200
> 
> So the idea was that redisplay eventually will set
> tool_bar_redisplayed after calculating the tool bar height and that
> value is copied to tool_bar_resized to make sure this frame never gets
> resized again when the tool bar changes.  So these resets should
> handle only this initial resize operation and no others.

Ah, so these are one-off flags, and not indications of the resize,
i.e. they are not supposed to be sensitive to, say, when a tool bar
becomes too large for one line and needs two, is that so?

>  > The real motivation for these questions is the problem with
>  > redisplaying the frame when tab-bar is turned on by "C-x 6 f", but
>  > since the tab-bar code was simply copied from the tool-bar code, I
>  > find myself wondering about the latter, and hope you can show me the
>  > light there.
> 
> As you mentioned earlier, tab bars are initially off and the tool bar
> is on.  Maybe that's the cause of the problem.

No, I think the cause of the problem is that we have no equivalent of
"C-x 6 f" that turns on the tool bar as a side effect of a command
that displays a buffer.  But that's a guess, because I've just
established with Jimmy's help that even the call to redraw_frame
doesn't cause the expected effect.  Which completely stumps me, and I
need to think about it before I come with more ideas (_if_ I come with
more ideas)...

Re: Tabs

[martin rudalics]

 > Ah, so these are one-off flags, and not indications of the resize,
 > i.e. they are not supposed to be sensitive to, say, when a tool bar
 > becomes too large for one line and needs two, is that so?

They are one-off in the following sense:

(1) Initially the flags are off.  redisplay_tool_bar unconditionally
     sets f->tool_bar_redisplayed to true every time it runs, so
     redisplay_tool_bar is, by design, agnostic of the underlying
     mechanism.

(2) The mechanism for exceptionally allowing to change the frame
     height when a tool bar height shall be established is confined to
     the change_tool_bar_height functions and their GTK counterpart.
     There, f->tool_bar_redisplayed is reset if certain conditions are
     met so any earlier calculation by redisplay_tool_bar is forgotten
     - don't ask me if such a calculation could have happened in
     practice, I don't remember.

     In either case the mechanism is only sharpened here and as we have
     seen with Bug#37609 its effect may trigger a long time after the
     initial frame has been made.  Maybe we could inhibit it by having
     any caller(s) of redisplay_tool_bar set f->tool_bar_redisplayed
     even if they do not call redisplay_tool_bar.  But I'm not sure.
     ISTR that I tried alternative solutions for this but was always
     surprised at how late in the frame creation phase the tool bar
     could take on its final, exact size.

(3) Once the frame has been made and f->tool_bar_resized is set, the
     latter is never reset again and it's really one-off in the sense
     you described.

 >> As you mentioned earlier, tab bars are initially off and the tool bar
 >> is on.  Maybe that's the cause of the problem.
 >
 > No, I think the cause of the problem is that we have no equivalent of
 > "C-x 6 f" that turns on the tool bar as a side effect of a command
 > that displays a buffer.

I'm missing you here.  Do you mean that displaying a tool bar for the
first time in an Emacs session on a specific frame when you display a
certain buffer on that frame would have a similar dramatic effect?
Couldn't you verify that?

 > But that's a guess, because I've just
 > established with Jimmy's help that even the call to redraw_frame
 > doesn't cause the expected effect.  Which completely stumps me, and I
 > need to think about it before I come with more ideas (_if_ I come with
 > more ideas)...

I'm still not entirely sure whether it was a good idea to cargo cult
the tab bar code from the tool bar code.  Not that I have a
substantially better offer.  As a matter of fact, we should have
provided a good pseudo window mechanism for that.

martin

Re: Tabs

[Eli Zaretskii]

> Cc: spacibba@aol.com, emacs-devel@gnu.org, juri@linkov.net
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 10 Oct 2019 11:15:55 +0200
> 
> (3) Once the frame has been made and f->tool_bar_resized is set, the
>      latter is never reset again and it's really one-off in the sense
>      you described.

Thanks.  I will update the commentary for these members to reflect
your description.

>  > No, I think the cause of the problem is that we have no equivalent of
>  > "C-x 6 f" that turns on the tool bar as a side effect of a command
>  > that displays a buffer.
> 
> I'm missing you here.  Do you mean that displaying a tool bar for the
> first time in an Emacs session on a specific frame when you display a
> certain buffer on that frame would have a similar dramatic effect?

That's my current theory, yes.  Although I'm nowhere near sure it's
correct.

> Couldn't you verify that?

I don't know how.  We don't have the equivalent of "C-x 6 f" that
turns on a tool bar that was off before that, do we?

> I'm still not entirely sure whether it was a good idea to cargo cult
> the tab bar code from the tool bar code.

As a first approximation, it wasn't a bad idea.  But it needs various
adjustments due to the tab-bar specifics (including, but not limited
to, tab bar on TTY frames, where there's no "prior art" in tool-bar
code), and that's what we are struggling with now.  Also, the default
GTK build has a tool bar that is displayed entirely unlike the tab
bar, and that is another difficulty.

Btw... why do we set frame_inhibit_implied_resize to nil in GTK
builds?  Shouldn't it be (tab-bar-lines) instead?  The tab bar in GTK
build uses our own window, doesn't it?

Re: Tabs

[martin rudalics]

 > I don't know how.  We don't have the equivalent of "C-x 6 f" that
 > turns on a tool bar that was off before that, do we?

Doesn't Juri's recipe from Bug#37609 work?  Start with

emacs -Q -f tool-bar-mode

and use some function that enables 'tool-bar-mode'.

 > As a first approximation, it wasn't a bad idea.  But it needs various
 > adjustments due to the tab-bar specifics (including, but not limited
 > to, tab bar on TTY frames, where there's no "prior art" in tool-bar
 > code), and that's what we are struggling with now.

Shouldn't on a TTY the tab bar behave just like the menu bar?

 > Also, the default
 > GTK build has a tool bar that is displayed entirely unlike the tab
 > bar, and that is another difficulty.

Which difficulty?  I doubt it's the one that GTK auto-widens frames
when the tool bar gets too large.

 > Btw... why do we set frame_inhibit_implied_resize to nil in GTK
 > builds?  Shouldn't it be (tab-bar-lines) instead?

Now that you mention it, yes.

 > The tab bar in GTK
 > build uses our own window, doesn't it?

I've nowhere seen any code that would tell otherwise.

martin

Re: Tabs

[Eli Zaretskii]

> Cc: spacibba@aol.com, emacs-devel@gnu.org, juri@linkov.net
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 10 Oct 2019 12:38:01 +0200
> 
>  > I don't know how.  We don't have the equivalent of "C-x 6 f" that
>  > turns on a tool bar that was off before that, do we?
> 
> Doesn't Juri's recipe from Bug#37609 work?  Start with
> 
> emacs -Q -f tool-bar-mode
> 
> and use some function that enables 'tool-bar-mode'.

I need a function that will turn on the tool bar from
switch-to-buffer-* family of functions, and then cause adjustment of
frame glyphs from set-window-buffer, via apply_window_adjustment.  If
you have a suggestion for how to do this, please tell.

>  > As a first approximation, it wasn't a bad idea.  But it needs various
>  > adjustments due to the tab-bar specifics (including, but not limited
>  > to, tab bar on TTY frames, where there's no "prior art" in tool-bar
>  > code), and that's what we are struggling with now.
> 
> Shouldn't on a TTY the tab bar behave just like the menu bar?

Similar, yes.  But that a separate code, and it cannot be shared with
the menu bar, because the tab bar needs to know on the C level which
tab was clicked (the latter is a consequence of the fact that tab bar
support was copied from tool bar support code).

>  > Also, the default
>  > GTK build has a tool bar that is displayed entirely unlike the tab
>  > bar, and that is another difficulty.
> 
> Which difficulty?

That similar problems with tool bar might go unnoticed because the
code is never run.

>  > Btw... why do we set frame_inhibit_implied_resize to nil in GTK
>  > builds?  Shouldn't it be (tab-bar-lines) instead?
> 
> Now that you mention it, yes.

Will do.

Re: Tabs

[Eli Zaretskii]

> Date: Thu, 10 Oct 2019 14:33:23 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: spacibba@aol.com, juri@linkov.net, emacs-devel@gnu.org
> 
> >  > Btw... why do we set frame_inhibit_implied_resize to nil in GTK
> >  > builds?  Shouldn't it be (tab-bar-lines) instead?
> > 
> > Now that you mention it, yes.
> 
> Will do.

Done.  But this value doesn't affect the initial resize when tool bar
or tab bar are enabled for the first time in a session.  Right?

Re: Tabs

[martin rudalics]

 > Done.  But this value doesn't affect the initial resize when tool bar
 > or tab bar are enabled for the first time in a session.  Right?

Right.  Conceptually, the initial resize to get the right number of
text lines should take place regardless of any settings.  The only
exclusion are full height and size frames.

martin

Re: Tabs

[Eli Zaretskii]

> Date: Wed, 9 Oct 2019 14:05:34 +0200
> From: Ergus <spacibba@aol.com>
> Cc: michael_heerdegen@web.de, juri@linkov.net, emacs-devel@gnu.org
> 
> >diff --git a/src/xdisp.c b/src/xdisp.c
> >index 893ce92..f94f651 100644
> >--- a/src/xdisp.c
> >+++ b/src/xdisp.c
> >@@ -11796,7 +11796,7 @@ clear_garbaged_frames (void)
> >
> > 	  if (FRAME_VISIBLE_P (f) && FRAME_GARBAGED_P (f))
> > 	    {
> >-	      if (f->resized_p
> >+	      if ((f->resized_p || f->tab_bar_resized)
> > 		  /* It makes no sense to redraw a non-selected TTY
> > 		     frame, since that will actually clear the
> > 		     selected frame, and might leave the selected
> 
> No, this does nothing

If you set a breakpoint in this fragment from clear_garbaged_frames:

	  if (FRAME_VISIBLE_P (f) && FRAME_GARBAGED_P (f))
	    {
	      if ((f->resized_p || f->tab_bar_resized)
		  /* It makes no sense to redraw a non-selected TTY
		     frame, since that will actually clear the
		     selected frame, and might leave the selected
		     frame with corrupted display, if it happens not
		     to be marked garbaged.  */
		  && !(f != sf && (FRAME_TERMCAP_P (f) || FRAME_MSDOS_P (f))))
		redraw_frame (f);  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
	      else
		clear_current_matrices (f);

does the breakpoint fire after you type "C-x 6 f"?

Re: Tabs

[Ergus]

On Wed, Oct 09, 2019 at 03:36:06PM +0300, Eli Zaretskii wrote:
>> Date: Wed, 9 Oct 2019 14:05:34 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: michael_heerdegen@web.de, juri@linkov.net, emacs-devel@gnu.org
>>
>> >diff --git a/src/xdisp.c b/src/xdisp.c
>> >index 893ce92..f94f651 100644
>> >--- a/src/xdisp.c
>> >+++ b/src/xdisp.c
>> >@@ -11796,7 +11796,7 @@ clear_garbaged_frames (void)
>> >
>> > 	  if (FRAME_VISIBLE_P (f) && FRAME_GARBAGED_P (f))
>> > 	    {
>> >-	      if (f->resized_p
>> >+	      if ((f->resized_p || f->tab_bar_resized)
>> > 		  /* It makes no sense to redraw a non-selected TTY
>> > 		     frame, since that will actually clear the
>> > 		     selected frame, and might leave the selected
>>
>> No, this does nothing
>
>If you set a breakpoint in this fragment from clear_garbaged_frames:
>
>	  if (FRAME_VISIBLE_P (f) && FRAME_GARBAGED_P (f))
>	    {
>	      if ((f->resized_p || f->tab_bar_resized)
>		  /* It makes no sense to redraw a non-selected TTY
>		     frame, since that will actually clear the
>		     selected frame, and might leave the selected
>		     frame with corrupted display, if it happens not
>		     to be marked garbaged.  */
>		  && !(f != sf && (FRAME_TERMCAP_P (f) || FRAME_MSDOS_P (f))))
>		redraw_frame (f);  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>	      else
>		clear_current_matrices (f);
>
>does the breakpoint fire after you type "C-x 6 f"?

Yes:

Thread 1 "emacs" hit Breakpoint 1, clear_garbaged_frames () at ../../src/xdisp.c:11805
11805                   redraw_frame (f);
(gdb) bt
#0  0x00005555555ed30c in clear_garbaged_frames () at ../../src/xdisp.c:11805
#1  0x00005555555f33c9 in redisplay_internal () at ../../src/xdisp.c:15237
#2  0x00005555555f2564 in redisplay () at ../../src/xdisp.c:14825
#3  0x0000555555775f6f in read_char (commandflag=1, map=0x55555691f1e3, prev_event=0x0, used_mouse_menu=0x7fffffffd171, end_time=0x0) at ../../src/keyboard.c:2473
#4  0x00005555557858d0 in read_key_sequence (keybuf=0x7fffffffd3a0, prompt=0x0, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false)
    at ../../src/keyboard.c:9527
#5  0x0000555555772fbe in command_loop_1 () at ../../src/keyboard.c:1345
#6  0x0000555555896deb in internal_condition_case (bfun=0x555555772b76 <command_loop_1>, handlers=0x90, hfun=0x5555557722e9 <cmd_error>) at ../../src/eval.c:1355
#7  0x000055555577283b in command_loop_2 (ignore=0x0) at ../../src/keyboard.c:1091
#8  0x000055555589665c in internal_catch (tag=0xd470, func=0x55555577280e <command_loop_2>, arg=0x0) at ../../src/eval.c:1116
#9  0x00005555557727d9 in command_loop () at ../../src/keyboard.c:1070
#10 0x0000555555771eb8 in recursive_edit_1 () at ../../src/keyboard.c:714
#11 0x000055555577203c in Frecursive_edit () at ../../src/keyboard.c:786
#12 0x000055555576a4a7 in main (argc=2, argv=0x7fffffffd818) at ../../src/emacs.c:2055
(gdb) c
Continuing.

Thread 1 "emacs" hit Breakpoint 1, clear_garbaged_frames () at ../../src/xdisp.c:11805
11805                   redraw_frame (f);
(gdb) bt
#0  0x00005555555ed30c in clear_garbaged_frames () at ../../src/xdisp.c:11805
#1  0x00005555555f33c9 in redisplay_internal () at ../../src/xdisp.c:15237
#2  0x00005555555f2564 in redisplay () at ../../src/xdisp.c:14825
#3  0x0000555555775f6f in read_char (commandflag=1, map=0x55555691f1e3, prev_event=0x0, used_mouse_menu=0x7fffffffd171, end_time=0x0) at ../../src/keyboard.c:2473
#4  0x00005555557858d0 in read_key_sequence (keybuf=0x7fffffffd3a0, prompt=0x0, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false)
    at ../../src/keyboard.c:9527
#5  0x0000555555772fbe in command_loop_1 () at ../../src/keyboard.c:1345
#6  0x0000555555896deb in internal_condition_case (bfun=0x555555772b76 <command_loop_1>, handlers=0x90, hfun=0x5555557722e9 <cmd_error>) at ../../src/eval.c:1355
#7  0x000055555577283b in command_loop_2 (ignore=0x0) at ../../src/keyboard.c:1091
#8  0x000055555589665c in internal_catch (tag=0xd470, func=0x55555577280e <command_loop_2>, arg=0x0) at ../../src/eval.c:1116
#9  0x00005555557727d9 in command_loop () at ../../src/keyboard.c:1070
#10 0x0000555555771eb8 in recursive_edit_1 () at ../../src/keyboard.c:714
#11 0x000055555577203c in Frecursive_edit () at ../../src/keyboard.c:786
#12 0x000055555576a4a7 in main (argc=2, argv=0x7fffffffd818) at ../../src/emacs.c:2055
(gdb) c
Continuing.

Re: Tabs

[Eli Zaretskii]

> Date: Wed, 9 Oct 2019 15:55:39 +0200
> From: Ergus <spacibba@aol.com>
> Cc: michael_heerdegen@web.de, juri@linkov.net, emacs-devel@gnu.org
> 
> >If you set a breakpoint in this fragment from clear_garbaged_frames:
> >
> >	  if (FRAME_VISIBLE_P (f) && FRAME_GARBAGED_P (f))
> >	    {
> >	      if ((f->resized_p || f->tab_bar_resized)
> >		  /* It makes no sense to redraw a non-selected TTY
> >		     frame, since that will actually clear the
> >		     selected frame, and might leave the selected
> >		     frame with corrupted display, if it happens not
> >		     to be marked garbaged.  */
> >		  && !(f != sf && (FRAME_TERMCAP_P (f) || FRAME_MSDOS_P (f))))
> >		redraw_frame (f);  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> >	      else
> >		clear_current_matrices (f);
> >
> >does the breakpoint fire after you type "C-x 6 f"?
> 
> Yes:
> 
> Thread 1 "emacs" hit Breakpoint 1, clear_garbaged_frames () at ../../src/xdisp.c:11805
> 11805                   redraw_frame (f);

So you are saying that the call to redraw_frame does nothing in your
case?  It's supposed to clear out the entire X window and then cause
its redisplay...

What about disabling double buffering, does it help in any way?

And what about the question I asked earlier about the last master
build you had that didn't have this problem? do you have an answer?

TIA.

Anyway, Juri, I'm at the end of my wits (which evidently are too short
to begin with) regarding this problem.  It is bad enough to have to
debug this without being able to reproduce the problem on my machine,
and in addition, I don't have a clear understanding how this is
supposed to work.  AFAIU, you just copied the code from the tool-bar
code, so it's possible that you don't understand that either.  Maybe
Martin will be able to explain how the tool-bar related flags are
supposed to work, and maybe that will help me see the light.  But I'm
not holding my breath, given that even the call to redraw_frame
doesn't seem to do what it's supposed to.

Do you see the problem described by Jimmy on your system?  If so, are
you able to debug it on your system (with my help, if you need it)?
If not, would someone else who sees the problem please try debugging
it?

Re: Tabs

[Ergus]

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

On Wed, Oct 09, 2019 at 05:21:15PM +0300, Eli Zaretskii wrote:
>> Date: Wed, 9 Oct 2019 15:55:39 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: michael_heerdegen@web.de, juri@linkov.net, emacs-devel@gnu.org
>>
>> >If you set a breakpoint in this fragment from clear_garbaged_frames:
>> >
>> >	  if (FRAME_VISIBLE_P (f) && FRAME_GARBAGED_P (f))
>> >	    {
>> >	      if ((f->resized_p || f->tab_bar_resized)
>> >		  /* It makes no sense to redraw a non-selected TTY
>> >		     frame, since that will actually clear the
>> >		     selected frame, and might leave the selected
>> >		     frame with corrupted display, if it happens not
>> >		     to be marked garbaged.  */
>> >		  && !(f != sf && (FRAME_TERMCAP_P (f) || FRAME_MSDOS_P (f))))
>> >		redraw_frame (f);  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>> >	      else
>> >		clear_current_matrices (f);
>> >
>> >does the breakpoint fire after you type "C-x 6 f"?
>>
>> Yes:
>>
>> Thread 1 "emacs" hit Breakpoint 1, clear_garbaged_frames () at ../../src/xdisp.c:11805
>> 11805                   redraw_frame (f);
>
>So you are saying that the call to redraw_frame does nothing in your
>case?  It's supposed to clear out the entire X window and then cause
>its redisplay...
>
Exactly

>What about disabling double buffering, does it help in any way?
>
The same

>And what about the question I asked earlier about the last master
>build you had that didn't have this problem? do you have an answer?
>
I will look for it now.

>TIA.
>
>Anyway, Juri, I'm at the end of my wits (which evidently are too short
>to begin with) regarding this problem.  It is bad enough to have to
>debug this without being able to reproduce the problem on my machine,
>and in addition, I don't have a clear understanding how this is
>supposed to work.  AFAIU, you just copied the code from the tool-bar
>code, so it's possible that you don't understand that either.  Maybe
>Martin will be able to explain how the tool-bar related flags are
>supposed to work, and maybe that will help me see the light.  But I'm
>not holding my breath, given that even the call to redraw_frame
>doesn't seem to do what it's supposed to.
>
>Do you see the problem described by Jimmy on your system?  If so, are
>you able to debug it on your system (with my help, if you need it)?
>If not, would someone else who sees the problem please try debugging
>it?

This seems to be related with an optimization in redisplay as you said
because sometimes when I get the broken tab-bar if I scroll with the
mouse the bar scrolls too. (attached picture.) This happens with and
without double buffering.

[-- Attachment #2: Screenshot_2019-10-09_17-08-58.png --]
[-- Type: image/png, Size: 157686 bytes --]

Re: Tabs

[Eli Zaretskii]

> Date: Wed, 9 Oct 2019 17:15:05 +0200
> From: Ergus <spacibba@aol.com>
> Cc: juri@linkov.net, michael_heerdegen@web.de, emacs-devel@gnu.org
> 
> This seems to be related with an optimization in redisplay as you said
> because sometimes when I get the broken tab-bar if I scroll with the
> mouse the bar scrolls too.

Emacs doesn't understand that this part of the display is taken by the
tab bar, it thinks that it's part of some window's text area.  The
question is: why does the display engine fail to realize that, given
what we do when "C-x 6 f" turns on tab-bar-mode?

Re: Tabs

[Eli Zaretskii]

Please try the latest master, I made a change which could potentially
affect the issue.

Re: Tabs

[Ergus]

Hi Eli:

It seems to be working fine now !!!! I will try a bit more latter
(Because paradoxically I don't actually use gui interface myself). But
so far it seems to be working fine now.

Very thanks.
Ergus

On Thu, Oct 10, 2019 at 02:52:36PM +0300, Eli Zaretskii wrote:
>Please try the latest master, I made a change which could potentially
>affect the issue.
>

Re: Tabs

[Eli Zaretskii]

> Date: Thu, 10 Oct 2019 15:12:32 +0200
> From: Ergus <spacibba@aol.com>
> Cc: juri@linkov.net, emacs-devel@gnu.org
> 
> It seems to be working fine now !!!! I will try a bit more latter
> (Because paradoxically I don't actually use gui interface myself). But
> so far it seems to be working fine now.

Thanks.  If that change fixed the issue, it's by sheer luck...

Moreover, if I set frame-inhibit-implied-resize to nil, as it was in
your build before that change, I still don't see the problem on my
system...

If you eval (setq frame-inhibit-implied-resize nil) right after
entering "emacs -Q", and then invoke "C-x 6 f", do you see the problem
again?

Re: Tabs

[Ergus]

On Thu, Oct 10, 2019 at 04:54:29PM +0300, Eli Zaretskii wrote:
>> Date: Thu, 10 Oct 2019 15:12:32 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: juri@linkov.net, emacs-devel@gnu.org
>>
>> It seems to be working fine now !!!! I will try a bit more latter
>> (Because paradoxically I don't actually use gui interface myself). But
>> so far it seems to be working fine now.
>
>Thanks.  If that change fixed the issue, it's by sheer luck...
>
>Moreover, if I set frame-inhibit-implied-resize to nil, as it was in
>your build before that change, I still don't see the problem on my
>system...
>
>If you eval (setq frame-inhibit-implied-resize nil) right after
>entering "emacs -Q", and then invoke "C-x 6 f", do you see the problem
>again?

Yes. Exactly as before. 

Re: Tabs

[Eli Zaretskii]

> Date: Thu, 10 Oct 2019 16:19:37 +0200
> From: Ergus <spacibba@aol.com>
> Cc: juri@linkov.net, emacs-devel@gnu.org
> 
> >If you eval (setq frame-inhibit-implied-resize nil) right after
> >entering "emacs -Q", and then invoke "C-x 6 f", do you see the problem
> >again?
> 
> Yes. Exactly as before. 

Thanks.

Martin, any ideas how this could contribute to the problem?

Re: Tabs

[martin rudalics]

 > Martin, any ideas how this could contribute to the problem?

I suppose with problem you mean Ergus' "hole in the beginning".  The
only cause for this I can think of is the apply_window_adjustment call
you mentioned earlier.  And maybe some omission in the GTK build due
to the fact that Juri somehow merged the tool bar widget and Emacs
windows concepts.

Ergus, does the "hole" also show up when you disable the tool bar
before doing C-x 6 f?

martin

Re: Tabs

[Ergus]

On Thu, Oct 10, 2019 at 05:35:56PM +0200, martin rudalics wrote:
>> Martin, any ideas how this could contribute to the problem?
>
>I suppose with problem you mean Ergus' "hole in the beginning".  The
>only cause for this I can think of is the apply_window_adjustment call
>you mentioned earlier.  And maybe some omission in the GTK build due
>to the fact that Juri somehow merged the tool bar widget and Emacs
>windows concepts.
>
>Ergus, does the "hole" also show up when you disable the tool bar
>before doing C-x 6 f?
>
>martin

Hi Martin:

Actually the hole is not the issue anymore. The problem was (before the
latest Eli's change):

1) C-x 6 f file RET does not show any tab-bar/tab.
2) Leaving the desktop and returning made the tab-bar visible, but
 2.1) It was not clickable,
 2.2) Overlapped text in the first text line.
 2.3) The cursor was also there.
 2.4) Moving the cursor "erased" the tab exposing the text line under
 it.
 2.5) Scrolling the text also scrolled part of the tab-bar.

I sent pictures of all these issues since Tuesday.

Re: Tabs

[martin rudalics]

 > Actually the hole is not the issue anymore. The problem was (before the
 > latest Eli's change):
 >
 > 1) C-x 6 f file RET does not show any tab-bar/tab.
 > 2) Leaving the desktop and returning made the tab-bar visible, but
 > 2.1) It was not clickable,
 > 2.2) Overlapped text in the first text line.
 > 2.3) The cursor was also there.
 > 2.4) Moving the cursor "erased" the tab exposing the text line under
 > it.
 > 2.5) Scrolling the text also scrolled part of the tab-bar.
 >
 > I sent pictures of all these issues since Tuesday.

The only picture I have is Screenshot_2019-10-09_17-08-58.png.  Is
that the one you mean?  Are you sure that you are on an unmodified
master?  And did you try turning off the tool bar?  The 'dired' icon
there looks unduly large IMHO.  And finally: Did you try building
without widgets, xft and modules?

martin

Re: Tabs

[Eli Zaretskii]

> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 10 Oct 2019 20:14:39 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, juri@linkov.net, emacs-devel@gnu.org
> 
>  > 1) C-x 6 f file RET does not show any tab-bar/tab.
>  > 2) Leaving the desktop and returning made the tab-bar visible, but
>  > 2.1) It was not clickable,
>  > 2.2) Overlapped text in the first text line.
>  > 2.3) The cursor was also there.
>  > 2.4) Moving the cursor "erased" the tab exposing the text line under
>  > it.

The screenshots for this are shown here:

  https://lists.gnu.org/archive/html/emacs-devel/2019-10/msg00324.html
  https://lists.gnu.org/archive/html/emacs-devel/2019-10/msg00345.html

>  > 2.5) Scrolling the text also scrolled part of the tab-bar.

The screenshot for this is shown here:

  https://lists.gnu.org/archive/html/emacs-devel/2019-10/msg00368.html


> The only picture I have is Screenshot_2019-10-09_17-08-58.png.  Is
> that the one you mean?

That's the last one above.

Re: Tabs

[martin rudalics]

 > The screenshots for this are shown here:
 >
 >    https://lists.gnu.org/archive/html/emacs-devel/2019-10/msg00324.html
 >    https://lists.gnu.org/archive/html/emacs-devel/2019-10/msg00345.html
 >
 >>   > 2.5) Scrolling the text also scrolled part of the tab-bar.
 >
 > The screenshot for this is shown here:
 >
 >    https://lists.gnu.org/archive/html/emacs-devel/2019-10/msg00368.html
 >
 >
 >> The only picture I have is Screenshot_2019-10-09_17-08-58.png.  Is
 >> that the one you mean?
 >
 > That's the last one above.

Thanks.  I still don't have the slightest clue what might cause these.
I can't imagine that any geometric miscalculation on our side would be
the culprit, these should be seen by others as well.  Could we get
some sort of summary which kinds of problems people see with all sorts
of GUI builds of latest master so that I can try to reproduce at least
something here?

TIA, martin

Re: Tabs

[Eli Zaretskii]

> Cc: spacibba@aol.com, emacs-devel@gnu.org, juri@linkov.net
> From: martin rudalics <rudalics@gmx.at>
> Date: Fri, 11 Oct 2019 10:18:53 +0200
> 
>  > The screenshots for this are shown here:
>  >
>  >    https://lists.gnu.org/archive/html/emacs-devel/2019-10/msg00324.html
>  >    https://lists.gnu.org/archive/html/emacs-devel/2019-10/msg00345.html
>  >
>  >>   > 2.5) Scrolling the text also scrolled part of the tab-bar.
>  >
>  > The screenshot for this is shown here:
>  >
>  >    https://lists.gnu.org/archive/html/emacs-devel/2019-10/msg00368.html
>  >
>  >
>  >> The only picture I have is Screenshot_2019-10-09_17-08-58.png.  Is
>  >> that the one you mean?
>  >
>  > That's the last one above.
> 
> Thanks.  I still don't have the slightest clue what might cause these.

Given that changing the default for frame-inhibit-implied-resize fixed
the problem, and setting it to the previous default recreates it, I'd
suspect something done in x_change_tab_bar_height (and/or its sibling
for GTK).

Re: Tabs

[martin rudalics]

 >> If you eval (setq frame-inhibit-implied-resize nil) right after
 >> entering "emacs -Q", and then invoke "C-x 6 f", do you see the problem
 >> again?
 >
 > Yes. Exactly as before.

Please try again.  This should have been fixed now.

Thanks, martin

Re: Tabs

[Ergus]

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

BTW: At some point during the latest changes there was a change in the
tui tabs?? They where made as text mode before, but now they are
graphical tabs over the terminal (picture attached)... was this
intentional?



On Thu, Oct 10, 2019 at 02:52:36PM +0300, Eli Zaretskii wrote:
>Please try the latest master, I made a change which could potentially
>affect the issue.
>

[-- Attachment #2: Screenshot_2019-10-10_15-21-07.png --]
[-- Type: image/png, Size: 16639 bytes --]

Re: Tabs

[Eli Zaretskii]

> Date: Thu, 10 Oct 2019 15:29:31 +0200
> From: Ergus <spacibba@aol.com>
> Cc: juri@linkov.net, emacs-devel@gnu.org
> 
> BTW: At some point during the latest changes there was a change in the
> tui tabs?? They where made as text mode before, but now they are
> graphical tabs over the terminal (picture attached)...

They aren't graphical, they are still text.  Emacs cannot display
graphics on TTY frames.

Re: Tabs

[Ergus]

On Thu, Oct 10, 2019 at 04:47:57PM +0300, Eli Zaretskii wrote:
>> Date: Thu, 10 Oct 2019 15:29:31 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: juri@linkov.net, emacs-devel@gnu.org
>>
>> BTW: At some point during the latest changes there was a change in the
>> tui tabs?? They where made as text mode before, but now they are
>> graphical tabs over the terminal (picture attached)...
>
>They aren't graphical, they are still text.  Emacs cannot display
>graphics on TTY frames.
>
Ohh sorry, they looked like gui but it is only a face, now I see it...

I was confused because I didn't see any reference to a tabs face in
the manual. Sorry.

Re: Tabs

[Ergus]

On Thu, Oct 10, 2019 at 04:47:57PM +0300, Eli Zaretskii wrote:
>> Date: Thu, 10 Oct 2019 15:29:31 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: juri@linkov.net, emacs-devel@gnu.org
>>
>> BTW: At some point during the latest changes there was a change in the
>> tui tabs?? They where made as text mode before, but now they are
>> graphical tabs over the terminal (picture attached)...
>
>They aren't graphical, they are still text.  Emacs cannot display
>graphics on TTY frames.
>

I have a non so technical question here. I see that the tab-bar face is
defined completely in the code, but if instead we define it as
inheriting from a more "traditional/standard" face (like tool-bar or
similes) maybe the users that had already configured it will have the
impression of a better integration??.

I mention this because many themes define a toolbar color/font and it
will be needed some time before they also define a tab-bar color, so
when emacs 27 will be released all the users with those themes will have
tabs not matching in their emacs appearance.

Does it makes sense?

Re: Tabs

[Eli Zaretskii]

> Date: Thu, 10 Oct 2019 16:40:56 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org, juri@linkov.net
> 
> I have a non so technical question here. I see that the tab-bar face is
> defined completely in the code, but if instead we define it as
> inheriting from a more "traditional/standard" face (like tool-bar or
> similes) maybe the users that had already configured it will have the
> impression of a better integration??.
> 
> I mention this because many themes define a toolbar color/font and it
> will be needed some time before they also define a tab-bar color, so
> when emacs 27 will be released all the users with those themes will have
> tabs not matching in their emacs appearance.

I think we should simply have a prettier default for the tab-bar
faces.  They are currently too dull, IMNSHO.

Re: Tabs

[Juri Linkov]

>>> BTW: At some point during the latest changes there was a change in the
>>> tui tabs?? They where made as text mode before, but now they are
>>> graphical tabs over the terminal (picture attached)...

The intention was to make text tabs look like gui tabs.
Thanks for confirming that the goal was achieved.

>>They aren't graphical, they are still text.  Emacs cannot display
>>graphics on TTY frames.
>
> I have a non so technical question here. I see that the tab-bar face is
> defined completely in the code, but if instead we define it as
> inheriting from a more "traditional/standard" face (like tool-bar or
> similes) maybe the users that had already configured it will have the
> impression of a better integration??.
>
> I mention this because many themes define a toolbar color/font and it
> will be needed some time before they also define a tab-bar color, so
> when emacs 27 will be released all the users with those themes will have
> tabs not matching in their emacs appearance.
>
> Does it makes sense?

The problem is that by default tool-bar takes its colors from external
resources.  faces.el defines the 'tool-bar' background color as "grey75",
but running 'emacs -q' (lowercase '-q' that loads x-resources) and
visiting the 'tool-bar' face customization via M-x list-faces-display
shows other colors:

   [X] : Foreground: #4a4a4a     Choose   (sample)
   [X] : Background: #f0f0f0     Choose   (sample)

Where does it get #4a4a4a and #f0f0f0?

I tried to run 'xrdb -query | grep -i tool' and the output is:

  Emacs.tool-bar.attributeBackground:	#f0f0f0
  Emacs.tool-bar.attributeForeground:	#4a4a4a

But where these settings come from?

I searched in /etc and found /etc/xrdb/Emacs.ad with:

  Emacs.tool-bar.attributeBackground: BACKGROUND
  Emacs.tool-bar.attributeForeground: FOREGROUND

But there is no "Emacs.tab-bar".  Anyway I already added
reading the "Emacs.tab-bar" resource to x-apply-session-resources
in startup.el, so I guess now maintainers of different distributions
could add it to the list of default X resources.

Re: Tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Thu, 10 Oct 2019 23:54:48 +0300
> 
> Anyway I already added reading the "Emacs.tab-bar" resource to
> x-apply-session-resources in startup.el

I don't see these resources documented, neither in NEWS nor in the
user manual (where we have a special appendix about the resources
Emacs uses).  Please add that, and thanks.

Re: Tabs

[Juri Linkov]

>> Anyway I already added reading the "Emacs.tab-bar" resource to
>> x-apply-session-resources in startup.el
>
> I don't see these resources documented, neither in NEWS nor in the
> user manual (where we have a special appendix about the resources
> Emacs uses).  Please add that, and thanks.

This is added now to NEWS and the user manual.

PS: About providing compatibility with tool-bar customization,
I don't know a good way to use tool-bar colors for tab-bar -
we can't inherit tab-bar face from tool-bar face.

Maybe update tab-bar face attributes explicitly in
'set-face-attribute-from-resource'?  For example, use
'x-get-resource' to get tool-bar background/foreground colors,
and apply these colors to the tab-bar face?

Re: Tabs

[Juri Linkov]

> Do you see the problem described by Jimmy on your system?  If so, are
> you able to debug it on your system (with my help, if you need it)?
> If not, would someone else who sees the problem please try debugging
> it?

It's strange that the problem is not reproducible even when
I tried with exactly the same configuration with gtk3 and
without optimization.

Re: Tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Ergus <spacibba@aol.com>,  michael_heerdegen@web.de,  emacs-devel@gnu.org
> Date: Thu, 10 Oct 2019 01:37:49 +0300
> 
> > Do you see the problem described by Jimmy on your system?  If so, are
> > you able to debug it on your system (with my help, if you need it)?
> > If not, would someone else who sees the problem please try debugging
> > it?
> 
> It's strange that the problem is not reproducible even when
> I tried with exactly the same configuration with gtk3 and
> without optimization.

Do you see it in an optimized build?

Re: Tabs

[Juri Linkov]

>> > Do you see the problem described by Jimmy on your system?  If so, are
>> > you able to debug it on your system (with my help, if you need it)?
>> > If not, would someone else who sees the problem please try debugging
>> > it?
>>
>> It's strange that the problem is not reproducible even when
>> I tried with exactly the same configuration with gtk3 and
>> without optimization.
>
> Do you see it in an optimized build?

I see the same problem after building with

  ./configure --with-x-toolkit=no

However, this patch fixes it.  Please rewrite it,
if you think these #if could be grouped more compactly.

diff --git a/src/frame.c b/src/frame.c
index 099db29598..48f1d02101 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -6308,7 +6308,7 @@ focus (where a frame immediately loses focus when it's left by the mouse
 #elif defined (USE_LUCID) || defined (USE_MOTIF) || defined (HAVE_NTGUI)
   frame_inhibit_implied_resize = list2 (Qtab_bar_lines, Qtool_bar_lines);
 #else
-  frame_inhibit_implied_resize = Qnil;
+  frame_inhibit_implied_resize = list1 (Qtab_bar_lines);
 #endif
 #else
   frame_inhibit_implied_resize = Qt;

Re: Tabs

[martin rudalics]

 >> Do you see it in an optimized build?
 >
 > I see the same problem after building with
 >
 >    ./configure --with-x-toolkit=no

Which is the problem you see here?  C-x 6 f works pretty well in such
builds although I would prefer to (at least customizably) see the tab
bar to appear below the tool bar but that's no great deal.  In either
case, I have no problems with 'frame-inhibit-implied-resize' nil here
in non-toolkit builds, neither with the tab bar nor with the tool bar.

martin

Re: Tabs

[Juri Linkov]

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

>>> Do you see it in an optimized build?
>>
>> I see the same problem after building with
>>
>>    ./configure --with-x-toolkit=no
>
> Which is the problem you see here?  C-x 6 f works pretty well in such
> builds

I see the problem with this test case:

0. emacs -Q
1. C-x t 2
2. C-S-TAB

where switching back to the first tab damages the tool bar
as shown on this screenshot:


[-- Attachment #2: frame-inhibit.png --]
[-- Type: image/png, Size: 15081 bytes --]

[-- Attachment #3: Type: text/plain, Size: 595 bytes --]


So maybe the problem is in set-window-configuration?
(that is used by tab switching)

But changing the default value of frame-inhibit-implied-resize
to '(tab-bar-lines tool-bar-lines)' fixes it.

> although I would prefer to (at least customizably) see the tab
> bar to appear below the tool bar but that's no great deal.

I have no preference, but in web browsers the tab bar is above the tool bar,
and this makes more sense because the tool bar depends more on the buffer so
it should located closer to the buffer, whereas the tab bar refers to elements
higher in the window/frame hierarchy.

Re: Tabs

[martin rudalics]

 > So maybe the problem is in set-window-configuration?
 > (that is used by tab switching)

Presumably so.  A much simpler scenario without tab bars is

(let ((conf (current-window-configuration)))
   (tool-bar-mode -1)
   (set-window-configuration conf))

or on other builds with an internal tool bar (including Windows)

(let ((conf (current-window-configuration))
       (frame-inhibit-implied-resize nil))
   (tool-bar-mode -1)
   (set-window-configuration conf))

This will require some surgery, so don't expect a fix in a few days.

And I have no idea yet whether and how this could affect GTK builds.

 >> although I would prefer to (at least customizably) see the tab
 >> bar to appear below the tool bar but that's no great deal.
 >
 > I have no preference, but in web browsers the tab bar is above the tool bar,

Certainly not in mine (though it took me some effort to fix that).

 > and this makes more sense because the tool bar depends more on the buffer so
 > it should located closer to the buffer, whereas the tab bar refers to elements
 > higher in the window/frame hierarchy.

IIUC, in all other builds we show the tab bar below the tool bar.

martin

Re: Tabs

[martin rudalics]

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

 > This will require some surgery, so don't expect a fix in a few days.
 >
 > And I have no idea yet whether and how this could affect GTK builds.

The forensics (informal):

(1) Suppose you have a frame with a visible tab-bar (and no other
     pseudo window) and save its window configuration.  In the saved
     configuration, the root window is at a line 3.

(2) You disable the tab-bar.  The root window is now at line 0.

(3) You restore the configuration saved in (1).  The root window is at
     line 2 again.  Now adjust_frame_size kicks in.  And this one had
     the optimization to do almost nothing in the most frequent case
     where

       && new_text_width == old_text_width
       && new_text_height == old_text_height
       && new_windows_width == old_windows_width
       && new_windows_height == old_windows_height
       && new_pixel_width == old_pixel_width
       && new_pixel_height == old_pixel_height
       && new_cols == old_cols
       && new_lines == old_lines)
     /* No change.  Sanitize window sizes and return.  */

    hold.  Unfortunately, in our case all of these miraculously do
    hold, apparently nothing changed.

The reason for this is the 'frame-inhibit-implied-resize' nil setting.
When (2) removes the tab bar from the frame this sets all these sizes
(which later here appear as old_...) to the sizes of the saved window
configuration (which appear here as new_...) and we have a frame where
the root window remains at line 3 and its bottom is cut off.

I attach a patch for this.  Please carefully check all builds with
'frame-inhibit-implied-resize' nil for whether they DTRT now (and
obviously the GTK build is affected too since the tab-bar is now its
first internal window).

martin

PS: I noticed two annoying things about tab-bar - it (1) usurpates my
private <C-tab> binding even after I turned it off and (2) apparently
turns off 'truncate-lines' (always t here) in the buffer from where I
invoked it.  Finally, I can't make tab-bar work on Windows any more
always getting something like

Debugger entered--Lisp error: (wrong-type-argument sequencep #<buffer *Messages*>)
   #f(compiled-function (tab) #<bytecode 0x1d723d1>)((current-tab (name . #<buffer *Messages*>)))
   mapcan(#f(compiled-function (tab) #<bytecode 0x1d723d1>) ((current-tab (name . #<buffer *Messages*>))))
   tab-bar-make-keymap-1()
   tab-bar-make-keymap(ignore)
   redisplay_internal\ \(C\ function\)()
   redisplay()
   sit-for(2)
   execute-extended-command(nil "tab-bar-mode" "tab-bar-mode")
   funcall-interactively(execute-extended-command nil "tab-bar-mode" "tab-bar-mode")
   call-interactively(execute-extended-command nil nil)
   command-execute(execute-extended-command)

Any ideas?

[-- Attachment #2: adjust_frame_size.diffs --]
[-- Type: text/plain, Size: 1612 bytes --]

diff --git a/src/frame.c b/src/frame.c
index f7e65be727..4dd181f6a9 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -704,18 +704,17 @@ adjust_frame_size (struct frame *f, int new_width, int new_height, int inhibit,
 		inhibit_vertical ? Qt : Qnil));
 
       if (FRAME_TERMINAL (f)->set_window_size_hook)
-        FRAME_TERMINAL (f)->set_window_size_hook (f,
-                                                  0,
-                                                  new_text_width,
-                                                  new_text_height,
-                                                  1);
+        FRAME_TERMINAL (f)->set_window_size_hook
+	  (f, 0, new_text_width, new_text_height, 1);
       f->resized_p = true;
 
       return;
     }
 #endif
 
-  if (new_text_width == old_text_width
+  if ((XWINDOW (FRAME_ROOT_WINDOW (f))->pixel_top
+       == FRAME_TOP_MARGIN_HEIGHT (f))
+      && new_text_width == old_text_width
       && new_text_height == old_text_height
       && new_windows_width == old_windows_width
       && new_windows_height == old_windows_height
diff --git a/src/window.c b/src/window.c
index ba9af3b9b0..7d70c9b002 100644
--- a/src/window.c
+++ b/src/window.c
@@ -7132,7 +7132,7 @@ the return value is nil.  Otherwise the value is t.  */)
       /* Allow set_window_size_hook again and apply frame size changes
 	 if needed.  */
       f->can_set_window_size = true;
-      adjust_frame_size (f, -1, -1, 1, false, Qset_window_configuration);
+      adjust_frame_size (f, -1, -1, 4, false, Qset_window_configuration);
 
       adjust_frame_glyphs (f);
       unblock_input ();

Re: Tabs

[Eli Zaretskii]

> From: martin rudalics <rudalics@gmx.at>
> Cc: michael_heerdegen@web.de, Eli Zaretskii <eliz@gnu.org>, spacibba@aol.com,
>  emacs-devel@gnu.org
> Date: Mon, 14 Oct 2019 20:02:57 +0200
> 
> PS: I noticed two annoying things about tab-bar - it (1) usurpates my
> private <C-tab> binding even after I turned it off and (2) apparently
> turns off 'truncate-lines' (always t here) in the buffer from where I
> invoked it.  Finally, I can't make tab-bar work on Windows any more
> always getting something like
> 
> Debugger entered--Lisp error: (wrong-type-argument sequencep #<buffer *Messages*>)

None if this happens here with the latest master.

Re: Tabs

[martin rudalics]

 >> PS: I noticed two annoying things about tab-bar - it (1) usurpates my
 >> private <C-tab> binding even after I turned it off and

This one still does happen here.  But maybe there's nothing that can
be done about this.

 > (2) apparently
 >> turns off 'truncate-lines' (always t here) in the buffer from where I
 >> invoked it.

This doesn't seem to happen any more.

Finally, I can't make tab-bar work on Windows any more
 >> always getting something like
 >>
 >> Debugger entered--Lisp error: (wrong-type-argument sequencep #<buffer *Messages*>)

This one has been fixed.

 > None if this happens here with the latest master.

martin

Re: Tabs

[Juri Linkov]

> PS: I noticed two annoying things about tab-bar - it

> (1) usurpates my private <C-tab> binding even after I turned it off

Do you think after turning off, it should just unbind <C-tab>,
or restore a previous binding, or when turning it on to check
if there is already <C-tab> bound and don't override
the existing binding?

> (2) apparently turns off 'truncate-lines' (always t here) in the
> buffer from where I invoked it.

This is something new, it should not affect 'truncate-lines'.

> Finally, I can't make tab-bar work on Windows any more always getting something like
> Debugger entered--Lisp error: (wrong-type-argument sequencep #<buffer *Messages*>)

This was fixed recently.

Re: Tabs

[T.V Raman]

Juri Linkov <juri@linkov.net> writes:

One additional thought on keybindings, at present, when running under X,
C-1 ..C-0 all run "digit-argument" and there are other ways to supply
that -- from myself, I never have used c-1 etc for digit argument. Could
we perhaps use C-1 .. to jump to a tab by index?>> PS: I noticed two annoying things about tab-bar - it
>
>> (1) usurpates my private <C-tab> binding even after I turned it off
>
> Do you think after turning off, it should just unbind <C-tab>,
> or restore a previous binding, or when turning it on to check
> if there is already <C-tab> bound and don't override
> the existing binding?
>
>> (2) apparently turns off 'truncate-lines' (always t here) in the
>> buffer from where I invoked it.
>
> This is something new, it should not affect 'truncate-lines'.
>
>> Finally, I can't make tab-bar work on Windows any more always getting something like
>> Debugger entered--Lisp error: (wrong-type-argument sequencep #<buffer *Messages*>)
>
> This was fixed recently.
>

-- 
Id: kg:/m/0285kf1 

Re: Tabs

[Phil Sainty]

On 2019-10-15 10:17, T.V Raman wrote:
> One additional thought on keybindings, at present, when running under 
> X,
> C-1 ..C-0 all run "digit-argument" and there are other ways to supply
> that -- from myself, I never have used c-1 etc for digit argument. 
> Could
> we perhaps use C-1 .. to jump to a tab by index?

The C-0 to 9 and M-0 to 9 sets of `digit-argument' bindings are *both*
useful, because sometimes you'll be following the numeric arg with a
Ctrl-modified key, and sometimes you'll follow it with a Meta-modified
key, and simply holding down the same modifier throughout makes the
sequence easier to type, vs having to switch modifiers in the middle.

As such, I don't think clobbering those should be a default; but it 
could
certainly be an option.

Perhaps it could be done similarly to `windmove-default-keybindings',
where the user can trivially choose the modifier key to use.


-Phil

Re: Tabs

[Juri Linkov]

>> One additional thought on keybindings, at present, when running under X,
>> C-1 ..C-0 all run "digit-argument" and there are other ways to supply
>> that -- from myself, I never have used c-1 etc for digit argument. Could
>> we perhaps use C-1 .. to jump to a tab by index?
>
> The C-0 to 9 and M-0 to 9 sets of `digit-argument' bindings are *both*
> useful, because sometimes you'll be following the numeric arg with a
> Ctrl-modified key, and sometimes you'll follow it with a Meta-modified
> key, and simply holding down the same modifier throughout makes the
> sequence easier to type, vs having to switch modifiers in the middle.
>
> As such, I don't think clobbering those should be a default; but it could
> certainly be an option.
>
> Perhaps it could be done similarly to `windmove-default-keybindings',
> where the user can trivially choose the modifier key to use.

Currently I'm using the hard-coded modifier

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

but making it customizable is a good idea.

What modifier we could set as the default value?

Re: Tabs

[T.V Raman]

Hard to pick defaults in emacs, everyone will have a prefered default:-)
Juri Linkov writes:
 > >> One additional thought on keybindings, at present, when running under X,
 > >> C-1 ..C-0 all run "digit-argument" and there are other ways to supply
 > >> that -- from myself, I never have used c-1 etc for digit argument. Could
 > >> we perhaps use C-1 .. to jump to a tab by index?
 > >
 > > The C-0 to 9 and M-0 to 9 sets of `digit-argument' bindings are *both*
 > > useful, because sometimes you'll be following the numeric arg with a
 > > Ctrl-modified key, and sometimes you'll follow it with a Meta-modified
 > > key, and simply holding down the same modifier throughout makes the
 > > sequence easier to type, vs having to switch modifiers in the middle.
 > >
 > > As such, I don't think clobbering those should be a default; but it could
 > > certainly be an option.
 > >
 > > Perhaps it could be done similarly to `windmove-default-keybindings',
 > > where the user can trivially choose the modifier key to use.
 > 
 > Currently I'm using the hard-coded modifier
 > 
 >   (dotimes (i 9)
 >     (global-set-key (vector (list 'super (+ i 1 ?0)))
 >                     'tab-bar-select-tab))
 > 
 > but making it customizable is a good idea.
 > 
 > What modifier we could set as the default value?

-- 
Id: kg:/m/0285kf1 

-- 
Id: kg:/m/0285kf1 

Re: Tabs

[Juri Linkov]

> Hard to pick defaults in emacs, everyone will have a prefered default :-)

So now the new option tab-bar-select-tab-modifiers has no default.
It allows selecting a set of modifiers such as Ctrl or Meta.

>  > >> One additional thought on keybindings, at present, when running under X,
>  > >> C-1 ..C-0 all run "digit-argument" and there are other ways to supply
>  > >> that -- from myself, I never have used c-1 etc for digit argument. Could
>  > >> we perhaps use C-1 .. to jump to a tab by index?
>  > >
>  > > The C-0 to 9 and M-0 to 9 sets of `digit-argument' bindings are *both*
>  > > useful, because sometimes you'll be following the numeric arg with a
>  > > Ctrl-modified key, and sometimes you'll follow it with a Meta-modified
>  > > key, and simply holding down the same modifier throughout makes the
>  > > sequence easier to type, vs having to switch modifiers in the middle.
>  > >
>  > > As such, I don't think clobbering those should be a default; but it could
>  > > certainly be an option.
>  > >
>  > > Perhaps it could be done similarly to `windmove-default-keybindings',
>  > > where the user can trivially choose the modifier key to use.
>  > 
>  > Currently I'm using the hard-coded modifier
>  > 
>  >   (dotimes (i 9)
>  >     (global-set-key (vector (list 'super (+ i 1 ?0)))
>  >                     'tab-bar-select-tab))
>  > 
>  > but making it customizable is a good idea.
>  > 
>  > What modifier we could set as the default value?

Re: Tabs

[T.V Raman]

Juri Linkov <juri@linkov.net> writes:


Nice, works well for me (set it to control)
>> Hard to pick defaults in emacs, everyone will have a prefered default :-)
>
> So now the new option tab-bar-select-tab-modifiers has no default.
> It allows selecting a set of modifiers such as Ctrl or Meta.
>
>>  > >> One additional thought on keybindings, at present, when running under X,
>>  > >> C-1 ..C-0 all run "digit-argument" and there are other ways to supply
>>  > >> that -- from myself, I never have used c-1 etc for digit argument. Could
>>  > >> we perhaps use C-1 .. to jump to a tab by index?
>>  > >
>>  > > The C-0 to 9 and M-0 to 9 sets of `digit-argument' bindings are *both*
>>  > > useful, because sometimes you'll be following the numeric arg with a
>>  > > Ctrl-modified key, and sometimes you'll follow it with a Meta-modified
>>  > > key, and simply holding down the same modifier throughout makes the
>>  > > sequence easier to type, vs having to switch modifiers in the middle.
>>  > >
>>  > > As such, I don't think clobbering those should be a default; but it could
>>  > > certainly be an option.
>>  > >
>>  > > Perhaps it could be done similarly to `windmove-default-keybindings',
>>  > > where the user can trivially choose the modifier key to use.
>>  > 
>>  > Currently I'm using the hard-coded modifier
>>  > 
>>  >   (dotimes (i 9)
>>  >     (global-set-key (vector (list 'super (+ i 1 ?0)))
>>  >                     'tab-bar-select-tab))
>>  > 
>>  > but making it customizable is a good idea.
>>  > 
>>  > What modifier we could set as the default value?
>

-- 

Re: Tabs

[Eli Zaretskii]

> From: "T.V Raman" <raman@google.com>
> Cc: martin rudalics <rudalics@gmx.at>,  michael_heerdegen@web.de,  Eli
>  Zaretskii <eliz@gnu.org>,  spacibba@aol.com,  emacs-devel@gnu.org
> Date: Mon, 14 Oct 2019 14:17:02 -0700
> 
> One additional thought on keybindings, at present, when running under X,
> C-1 ..C-0 all run "digit-argument" and there are other ways to supply
> that -- from myself, I never have used c-1 etc for digit argument. Could
> we perhaps use C-1 .. to jump to a tab by index?

That cannot be done by default, since C-1 etc. are very old bindings;
we cannot break them just like that.

Re: Tabs

[martin rudalics]

 >> (1) usurpates my private <C-tab> binding even after I turned it off
 >
 > Do you think after turning off, it should just unbind <C-tab>,
 > or restore a previous binding, or when turning it on to check
 > if there is already <C-tab> bound and don't override
 > the existing binding?

Either restore a previous binding or don't override the existing
binding.  I think that, as a rule, the latter is preferable when
rebinding such fairly popular keys as say <C-tab>.

 >> (2) apparently turns off 'truncate-lines' (always t here) in the
 >> buffer from where I invoked it.
 >
 > This is something new, it should not affect 'truncate-lines'.

It didn't happen again.  Maybe a consequence of the below error.

 >> Finally, I can't make tab-bar work on Windows any more always getting something like
 >> Debugger entered--Lisp error: (wrong-type-argument sequencep #<buffer *Messages*>)
 >
 > This was fixed recently.

Indeed.

Please try the patch I sent you.  'frame-inhibit-implied-resize' nil
should now behave well with tab bars.

Thanks, martin

Re: Tabs

[Juri Linkov]

> Please try the patch I sent you.  'frame-inhibit-implied-resize' nil
> should now behave well with tab bars.

I tried your patch in non-GTK builds with the tab-bar above and below the
the tool-bar, and in GTK builds, and with 'frame-inhibit-implied-resize' nil
everything works fine, thanks.

Re: Tabs

[martin rudalics]

 > I tried your patch in non-GTK builds with the tab-bar above and below the
 > the tool-bar, and in GTK builds, and with 'frame-inhibit-implied-resize' nil
 > everything works fine, thanks.

OK, installed.

Thanks for checking, martin

Re: Tabs

[Juri Linkov]

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

>>> although I would prefer to (at least customizably) see the tab
>>> bar to appear below the tool bar but that's no great deal.
>>
>> I have no preference, but in web browsers the tab bar is above the tool bar,
>
> Certainly not in mine (though it took me some effort to fix that).
>
>> and this makes more sense because the tool bar depends more on the buffer so
>> it should located closer to the buffer, whereas the tab bar refers to elements
>> higher in the window/frame hierarchy.
>
> IIUC, in all other builds we show the tab bar below the tool bar.

Now I implemented the option to show the tab bar below the tool bar:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: tab-bar-position.patch --]
[-- Type: text/x-diff, Size: 2697 bytes --]

diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index 89a96a9f51..85273a2d2a 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -591,6 +591,12 @@ minibuffer-prompt-properties--setter
 		      (const :tag "Text-image-horiz" :value text-image-horiz)
 		      (const :tag "System default" :value nil)) "24.1")
              (tool-bar-max-label-size frames integer "24.1")
+             (tab-bar-position tab-bar boolean "27.1"
+                               :set (lambda (sym val)
+                                     (set-default sym val)
+                                     ;; Redraw the bars:
+                                     (tab-bar-mode -1)
+                                     (tab-bar-mode 1)))
 	     (auto-hscroll-mode scrolling
                                 (choice
                                  (const :tag "Don't scroll automatically"
diff --git a/src/dispnew.c b/src/dispnew.c
index 4dd5ee2a1e..4cdc76f5bc 100644
--- a/src/dispnew.c
+++ b/src/dispnew.c
@@ -2166,8 +2166,10 @@ adjust_frame_glyphs_for_window_redisplay (struct frame *f)
 
     w->pixel_left = 0;
     w->left_col = 0;
-    w->pixel_top = FRAME_MENU_BAR_HEIGHT (f);
-    w->top_line = FRAME_MENU_BAR_LINES (f);
+    w->pixel_top = FRAME_MENU_BAR_HEIGHT (f)
+      + (!NILP (Vtab_bar_position) ? FRAME_TOOL_BAR_HEIGHT (f) : 0);
+    w->top_line = FRAME_MENU_BAR_LINES (f)
+      + (!NILP (Vtab_bar_position) ? FRAME_TOOL_BAR_LINES (f) : 0);
     w->total_cols = FRAME_TOTAL_COLS (f);
     w->pixel_width = (FRAME_PIXEL_WIDTH (f)
 		       - 2 * FRAME_INTERNAL_BORDER_WIDTH (f));
@@ -2196,8 +2198,10 @@ adjust_frame_glyphs_for_window_redisplay (struct frame *f)
 
     w->pixel_left = 0;
     w->left_col = 0;
-    w->pixel_top = FRAME_MENU_BAR_HEIGHT (f) + FRAME_TAB_BAR_HEIGHT (f);
-    w->top_line = FRAME_MENU_BAR_LINES (f) + FRAME_TAB_BAR_LINES (f);
+    w->pixel_top = FRAME_MENU_BAR_HEIGHT (f)
+      + (NILP (Vtab_bar_position) ? FRAME_TAB_BAR_HEIGHT (f) : 0);
+    w->top_line = FRAME_MENU_BAR_LINES (f)
+      + (NILP (Vtab_bar_position) ? FRAME_TAB_BAR_LINES (f) : 0);
     w->total_cols = FRAME_TOTAL_COLS (f);
     w->pixel_width = (FRAME_PIXEL_WIDTH (f)
 		       - 2 * FRAME_INTERNAL_BORDER_WIDTH (f));
@@ -6569,6 +6573,11 @@ syms_of_display (void)
      beginning of the next redisplay).  */
   redisplay_dont_pause = true;
 
+  DEFVAR_LISP ("tab-bar-position", Vtab_bar_position,
+	       doc: /* Specify on which side from the tool bar the tab bar shall be.
+Possible values are `t' (below the tool bar), `nil' (above the tool bar).
+This option affects only builds where the tool bar is not external.  */);
+
   pdumper_do_now_and_after_load (syms_of_display_for_pdumper);
 }
 

Re: Tabs

[martin rudalics]

>> IIUC, in all other builds we show the tab bar below the tool bar.
>
> Now I implemented the option to show the tab bar below the tool bar:

Thanks.  I think you should install it.

martin

Re: Tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: spacibba@aol.com,  michael_heerdegen@web.de,  emacs-devel@gnu.org
> Date: Fri, 11 Oct 2019 01:35:03 +0300
> 
> I see the same problem after building with
> 
>   ./configure --with-x-toolkit=no
> 
> However, this patch fixes it.  Please rewrite it,
> if you think these #if could be grouped more compactly.
> 
> diff --git a/src/frame.c b/src/frame.c
> index 099db29598..48f1d02101 100644
> --- a/src/frame.c
> +++ b/src/frame.c
> @@ -6308,7 +6308,7 @@ focus (where a frame immediately loses focus when it's left by the mouse
>  #elif defined (USE_LUCID) || defined (USE_MOTIF) || defined (HAVE_NTGUI)
>    frame_inhibit_implied_resize = list2 (Qtab_bar_lines, Qtool_bar_lines);
>  #else
> -  frame_inhibit_implied_resize = Qnil;
> +  frame_inhibit_implied_resize = list1 (Qtab_bar_lines);
>  #endif
>  #else
>    frame_inhibit_implied_resize = Qt;

Please install the change.  We still need to understand why this
default has any effect on the issue, but that's a separate discussion.

Re: Tabs

[Juri Linkov]

>> @@ -6308,7 +6308,7 @@ focus (where a frame immediately loses focus when it's left by the mouse
>>  #elif defined (USE_LUCID) || defined (USE_MOTIF) || defined (HAVE_NTGUI)
>>    frame_inhibit_implied_resize = list2 (Qtab_bar_lines, Qtool_bar_lines);
>>  #else
>> -  frame_inhibit_implied_resize = Qnil;
>> +  frame_inhibit_implied_resize = list1 (Qtab_bar_lines);
>>  #endif
>>  #else
>>    frame_inhibit_implied_resize = Qt;
>
> Please install the change.  We still need to understand why this
> default has any effect on the issue, but that's a separate discussion.

Actually I don't understand why the no-toolkit case should differ from
Lucid, Motif, Windows?  They all have non-external tool-bar and tab-bar.
Only GTK+ has an external tool-bar, so 'tool-bar-lines' is not included
in its default value.

Is this a more correct patch?  It uses '(tab-bar-lines tool-bar-lines)'
in the no-toolkit case as well:

diff --git a/src/frame.c b/src/frame.c
index 099db29598..fba1ed8970 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -6292,12 +6292,11 @@ focus (where a frame immediately loses focus when it's left by the mouse
 
 The default value is \\='(tab-bar-lines) in GTK+, (which means that
 adding/removing a tab bar does not change the frame height),
-\\='(tab-bar-lines tool-bar-lines) on Lucid, Motif and Windows
-\(which means that adding/removing a tool bar or tab bar does not
-change the frame height), nil on all other window systems (which
-means that changing any of the parameters listed above may change
-the size of the frame), and t otherwise (which means the frame size
-never changes implicitly when there's no window system support).
+\\='(tab-bar-lines tool-bar-lines) on Lucid, Motif, Windows and on all
+other window systems (which means that adding/removing a tool bar or
+tab bar does not change the frame height), and t otherwise (which
+means the frame size never changes implicitly when there's no window
+system support).
 
 Note that when a frame is not large enough to accommodate a change of
 any of the parameters listed above, Emacs may try to enlarge the frame
@@ -6305,10 +6304,8 @@ focus (where a frame immediately loses focus when it's left by the mouse
 #if defined (HAVE_WINDOW_SYSTEM)
 #if defined USE_GTK
   frame_inhibit_implied_resize = list1 (Qtab_bar_lines);
-#elif defined (USE_LUCID) || defined (USE_MOTIF) || defined (HAVE_NTGUI)
+#else
   frame_inhibit_implied_resize = list2 (Qtab_bar_lines, Qtool_bar_lines);
-#else
-  frame_inhibit_implied_resize = Qnil;
 #endif
 #else
   frame_inhibit_implied_resize = Qt;

Re: Tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: spacibba@aol.com,  michael_heerdegen@web.de,  emacs-devel@gnu.org
> Date: Sun, 13 Oct 2019 01:47:20 +0300
> 
> Actually I don't understand why the no-toolkit case should differ from
> Lucid, Motif, Windows?  They all have non-external tool-bar and tab-bar.

It's been a while since I last used the non-toolkit X build of Emacs.
I thought it had no tool bar.  If it does, then I think you are right.

> Only GTK+ has an external tool-bar

I think NS has an external tool bar as well, no?

> +\\='(tab-bar-lines tool-bar-lines) on Lucid, Motif, Windows and on all
> +other window systems (which means that adding/removing a tool bar or

Instead of enumerating the toolkits, I'd simply say

  on all other types of GUI frames

(but note my reference to NS above).

Thanks.

Re: Tabs

[Juri Linkov]

>> Actually I don't understand why the no-toolkit case should differ from
>> Lucid, Motif, Windows?  They all have non-external tool-bar and tab-bar.
>
> It's been a while since I last used the non-toolkit X build of Emacs.
> I thought it had no tool bar.  If it does, then I think you are right.
>
>> Only GTK+ has an external tool-bar
>
> I think NS has an external tool bar as well, no?

NS has an external tool bar and no tab bar,
so its default value is nil.

>> +\\='(tab-bar-lines tool-bar-lines) on Lucid, Motif, Windows and on all
>> +other window systems (which means that adding/removing a tool bar or
>
> Instead of enumerating the toolkits, I'd simply say
>
>   on all other types of GUI frames
>
> (but note my reference to NS above).

Fixed.

Re: Tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: spacibba@aol.com,  michael_heerdegen@web.de,  emacs-devel@gnu.org
> Date: Sun, 13 Oct 2019 23:48:37 +0300
> 
> >> Only GTK+ has an external tool-bar
> >
> > I think NS has an external tool bar as well, no?
> 
> NS has an external tool bar and no tab bar,

But that's temporary, at least we hope so, right?

> so its default value is nil.

Why not make it identical to GTK?

Re: Tabs

[Juri Linkov]

>> >> Only GTK+ has an external tool-bar
>> >
>> > I think NS has an external tool bar as well, no?
>> 
>> NS has an external tool bar and no tab bar,
>
> But that's temporary, at least we hope so, right?

Right, we need to find a macOS developer who likes tabs enough
to implement NS tab-bar :-)

>> so its default value is nil.
>
> Why not make it identical to GTK?

Because then I don't know how to explain in the docstring
why NS has the default value 'tab-bar-lines'.  This is
how the docstring would look in this case:

  In GTK+ and NS that use the external tool bar, the default value is
  \\='(tab-bar-lines) which means that adding/removing a tab bar does
  not change the frame height.

Re: Tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: spacibba@aol.com,  michael_heerdegen@web.de,  emacs-devel@gnu.org
> Date: Mon, 14 Oct 2019 00:33:47 +0300
> 
> > Why not make it identical to GTK?
> 
> Because then I don't know how to explain in the docstring
> why NS has the default value 'tab-bar-lines'.  This is
> how the docstring would look in this case:
> 
>   In GTK+ and NS that use the external tool bar, the default value is
>   \\='(tab-bar-lines) which means that adding/removing a tab bar does
>   not change the frame height.

Looks good to me, I suggest installing that.

Re: Tabs

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: Juri Linkov <juri@linkov.net>,  emacs-devel@gnu.org
> Date: Mon, 07 Oct 2019 18:53:24 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Please try the latest master, I hope this is now fixed.
> 
> Seems fixed for me indeed.  Thank you!

Great, thanks for testing.

Re: Tabs

[Juri Linkov]

> Please try the latest master, I hope this is now fixed.

Thanks, I confirm this is fixed.

Re: Tabs

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

>  It infloops in these lines:
>
> 		  /* On some platforms (at least MS-Windows), the
> 		     scroll_run_hook called from scrolling_window
> 		     called from update_frame could set the frame's
> 		     garbaged flag, in which case we need to
> 		     redisplay the frame.  */
>                   if (FRAME_GARBAGED_P (f))
> 		    goto retry_frame;

Thanks.  Seems Eli changed this in

2fa9699fd7 Fix display of cursor in obscure use case on MS-Windows

Michael.

Re: Tabs

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sun, 06 Oct 2019 20:38:54 +0200
> 
> > 		  /* On some platforms (at least MS-Windows), the
> > 		     scroll_run_hook called from scrolling_window
> > 		     called from update_frame could set the frame's
> > 		     garbaged flag, in which case we need to
> > 		     redisplay the frame.  */
> >                   if (FRAME_GARBAGED_P (f))
> > 		    goto retry_frame;
> 
> Thanks.  Seems Eli changed this in
> 
> 2fa9699fd7 Fix display of cursor in obscure use case on MS-Windows

That change is not a bug: we cannot possible leave the frame garbaged
when we end a redisplay cycle.  Some other factor is at work here, and
it sounds like I need all the help you can provide to understand what
that is, because it doesn't seem to happen to me.

TIA

Re: Tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Michael Heerdegen <michael_heerdegen@web.de>,  emacs-devel@gnu.org
> Date: Sun, 06 Oct 2019 20:55:31 +0300
> 
> I can reproduce the redisplay issue, I never seen this before,
> maybe some recent change broke redisplaying.
> 
> I tried to debug and in redisplay_internal, the value of
> garbaged_frame_retries has a very large number - about thousands
> order of magnitude.  It never resets the 'garbaged' flag set in the
> selected frame.  And I have no idea how to force the 'garbaged' flag
> to be reset.  It infloops in these lines:
> 
> 		  /* On some platforms (at least MS-Windows), the
> 		     scroll_run_hook called from scrolling_window
> 		     called from update_frame could set the frame's
> 		     garbaged flag, in which case we need to
> 		     redisplay the frame.  */
>                   if (FRAME_GARBAGED_P (f))
> 		    goto retry_frame;

I need a reproducer.  Can you provide one?

Re: Tabs

[Michael Heerdegen]

Hi again,

is there anything I can try or do to find out why it doesn't work for
me?

> > I tried your code, and it works fine: tabs are shown only when
> > the current buffer is in Info mode, and hidden when the selected window's
> > buffer is in other modes.
>
> Hmm, no not for me, I never get tabs with this code.  I also tried with
> emacs -Q.  This is with current master - or do I still have to use a
> different branch?
>
> I see that (funcall tab-bar-tabs-function) in info buffers returns a
> list with multiple elements, so it /should/ work.
>
> Regards,
>
> Michael.


Thanks,

Michael.

Re: Tabs

[Juri Linkov]

>> > I tried your code, and it works fine: tabs are shown only when
>> > the current buffer is in Info mode, and hidden when the selected window's
>> > buffer is in other modes.
>>
>> Hmm, no not for me, I never get tabs with this code.  I also tried with
>> emacs -Q.  This is with current master - or do I still have to use a
>> different branch?
>>
>> I see that (funcall tab-bar-tabs-function) in info buffers returns a
>> list with multiple elements, so it /should/ work.
>
> is there anything I can try or do to find out why it doesn't work for
> me?

I tried your code again after enabling tab-bar-mode and it displays
tabs only in Info mode.  In other modes it displays an empty tab-bar
without tabs.  Is this what you expect?

Re: Tabs

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> I tried your code again after enabling tab-bar-mode and it displays
> tabs only in Info mode.  In other modes it displays an empty tab-bar
> without tabs.  Is this what you expect?

It is not what I get!  I never see a tab-bar with that code.  No tabs in
Info mode buffers.  We obviously see something different!

Plus, what I really want to achieve is to have tabs in Info and _no_
tab-bar in other buffers - a hidden instead of an empty tab bar.  Is
that even possible?


Regards,

Michael.

Re: Tabs

[Juri Linkov]

>> I tried your code again after enabling tab-bar-mode and it displays
>> tabs only in Info mode.  In other modes it displays an empty tab-bar
>> without tabs.  Is this what you expect?
>
> It is not what I get!  I never see a tab-bar with that code.  No tabs in
> Info mode buffers.  We obviously see something different!

Have you really enabled tab-bar-mode?

> Plus, what I really want to achieve is to have tabs in Info and _no_
> tab-bar in other buffers - a hidden instead of an empty tab bar.  Is
> that even possible?

This is possible but will have a “shaking” effect: switching to
an Info buffer will shift the whole text area down to free screen space
for the tab-bar, and switching to another buffer will move text up
after automatically removing the tab-bar.

Re: Tabs

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> > It is not what I get!  I never see a tab-bar with that code.  No tabs in
> > Info mode buffers.  We obviously see something different!
>
> Have you really enabled tab-bar-mode?

Ok, when I explicitly enable it it works.  But I had expected that the
custom setter of `tab-bar-show' would already do that...?

> > Plus, what I really want to achieve is to have tabs in Info and _no_
> > tab-bar in other buffers - a hidden instead of an empty tab bar.  Is
> > that even possible?
>
> This is possible but will have a “shaking” effect: switching to
> an Info buffer will shift the whole text area down to free screen space
> for the tab-bar, and switching to another buffer will move text up
> after automatically removing the tab-bar.

I think that would be acceptable: all buffers where I want tabs will
probably be displayed in a separate one-window frame.  Ok, and how do I
get that?


Thanks,

Michael.

Re: Tabs

[Juri Linkov]

>> > It is not what I get!  I never see a tab-bar with that code.  No tabs in
>> > Info mode buffers.  We obviously see something different!
>>
>> Have you really enabled tab-bar-mode?
>
> Ok, when I explicitly enable it it works.  But I had expected that the
> custom setter of `tab-bar-show' would already do that...?

`tab-bar-show' affects only tab commands.

>> > Plus, what I really want to achieve is to have tabs in Info and _no_
>> > tab-bar in other buffers - a hidden instead of an empty tab bar.  Is
>> > that even possible?
>>
>> This is possible but will have a “shaking” effect: switching to
>> an Info buffer will shift the whole text area down to free screen space
>> for the tab-bar, and switching to another buffer will move text up
>> after automatically removing the tab-bar.
>
> I think that would be acceptable: all buffers where I want tabs will
> probably be displayed in a separate one-window frame.  Ok, and how do I
> get that?

Then the solution is much simpler - in that frame just set

  (set-frame-parameter nil 'tab-bar-lines 1)

and to 0 in all other frames.

Re: Tabs

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> >> This is possible but will have a “shaking” effect: switching to
> >> an Info buffer will shift the whole text area down to free screen space
> >> for the tab-bar, and switching to another buffer will move text up
> >> after automatically removing the tab-bar.
> >
> > I think that would be acceptable: all buffers where I want tabs will
> > probably be displayed in a separate one-window frame.  Ok, and how do I
> > get that?
>
> Then the solution is much simpler - in that frame just set
>
>   (set-frame-parameter nil 'tab-bar-lines 1)
>
> and to 0 in all other frames.

And the alternative?  I would prefer a solution where the tabs would
appear without such an explicit activation.


TIA,

Michael.

Re: Tabs

[Juri Linkov]

>> >> This is possible but will have a “shaking” effect: switching to
>> >> an Info buffer will shift the whole text area down to free screen space
>> >> for the tab-bar, and switching to another buffer will move text up
>> >> after automatically removing the tab-bar.
>> >
>> > I think that would be acceptable: all buffers where I want tabs will
>> > probably be displayed in a separate one-window frame.  Ok, and how do I
>> > get that?
>>
>> Then the solution is much simpler - in that frame just set
>>
>>   (set-frame-parameter nil 'tab-bar-lines 1)
>>
>> and to 0 in all other frames.
>
> And the alternative?  I would prefer a solution where the tabs would
> appear without such an explicit activation.

Do you think we should have global-tab-bar-mode that affects all frames,
and tab-bar-mode to enable/disable the tab-bar only in the selected frame?

Analogously, having global-tab-line-mode to enable tab-line in all windows,
and tab-line-mode to toggle tab-line only in the selected window?

Re: Tabs

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> Do you think we should have global-tab-bar-mode that affects all frames,
> and tab-bar-mode to enable/disable the tab-bar only in the selected frame?

> Analogously, having global-tab-line-mode to enable tab-line in all windows,
> and tab-line-mode to toggle tab-line only in the selected window?

Could be useful maybe.  I've now just found out that what I want is to
use a tab-line, like this:

#+begin_src emacs-lisp
(require 'tab-line)
(setq-default tab-line-format nil)
(setq-default tab-line-close-tab-action #'kill-buffer)

(setq-default
 tab-line-tabs-function
 (defun my-tab-line-get-mode-tabs ()
   (cl-sort
    (let ((mode major-mode))
      (delq nil
            (mapcar
             (lambda (b)
               (and (with-current-buffer b
                      (derived-mode-p mode))
                    (not (string-match-p (rx bos " ")
                                         (buffer-name b)))
                    b))
             (buffer-list))))
            #'string< :key #'buffer-name)))

(defun my-enable-tab-line ()
  (setq-local tab-line-format '(:eval (tab-line-format))))

(dolist (hook '(Info-mode-hook eww-mode-hook))
  (add-hook hook #'my-enable-tab-line))
#+end_src

I think a local tab-line mode doesn't make that much sense currently
since everything, as far as I can see, is programmed around a global tab
bar/line, and using it as I want still requires local setup, so a local
mode per se isn't that useful for me.  FWIW, I think it would be an
improvement when the documentation just told somewhere how the tab-line
can be set up to cover use cases like mine.

I see that you did not have my use case in mind when I e.g. try
`tab-line-switch-to-next-tab': it switches to buffers that are not
displayed in the tab-line, and the tab-line just vanishes.

Maybe there could be different tab-bar/tab-line modes for the different
use cases, or something like that, haven't thought about it.


Thanks,

Michael.

Re: Tabs

[Juri Linkov]

> I've now just found out that what I want is to use a tab-line, like this:
>
> #+begin_src emacs-lisp
> (require 'tab-line)
> (setq-default tab-line-format nil)
> (setq-default tab-line-close-tab-action #'kill-buffer)
>
> (setq-default
>  tab-line-tabs-function
>  (defun my-tab-line-get-mode-tabs ()
>    (cl-sort
>     (let ((mode major-mode))
>       (delq nil
>             (mapcar
>              (lambda (b)
>                (and (with-current-buffer b
>                       (derived-mode-p mode))
>                     (not (string-match-p (rx bos " ")
>                                          (buffer-name b)))
>                     b))
>              (buffer-list))))
>             #'string< :key #'buffer-name)))
>
> (defun my-enable-tab-line ()
>   (setq-local tab-line-format '(:eval (tab-line-format))))
>
> (dolist (hook '(Info-mode-hook eww-mode-hook))
>   (add-hook hook #'my-enable-tab-line))
> #+end_src
> [...]
> I see that you did not have my use case in mind when I e.g. try
> `tab-line-switch-to-next-tab': it switches to buffers that are not
> displayed in the tab-line, and the tab-line just vanishes.
>
> Maybe there could be different tab-bar/tab-line modes for the different
> use cases, or something like that, haven't thought about it.

Thanks for posting the use case with real needs, so now it's clear
how to make tab-line customizable.

Now you can replace all code above with just 3 lines:

  (setq tab-line-tabs-function #'tab-line-tabs-mode-buffers)
  (dolist (hook '(Info-mode-hook eww-mode-hook))
    (add-hook hook #'tab-line-mode))

This is because now tab-line-tabs-function is customizable to the
function that populates the tab-line with buffers having the same mode.

Also there is separate global-tab-line-mode that affects all buffers
and buffer-local tab-line-mode.

tab-line-switch-to-next-tab works as well in your case now.

Re: Tabs

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> Now you can replace all code above with just 3 lines:
>
>   (setq tab-line-tabs-function #'tab-line-tabs-mode-buffers)
>   (dolist (hook '(Info-mode-hook eww-mode-hook))
>     (add-hook hook #'tab-line-mode))
>
> This is because now tab-line-tabs-function is customizable to the
> function that populates the tab-line with buffers having the same
> mode.

Tried that for some days now, and it works perfectly so far.

> tab-line-switch-to-next-tab works as well in your case now.

Confirmed.

Thank you very much!


Regards,

Michael.

Re: Tabs

[Juri Linkov]

>> Now you can replace all code above with just 3 lines:
>>
>>   (setq tab-line-tabs-function #'tab-line-tabs-mode-buffers)
>>   (dolist (hook '(Info-mode-hook eww-mode-hook))
>>     (add-hook hook #'tab-line-mode))
>>
>> This is because now tab-line-tabs-function is customizable to the
>> function that populates the tab-line with buffers having the same
>> mode.
>
> Tried that for some days now, and it works perfectly so far.

Now 'tab-line-tabs-function' has a new more general option
'tab-line-tabs-buffer-groups' that groups tabs by buffer modes.
Clicking on the mode name displays all modes.  Selecting a mode
from mode list displays only buffers with the same mode.

Re: Tabs

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> Now 'tab-line-tabs-function' has a new more general option
> 'tab-line-tabs-buffer-groups' that groups tabs by buffer modes.
> Clicking on the mode name displays all modes.  Selecting a mode
> from mode list displays only buffers with the same mode.

Works fine here - nice!


Thanks,

Michael.

Re: Tabs

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Works fine here - nice!

BTW, was it on purpose that you include buffers whose name starts with a
space character?

For example, when using `tab-line-tabs-mode-buffers' when I visit an
Info buffer the tab line often lists a buffer named " temp-info-look"
which is an internal helper buffer AFAIK.

Or should there be some kind of configurable filter?

Michael.

Re: Tabs

[Juri Linkov]

>> Works fine here - nice!
>
> BTW, was it on purpose that you include buffers whose name starts with a
> space character?
>
> For example, when using `tab-line-tabs-mode-buffers' when I visit an
> Info buffer the tab line often lists a buffer named " temp-info-look"
> which is an internal helper buffer AFAIK.
>
> Or should there be some kind of configurable filter?

A list of buffers is configurable now using a new variable that by default
doesn't include buffers whose name starts with a space character.

Re: Tabs

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> > Or should there be some kind of configurable filter?
>
> A list of buffers is configurable now using a new variable that by
> default doesn't include buffers whose name starts with a space
> character.

Looks good, thanks.  Seems I can also use buffer local bindings for
`tab-line-tabs-buffer-list-function', which is also good.

BTW, in `tab-line-tabs-buffer-list', is the `buffer-live-p' filter test
on the result of `buffer-list':

"Return a list of all live buffers.[...]"

redundant?


Regards,

Michael.

Re: Tabs

[Juri Linkov]

>> A list of buffers is configurable now using a new variable that by
>> default doesn't include buffers whose name starts with a space
>> character.
>
> Looks good, thanks.  Seems I can also use buffer local bindings for
> `tab-line-tabs-buffer-list-function', which is also good.
>
> BTW, in `tab-line-tabs-buffer-list', is the `buffer-live-p' filter test
> on the result of `buffer-list':
>
> "Return a list of all live buffers.[...]"
>
> redundant?

I added `buffer-live-p' after discovering that not all buffers
are live in the buffer list.  But maybe this happened only in the
buffer list combined with the list of window-prev-buffers.

Re: Tabs

[martin rudalics]

 >> BTW, in `tab-line-tabs-buffer-list', is the `buffer-live-p' filter test
 >> on the result of `buffer-list':
 >>
 >> "Return a list of all live buffers.[...]"
 >>
 >> redundant?
 >
 > I added `buffer-live-p' after discovering that not all buffers
 > are live in the buffer list.  But maybe this happened only in the
 > buffer list combined with the list of window-prev-buffers.

'buffer-list' should be clean in this regard.  'window-prev-buffers'
(and 'window-next-buffers') are not, for the simple technical reason
that a window is not accessible when it has been deleted but remains
within some saved configuration or state.  This means that
'kill-buffer' cannot always update these lists for sure and it mainly
depends on GC frequency whether a killed buffer appears in one of
these lists or not.  Both, 'switch-to-prev-buffer' and
'switch-to-next-buffer' prune dead buffers from the respective lists
when they find one.

martin