* RE: Tabs [not found] ` <<courier.000000005D6DF86C.00005323@protected.rcdrun.com> @ 2019-09-03 15:24 ` Drew Adams 0 siblings, 0 replies; 209+ messages in thread From: Drew Adams @ 2019-09-03 15:24 UTC (permalink / raw) To: Jean Louis, Juri Linkov; +Cc: lokedhs, stefan, rudalics, emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs
@ 2019-09-03 9:20 Angelo Graziosi
0 siblings, 0 replies; 209+ messages in thread
From: Angelo Graziosi @ 2019-09-03 9:20 UTC (permalink / raw)
To: emacs-devel
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'...
^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs @ 2019-09-02 13:31 Angelo Graziosi 2019-09-02 19:46 ` Tabs Juri Linkov 0 siblings, 1 reply; 209+ messages in thread From: Angelo Graziosi @ 2019-09-02 13:31 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-02 13:31 Tabs Angelo Graziosi @ 2019-09-02 19:46 ` Juri Linkov 2019-09-03 8:49 ` Tabs Angelo Graziosi 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-09-02 19:46 UTC (permalink / raw) To: Angelo Graziosi; +Cc: emacs-devel > 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-02 19:46 ` Tabs Juri Linkov @ 2019-09-03 8:49 ` Angelo Graziosi 2019-09-03 19:48 ` Tabs Juri Linkov 0 siblings, 1 reply; 209+ messages in thread From: Angelo Graziosi @ 2019-09-03 8:49 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-03 8:49 ` Tabs Angelo Graziosi @ 2019-09-03 19:48 ` Juri Linkov 2019-09-04 8:22 ` Tabs Angelo Graziosi 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-09-03 19:48 UTC (permalink / raw) To: Angelo Graziosi; +Cc: emacs-devel >> >> 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-03 19:48 ` Tabs Juri Linkov @ 2019-09-04 8:22 ` Angelo Graziosi 2019-09-04 19:05 ` Tabs Juri Linkov 0 siblings, 1 reply; 209+ messages in thread From: Angelo Graziosi @ 2019-09-04 8:22 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-04 8:22 ` Tabs Angelo Graziosi @ 2019-09-04 19:05 ` Juri Linkov 2019-09-04 22:41 ` Tabs Angelo Graziosi 2019-09-05 21:40 ` Tabs Angelo Graziosi 0 siblings, 2 replies; 209+ messages in thread From: Juri Linkov @ 2019-09-04 19:05 UTC (permalink / raw) To: Angelo Graziosi; +Cc: emacs-devel >> 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-04 19:05 ` Tabs Juri Linkov @ 2019-09-04 22:41 ` Angelo Graziosi 2019-09-05 21:40 ` Tabs Angelo Graziosi 1 sibling, 0 replies; 209+ messages in thread From: Angelo Graziosi @ 2019-09-04 22:41 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel > 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.. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-04 19:05 ` Tabs Juri Linkov 2019-09-04 22:41 ` Tabs Angelo Graziosi @ 2019-09-05 21:40 ` Angelo Graziosi 2019-09-06 20:16 ` Tabs Angelo Graziosi ` (2 more replies) 1 sibling, 3 replies; 209+ messages in thread From: Angelo Graziosi @ 2019-09-05 21:40 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-05 21:40 ` Tabs Angelo Graziosi @ 2019-09-06 20:16 ` Angelo Graziosi 2019-09-07 20:28 ` Tabs Juri Linkov 2019-09-08 20:19 ` Tabs Juri Linkov 2 siblings, 0 replies; 209+ messages in thread From: Angelo Graziosi @ 2019-09-06 20:16 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-05 21:40 ` Tabs Angelo Graziosi 2019-09-06 20:16 ` Tabs Angelo Graziosi @ 2019-09-07 20:28 ` Juri Linkov 2019-09-08 20:19 ` Tabs Juri Linkov 2 siblings, 0 replies; 209+ messages in thread From: Juri Linkov @ 2019-09-07 20:28 UTC (permalink / raw) To: Angelo Graziosi; +Cc: emacs-devel >> 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-05 21:40 ` Tabs Angelo Graziosi 2019-09-06 20:16 ` Tabs Angelo Graziosi 2019-09-07 20:28 ` Tabs Juri Linkov @ 2019-09-08 20:19 ` Juri Linkov 2019-09-16 7:56 ` Tabs Angelo Graziosi 2 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-09-08 20:19 UTC (permalink / raw) To: Angelo Graziosi; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-08 20:19 ` Tabs Juri Linkov @ 2019-09-16 7:56 ` Angelo Graziosi 2019-09-16 8:45 ` Tabs Angelo Graziosi 0 siblings, 1 reply; 209+ messages in thread From: Angelo Graziosi @ 2019-09-16 7:56 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-16 7:56 ` Tabs Angelo Graziosi @ 2019-09-16 8:45 ` Angelo Graziosi 2019-09-16 20:43 ` Tabs Juri Linkov 0 siblings, 1 reply; 209+ messages in thread From: Angelo Graziosi @ 2019-09-16 8:45 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-16 8:45 ` Tabs Angelo Graziosi @ 2019-09-16 20:43 ` Juri Linkov 2019-10-13 14:49 ` Tabs Angelo Graziosi 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-09-16 20:43 UTC (permalink / raw) To: Angelo Graziosi; +Cc: emacs-devel >> 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-16 20:43 ` Tabs Juri Linkov @ 2019-10-13 14:49 ` Angelo Graziosi 2019-10-13 15:07 ` Tabs Eli Zaretskii 2019-10-13 22:01 ` Tabs Juri Linkov 0 siblings, 2 replies; 209+ messages in thread From: Angelo Graziosi @ 2019-10-13 14:49 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-13 14:49 ` Tabs Angelo Graziosi @ 2019-10-13 15:07 ` Eli Zaretskii 2019-10-13 21:09 ` Tabs Angelo Graziosi 2019-10-13 22:08 ` Tabs Juri Linkov 2019-10-13 22:01 ` Tabs Juri Linkov 1 sibling, 2 replies; 209+ messages in thread From: Eli Zaretskii @ 2019-10-13 15:07 UTC (permalink / raw) To: Angelo Graziosi; +Cc: emacs-devel, juri > 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-13 15:07 ` Tabs Eli Zaretskii @ 2019-10-13 21:09 ` Angelo Graziosi 2019-10-14 8:23 ` Tabs Eli Zaretskii 2019-10-13 22:08 ` Tabs Juri Linkov 1 sibling, 1 reply; 209+ messages in thread From: Angelo Graziosi @ 2019-10-13 21:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: juri, emacs-devel > 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-13 21:09 ` Tabs Angelo Graziosi @ 2019-10-14 8:23 ` Eli Zaretskii 2019-10-15 21:38 ` Tabs Angelo Graziosi 0 siblings, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-14 8:23 UTC (permalink / raw) To: Angelo Graziosi; +Cc: emacs-devel, juri > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-14 8:23 ` Tabs Eli Zaretskii @ 2019-10-15 21:38 ` Angelo Graziosi 2019-10-16 6:53 ` Tabs Eli Zaretskii 0 siblings, 1 reply; 209+ messages in thread From: Angelo Graziosi @ 2019-10-15 21:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: juri, emacs-devel > 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-15 21:38 ` Tabs Angelo Graziosi @ 2019-10-16 6:53 ` Eli Zaretskii 0 siblings, 0 replies; 209+ messages in thread From: Eli Zaretskii @ 2019-10-16 6:53 UTC (permalink / raw) To: Angelo Graziosi; +Cc: emacs-devel, juri > 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). ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-13 15:07 ` Tabs Eli Zaretskii 2019-10-13 21:09 ` Tabs Angelo Graziosi @ 2019-10-13 22:08 ` Juri Linkov 2019-10-14 6:37 ` Tabs Eli Zaretskii 1 sibling, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-10-13 22:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Angelo Graziosi, emacs-devel >> 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-13 22:08 ` Tabs Juri Linkov @ 2019-10-14 6:37 ` Eli Zaretskii 2019-10-15 7:55 ` Tabs Eli Zaretskii 0 siblings, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-14 6:37 UTC (permalink / raw) To: Juri Linkov; +Cc: angelo.g0, emacs-devel > 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-14 6:37 ` Tabs Eli Zaretskii @ 2019-10-15 7:55 ` Eli Zaretskii 2019-10-15 19:44 ` Tabs Juri Linkov 0 siblings, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-15 7:55 UTC (permalink / raw) To: juri; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-15 7:55 ` Tabs Eli Zaretskii @ 2019-10-15 19:44 ` Juri Linkov 2019-10-16 6:23 ` Tabs Eli Zaretskii 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-10-15 19:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel >> > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-15 19:44 ` Tabs Juri Linkov @ 2019-10-16 6:23 ` Eli Zaretskii 2019-10-16 22:17 ` Tabs Juri Linkov 0 siblings, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-16 6:23 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel > 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-16 6:23 ` Tabs Eli Zaretskii @ 2019-10-16 22:17 ` Juri Linkov 2019-10-17 7:17 ` Tabs Eli Zaretskii 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-10-16 22:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel >> 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-16 22:17 ` Tabs Juri Linkov @ 2019-10-17 7:17 ` Eli Zaretskii 0 siblings, 0 replies; 209+ messages in thread From: Eli Zaretskii @ 2019-10-17 7:17 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel > 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-13 14:49 ` Tabs Angelo Graziosi 2019-10-13 15:07 ` Tabs Eli Zaretskii @ 2019-10-13 22:01 ` Juri Linkov 1 sibling, 0 replies; 209+ messages in thread From: Juri Linkov @ 2019-10-13 22:01 UTC (permalink / raw) To: Angelo Graziosi; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Tabs @ 2019-08-31 20:45 Juri Linkov 2019-09-01 8:12 ` Tabs martin rudalics ` (5 more replies) 0 siblings, 6 replies; 209+ messages in thread From: Juri Linkov @ 2019-08-31 20:45 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-08-31 20:45 Tabs Juri Linkov @ 2019-09-01 8:12 ` martin rudalics 2019-09-01 14:40 ` Tabs Eli Zaretskii 2019-09-01 19:57 ` Tabs Juri Linkov 2019-09-01 9:28 ` Tabs Alan Mackenzie ` (4 subsequent siblings) 5 siblings, 2 replies; 209+ messages in thread From: martin rudalics @ 2019-09-01 8:12 UTC (permalink / raw) To: Juri Linkov, emacs-devel [-- 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 *); ^ permalink raw reply related [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-01 8:12 ` Tabs martin rudalics @ 2019-09-01 14:40 ` Eli Zaretskii 2019-09-01 19:57 ` Tabs Juri Linkov 1 sibling, 0 replies; 209+ messages in thread From: Eli Zaretskii @ 2019-09-01 14:40 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-devel, juri > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-01 8:12 ` Tabs martin rudalics 2019-09-01 14:40 ` Tabs Eli Zaretskii @ 2019-09-01 19:57 ` Juri Linkov 2019-09-02 0:40 ` Tabs Stefan Kangas 2019-09-02 2:29 ` Tabs Eli Zaretskii 1 sibling, 2 replies; 209+ messages in thread From: Juri Linkov @ 2019-09-01 19:57 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-devel >> 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-01 19:57 ` Tabs Juri Linkov @ 2019-09-02 0:40 ` Stefan Kangas 2019-09-02 10:11 ` Tabs Elias Mårtenson 2019-09-02 19:17 ` Tabs Juri Linkov 2019-09-02 2:29 ` Tabs Eli Zaretskii 1 sibling, 2 replies; 209+ messages in thread From: Stefan Kangas @ 2019-09-02 0:40 UTC (permalink / raw) To: Juri Linkov; +Cc: martin rudalics, emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-02 0:40 ` Tabs Stefan Kangas @ 2019-09-02 10:11 ` Elias Mårtenson 2019-09-02 11:16 ` Tabs Dmitry Gutov 2019-09-02 19:27 ` Tabs Juri Linkov 2019-09-02 19:17 ` Tabs Juri Linkov 1 sibling, 2 replies; 209+ messages in thread From: Elias Mårtenson @ 2019-09-02 10:11 UTC (permalink / raw) To: Stefan Kangas; +Cc: martin rudalics, emacs-devel, Juri Linkov [-- 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 --] ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-02 10:11 ` Tabs Elias Mårtenson @ 2019-09-02 11:16 ` Dmitry Gutov 2019-09-02 19:27 ` Tabs Juri Linkov 1 sibling, 0 replies; 209+ messages in thread From: Dmitry Gutov @ 2019-09-02 11:16 UTC (permalink / raw) To: Elias Mårtenson, Stefan Kangas Cc: martin rudalics, Juri Linkov, emacs-devel 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-02 10:11 ` Tabs Elias Mårtenson 2019-09-02 11:16 ` Tabs Dmitry Gutov @ 2019-09-02 19:27 ` Juri Linkov 2019-09-03 5:21 ` Tabs Jean Louis 1 sibling, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-09-02 19:27 UTC (permalink / raw) To: Elias Mårtenson; +Cc: martin rudalics, Stefan Kangas, emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-02 19:27 ` Tabs Juri Linkov @ 2019-09-03 5:21 ` Jean Louis 2019-09-03 19:40 ` Tabs Juri Linkov 0 siblings, 1 reply; 209+ messages in thread From: Jean Louis @ 2019-09-03 5:21 UTC (permalink / raw) To: Juri Linkov; +Cc: stefan, emacs-devel, lokedhs, rudalics 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) ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-03 5:21 ` Tabs Jean Louis @ 2019-09-03 19:40 ` Juri Linkov 2019-09-03 20:14 ` Tabs Jean Louis 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-09-03 19:40 UTC (permalink / raw) To: Jean Louis; +Cc: stefan, emacs-devel, lokedhs, rudalics > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-03 19:40 ` Tabs Juri Linkov @ 2019-09-03 20:14 ` Jean Louis 0 siblings, 0 replies; 209+ messages in thread From: Jean Louis @ 2019-09-03 20:14 UTC (permalink / raw) To: Juri Linkov; +Cc: stefan, emacs-devel, lokedhs, rudalics 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-02 0:40 ` Tabs Stefan Kangas 2019-09-02 10:11 ` Tabs Elias Mårtenson @ 2019-09-02 19:17 ` Juri Linkov 2019-09-03 5:45 ` Tabs Yuri Khan 2019-09-15 16:44 ` Tabs Stefan Kangas 1 sibling, 2 replies; 209+ messages in thread From: Juri Linkov @ 2019-09-02 19:17 UTC (permalink / raw) To: Stefan Kangas; +Cc: martin rudalics, emacs-devel > 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-02 19:17 ` Tabs Juri Linkov @ 2019-09-03 5:45 ` Yuri Khan 2019-09-03 19:45 ` Tabs Juri Linkov 2019-09-15 16:44 ` Tabs Stefan Kangas 1 sibling, 1 reply; 209+ messages in thread From: Yuri Khan @ 2019-09-03 5:45 UTC (permalink / raw) To: Juri Linkov; +Cc: martin rudalics, Stefan Kangas, Emacs developers 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-03 5:45 ` Tabs Yuri Khan @ 2019-09-03 19:45 ` Juri Linkov 0 siblings, 0 replies; 209+ messages in thread From: Juri Linkov @ 2019-09-03 19:45 UTC (permalink / raw) To: Yuri Khan; +Cc: martin rudalics, Stefan Kangas, Emacs developers >> 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-02 19:17 ` Tabs Juri Linkov 2019-09-03 5:45 ` Tabs Yuri Khan @ 2019-09-15 16:44 ` Stefan Kangas 2019-09-15 21:17 ` Tabs Juri Linkov 1 sibling, 1 reply; 209+ messages in thread From: Stefan Kangas @ 2019-09-15 16:44 UTC (permalink / raw) To: Juri Linkov; +Cc: martin rudalics, emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-15 16:44 ` Tabs Stefan Kangas @ 2019-09-15 21:17 ` Juri Linkov 0 siblings, 0 replies; 209+ messages in thread From: Juri Linkov @ 2019-09-15 21:17 UTC (permalink / raw) To: Stefan Kangas; +Cc: martin rudalics, emacs-devel >> > (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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-01 19:57 ` Tabs Juri Linkov 2019-09-02 0:40 ` Tabs Stefan Kangas @ 2019-09-02 2:29 ` Eli Zaretskii 2019-09-02 19:29 ` Tabs Juri Linkov 1 sibling, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-09-02 2:29 UTC (permalink / raw) To: Juri Linkov; +Cc: rudalics, emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-02 2:29 ` Tabs Eli Zaretskii @ 2019-09-02 19:29 ` Juri Linkov 2019-09-03 2:27 ` Tabs Eli Zaretskii 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-09-02 19:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rudalics, emacs-devel >> > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-02 19:29 ` Tabs Juri Linkov @ 2019-09-03 2:27 ` Eli Zaretskii 0 siblings, 0 replies; 209+ messages in thread From: Eli Zaretskii @ 2019-09-03 2:27 UTC (permalink / raw) To: Juri Linkov; +Cc: rudalics, emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-08-31 20:45 Tabs Juri Linkov 2019-09-01 8:12 ` Tabs martin rudalics @ 2019-09-01 9:28 ` Alan Mackenzie 2019-09-01 19:18 ` Tabs Juri Linkov 2019-09-01 12:31 ` Tabs Ergus ` (3 subsequent siblings) 5 siblings, 1 reply; 209+ messages in thread From: Alan Mackenzie @ 2019-09-01 9:28 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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). ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-01 9:28 ` Tabs Alan Mackenzie @ 2019-09-01 19:18 ` Juri Linkov 0 siblings, 0 replies; 209+ messages in thread From: Juri Linkov @ 2019-09-01 19:18 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel >> 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-08-31 20:45 Tabs Juri Linkov 2019-09-01 8:12 ` Tabs martin rudalics 2019-09-01 9:28 ` Tabs Alan Mackenzie @ 2019-09-01 12:31 ` Ergus 2019-09-01 19:31 ` Tabs Juri Linkov 2019-09-03 12:22 ` Tabs Robert Pluim ` (2 subsequent siblings) 5 siblings, 1 reply; 209+ messages in thread From: Ergus @ 2019-09-01 12:31 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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: > ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-01 12:31 ` Tabs Ergus @ 2019-09-01 19:31 ` Juri Linkov 2019-09-02 4:51 ` Tabs Ergus 2019-09-02 12:41 ` Tabs Stefan Monnier 0 siblings, 2 replies; 209+ messages in thread From: Juri Linkov @ 2019-09-01 19:31 UTC (permalink / raw) To: Ergus; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-01 19:31 ` Tabs Juri Linkov @ 2019-09-02 4:51 ` Ergus 2019-09-02 19:33 ` Tabs Juri Linkov 2019-09-02 12:41 ` Tabs Stefan Monnier 1 sibling, 1 reply; 209+ messages in thread From: Ergus @ 2019-09-02 4:51 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-02 4:51 ` Tabs Ergus @ 2019-09-02 19:33 ` Juri Linkov 2019-09-02 21:06 ` Tabs Stefan Monnier ` (3 more replies) 0 siblings, 4 replies; 209+ messages in thread From: Juri Linkov @ 2019-09-02 19:33 UTC (permalink / raw) To: Ergus; +Cc: emacs-devel > 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-02 19:33 ` Tabs Juri Linkov @ 2019-09-02 21:06 ` Stefan Monnier 2019-09-03 19:56 ` Tabs Juri Linkov 2019-09-03 2:30 ` Tabs Eli Zaretskii ` (2 subsequent siblings) 3 siblings, 1 reply; 209+ messages in thread From: Stefan Monnier @ 2019-09-02 21:06 UTC (permalink / raw) To: Juri Linkov; +Cc: Ergus, emacs-devel >> 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)" ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-02 21:06 ` Tabs Stefan Monnier @ 2019-09-03 19:56 ` Juri Linkov 0 siblings, 0 replies; 209+ messages in thread From: Juri Linkov @ 2019-09-03 19:56 UTC (permalink / raw) To: Stefan Monnier; +Cc: Ergus, emacs-devel >>> 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-02 19:33 ` Tabs Juri Linkov 2019-09-02 21:06 ` Tabs Stefan Monnier @ 2019-09-03 2:30 ` Eli Zaretskii 2019-09-03 19:58 ` Tabs Juri Linkov 2019-09-03 5:39 ` Tabs Ergus 2019-09-05 22:24 ` Tabs Ergus 3 siblings, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-09-03 2:30 UTC (permalink / raw) To: Juri Linkov; +Cc: spacibba, emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-03 2:30 ` Tabs Eli Zaretskii @ 2019-09-03 19:58 ` Juri Linkov 0 siblings, 0 replies; 209+ messages in thread From: Juri Linkov @ 2019-09-03 19:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: spacibba, emacs-devel >> > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-02 19:33 ` Tabs Juri Linkov 2019-09-02 21:06 ` Tabs Stefan Monnier 2019-09-03 2:30 ` Tabs Eli Zaretskii @ 2019-09-03 5:39 ` Ergus 2019-09-05 22:24 ` Tabs Ergus 3 siblings, 0 replies; 209+ messages in thread From: Ergus @ 2019-09-03 5:39 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-02 19:33 ` Tabs Juri Linkov ` (2 preceding siblings ...) 2019-09-03 5:39 ` Tabs Ergus @ 2019-09-05 22:24 ` Ergus 2019-09-07 20:14 ` Tabs Juri Linkov 3 siblings, 1 reply; 209+ messages in thread From: Ergus @ 2019-09-05 22:24 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-05 22:24 ` Tabs Ergus @ 2019-09-07 20:14 ` Juri Linkov 0 siblings, 0 replies; 209+ messages in thread From: Juri Linkov @ 2019-09-07 20:14 UTC (permalink / raw) To: Ergus; +Cc: emacs-devel [-- 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-01 19:31 ` Tabs Juri Linkov 2019-09-02 4:51 ` Tabs Ergus @ 2019-09-02 12:41 ` Stefan Monnier 2019-09-02 19:39 ` Tabs Juri Linkov 1 sibling, 1 reply; 209+ messages in thread From: Stefan Monnier @ 2019-09-02 12:41 UTC (permalink / raw) To: Juri Linkov; +Cc: Ergus, emacs-devel > '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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-02 12:41 ` Tabs Stefan Monnier @ 2019-09-02 19:39 ` Juri Linkov 2019-09-02 21:03 ` Tabs Stefan Monnier 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-09-02 19:39 UTC (permalink / raw) To: Stefan Monnier; +Cc: Ergus, emacs-devel >> '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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-02 19:39 ` Tabs Juri Linkov @ 2019-09-02 21:03 ` Stefan Monnier 0 siblings, 0 replies; 209+ messages in thread From: Stefan Monnier @ 2019-09-02 21:03 UTC (permalink / raw) To: Juri Linkov; +Cc: Ergus, emacs-devel > These names were created by analogy with the existing frame/buffer commands: Yeah, I don't like their lack of prefix-naming either. :-( Stefan ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-08-31 20:45 Tabs Juri Linkov ` (2 preceding siblings ...) 2019-09-01 12:31 ` Tabs Ergus @ 2019-09-03 12:22 ` Robert Pluim 2019-09-03 20:21 ` Tabs Juri Linkov 2019-09-15 19:21 ` Tabs Stefan Kangas 2019-09-19 23:57 ` Tabs Michael Heerdegen 5 siblings, 1 reply; 209+ messages in thread From: Robert Pluim @ 2019-09-03 12:22 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-03 12:22 ` Tabs Robert Pluim @ 2019-09-03 20:21 ` Juri Linkov 0 siblings, 0 replies; 209+ messages in thread From: Juri Linkov @ 2019-09-03 20:21 UTC (permalink / raw) To: emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-08-31 20:45 Tabs Juri Linkov ` (3 preceding siblings ...) 2019-09-03 12:22 ` Tabs Robert Pluim @ 2019-09-15 19:21 ` Stefan Kangas 2019-09-15 21:32 ` Tabs Juri Linkov 2019-09-19 23:57 ` Tabs Michael Heerdegen 5 siblings, 1 reply; 209+ messages in thread From: Stefan Kangas @ 2019-09-15 19:21 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-15 19:21 ` Tabs Stefan Kangas @ 2019-09-15 21:32 ` Juri Linkov 2019-09-16 4:19 ` Tabs Yuri Khan 2019-09-28 17:06 ` Tabs Stefan Kangas 0 siblings, 2 replies; 209+ messages in thread From: Juri Linkov @ 2019-09-15 21:32 UTC (permalink / raw) To: Stefan Kangas; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-15 21:32 ` Tabs Juri Linkov @ 2019-09-16 4:19 ` Yuri Khan 2019-09-16 20:59 ` Tabs Juri Linkov 2019-09-28 17:06 ` Tabs Stefan Kangas 1 sibling, 1 reply; 209+ messages in thread From: Yuri Khan @ 2019-09-16 4:19 UTC (permalink / raw) To: Juri Linkov; +Cc: Stefan Kangas, Emacs developers 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-16 4:19 ` Tabs Yuri Khan @ 2019-09-16 20:59 ` Juri Linkov 2019-09-17 5:29 ` Tabs Yuri Khan 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-09-16 20:59 UTC (permalink / raw) To: Yuri Khan; +Cc: Stefan Kangas, Emacs developers >> > 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Tabs 2019-09-16 20:59 ` Tabs Juri Linkov @ 2019-09-17 5:29 ` Yuri Khan 2019-09-17 20:37 ` Tabs Juri Linkov 0 siblings, 1 reply; 209+ messages in thread From: Yuri Khan @ 2019-09-17 5:29 UTC (permalink / raw) To: Juri Linkov; +Cc: Stefan Kangas, Emacs developers [-- 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 --] ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-17 5:29 ` Tabs Yuri Khan @ 2019-09-17 20:37 ` Juri Linkov 2019-09-17 22:53 ` Tabs Drew Adams 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-09-17 20:37 UTC (permalink / raw) To: Yuri Khan; +Cc: Stefan Kangas, Emacs developers >> 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* RE: Tabs 2019-09-17 20:37 ` Tabs Juri Linkov @ 2019-09-17 22:53 ` Drew Adams 0 siblings, 0 replies; 209+ messages in thread From: Drew Adams @ 2019-09-17 22:53 UTC (permalink / raw) To: Juri Linkov, Yuri Khan; +Cc: Stefan Kangas, Emacs developers > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-15 21:32 ` Tabs Juri Linkov 2019-09-16 4:19 ` Tabs Yuri Khan @ 2019-09-28 17:06 ` Stefan Kangas 2019-09-28 19:52 ` Tabs Juri Linkov 2019-11-02 21:40 ` Tabs Juri Linkov 1 sibling, 2 replies; 209+ messages in thread From: Stefan Kangas @ 2019-09-28 17:06 UTC (permalink / raw) To: Juri Linkov; +Cc: Emacs developers 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-28 17:06 ` Tabs Stefan Kangas @ 2019-09-28 19:52 ` Juri Linkov 2019-10-20 22:38 ` Tabs Juri Linkov 2019-11-02 21:40 ` Tabs Juri Linkov 1 sibling, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-09-28 19:52 UTC (permalink / raw) To: Stefan Kangas; +Cc: Emacs developers >> > 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! ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-28 19:52 ` Tabs Juri Linkov @ 2019-10-20 22:38 ` Juri Linkov 0 siblings, 0 replies; 209+ messages in thread From: Juri Linkov @ 2019-10-20 22:38 UTC (permalink / raw) To: Stefan Kangas; +Cc: Emacs developers >>> > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-28 17:06 ` Tabs Stefan Kangas 2019-09-28 19:52 ` Tabs Juri Linkov @ 2019-11-02 21:40 ` Juri Linkov 1 sibling, 0 replies; 209+ messages in thread From: Juri Linkov @ 2019-11-02 21:40 UTC (permalink / raw) To: Stefan Kangas; +Cc: Emacs developers >> > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-08-31 20:45 Tabs Juri Linkov ` (4 preceding siblings ...) 2019-09-15 19:21 ` Tabs Stefan Kangas @ 2019-09-19 23:57 ` Michael Heerdegen 2019-09-21 22:45 ` Tabs Juri Linkov 5 siblings, 1 reply; 209+ messages in thread From: Michael Heerdegen @ 2019-09-19 23:57 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-19 23:57 ` Tabs Michael Heerdegen @ 2019-09-21 22:45 ` Juri Linkov 2019-09-22 0:31 ` Tabs Michael Heerdegen 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-09-21 22:45 UTC (permalink / raw) To: Michael Heerdegen; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-21 22:45 ` Tabs Juri Linkov @ 2019-09-22 0:31 ` Michael Heerdegen 2019-09-25 20:15 ` Tabs Juri Linkov 0 siblings, 1 reply; 209+ messages in thread From: Michael Heerdegen @ 2019-09-22 0:31 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-22 0:31 ` Tabs Michael Heerdegen @ 2019-09-25 20:15 ` Juri Linkov 2019-10-05 13:57 ` Tabs Michael Heerdegen 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-09-25 20:15 UTC (permalink / raw) To: Michael Heerdegen; +Cc: emacs-devel >> 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-09-25 20:15 ` Tabs Juri Linkov @ 2019-10-05 13:57 ` Michael Heerdegen 2019-10-05 22:12 ` Tabs Juri Linkov 0 siblings, 1 reply; 209+ messages in thread From: Michael Heerdegen @ 2019-10-05 13:57 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-05 13:57 ` Tabs Michael Heerdegen @ 2019-10-05 22:12 ` Juri Linkov 2019-10-06 8:22 ` Tabs Michael Heerdegen 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-10-05 22:12 UTC (permalink / raw) To: Michael Heerdegen; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-05 22:12 ` Tabs Juri Linkov @ 2019-10-06 8:22 ` Michael Heerdegen 2019-10-06 12:09 ` Tabs Michael Heerdegen 2019-10-08 19:15 ` Tabs Michael Heerdegen 0 siblings, 2 replies; 209+ messages in thread From: Michael Heerdegen @ 2019-10-06 8:22 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-06 8:22 ` Tabs Michael Heerdegen @ 2019-10-06 12:09 ` Michael Heerdegen 2019-10-06 15:16 ` Tabs Michael Heerdegen 2019-10-06 17:49 ` Tabs Eli Zaretskii 2019-10-08 19:15 ` Tabs Michael Heerdegen 1 sibling, 2 replies; 209+ messages in thread From: Michael Heerdegen @ 2019-10-06 12:09 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-06 12:09 ` Tabs Michael Heerdegen @ 2019-10-06 15:16 ` Michael Heerdegen 2019-10-06 17:49 ` Tabs Eli Zaretskii 1 sibling, 0 replies; 209+ messages in thread From: Michael Heerdegen @ 2019-10-06 15:16 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-06 12:09 ` Tabs Michael Heerdegen 2019-10-06 15:16 ` Tabs Michael Heerdegen @ 2019-10-06 17:49 ` Eli Zaretskii 2019-10-06 17:55 ` Tabs Juri Linkov 1 sibling, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-06 17:49 UTC (permalink / raw) To: Michael Heerdegen; +Cc: emacs-devel, juri > 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-06 17:49 ` Tabs Eli Zaretskii @ 2019-10-06 17:55 ` Juri Linkov 2019-10-06 18:05 ` Tabs Juri Linkov ` (2 more replies) 0 siblings, 3 replies; 209+ messages in thread From: Juri Linkov @ 2019-10-06 17:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Michael Heerdegen, emacs-devel >> 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; ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-06 17:55 ` Tabs Juri Linkov @ 2019-10-06 18:05 ` Juri Linkov 2019-10-06 18:58 ` Tabs Eli Zaretskii 2019-10-06 18:59 ` Tabs Eli Zaretskii 2019-10-06 18:38 ` Tabs Michael Heerdegen 2019-10-06 18:56 ` Tabs Eli Zaretskii 2 siblings, 2 replies; 209+ messages in thread From: Juri Linkov @ 2019-10-06 18:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Michael Heerdegen, emacs-devel >>> 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-06 18:05 ` Tabs Juri Linkov @ 2019-10-06 18:58 ` Eli Zaretskii 2019-10-06 18:59 ` Tabs Eli Zaretskii 1 sibling, 0 replies; 209+ messages in thread From: Eli Zaretskii @ 2019-10-06 18:58 UTC (permalink / raw) To: Juri Linkov; +Cc: michael_heerdegen, emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-06 18:05 ` Tabs Juri Linkov 2019-10-06 18:58 ` Tabs Eli Zaretskii @ 2019-10-06 18:59 ` Eli Zaretskii 2019-10-06 19:08 ` Tabs Michael Heerdegen 2019-10-06 19:11 ` Tabs Juri Linkov 1 sibling, 2 replies; 209+ messages in thread From: Eli Zaretskii @ 2019-10-06 18:59 UTC (permalink / raw) To: Juri Linkov; +Cc: michael_heerdegen, emacs-devel > 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-06 18:59 ` Tabs Eli Zaretskii @ 2019-10-06 19:08 ` Michael Heerdegen 2019-10-06 19:11 ` Tabs Juri Linkov 1 sibling, 0 replies; 209+ messages in thread From: Michael Heerdegen @ 2019-10-06 19:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel, Juri Linkov 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-06 18:59 ` Tabs Eli Zaretskii 2019-10-06 19:08 ` Tabs Michael Heerdegen @ 2019-10-06 19:11 ` Juri Linkov 2019-10-06 19:21 ` Tabs Eli Zaretskii 1 sibling, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-10-06 19:11 UTC (permalink / raw) To: Eli Zaretskii; +Cc: michael_heerdegen, emacs-devel >> > /* 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' ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-06 19:11 ` Tabs Juri Linkov @ 2019-10-06 19:21 ` Eli Zaretskii 2019-10-06 19:58 ` Tabs Juri Linkov 0 siblings, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-06 19:21 UTC (permalink / raw) To: Juri Linkov; +Cc: michael_heerdegen, emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-06 19:21 ` Tabs Eli Zaretskii @ 2019-10-06 19:58 ` Juri Linkov 2019-10-07 16:05 ` Tabs Eli Zaretskii 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-10-06 19:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: michael_heerdegen, emacs-devel >> > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-06 19:58 ` Tabs Juri Linkov @ 2019-10-07 16:05 ` Eli Zaretskii 2019-10-07 16:53 ` Tabs Michael Heerdegen 2019-10-07 19:11 ` Tabs Juri Linkov 0 siblings, 2 replies; 209+ messages in thread From: Eli Zaretskii @ 2019-10-07 16:05 UTC (permalink / raw) To: Juri Linkov; +Cc: michael_heerdegen, emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-07 16:05 ` Tabs Eli Zaretskii @ 2019-10-07 16:53 ` Michael Heerdegen 2019-10-07 17:12 ` Tabs Ergus 2019-10-07 17:58 ` Tabs Eli Zaretskii 2019-10-07 19:11 ` Tabs Juri Linkov 1 sibling, 2 replies; 209+ messages in thread From: Michael Heerdegen @ 2019-10-07 16:53 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel, Juri Linkov 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-07 16:53 ` Tabs Michael Heerdegen @ 2019-10-07 17:12 ` Ergus 2019-10-07 18:24 ` Tabs Eli Zaretskii 2019-10-07 17:58 ` Tabs Eli Zaretskii 1 sibling, 1 reply; 209+ messages in thread From: Ergus @ 2019-10-07 17:12 UTC (permalink / raw) To: Michael Heerdegen; +Cc: Eli Zaretskii, emacs-devel, Juri Linkov 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-07 17:12 ` Tabs Ergus @ 2019-10-07 18:24 ` Eli Zaretskii 2019-10-07 19:28 ` Tabs Ergus 0 siblings, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-07 18:24 UTC (permalink / raw) To: Ergus; +Cc: michael_heerdegen, juri, emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-07 18:24 ` Tabs Eli Zaretskii @ 2019-10-07 19:28 ` Ergus 2019-10-08 7:42 ` Tabs Eli Zaretskii 0 siblings, 1 reply; 209+ messages in thread From: Ergus @ 2019-10-07 19:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: michael_heerdegen, juri, emacs-devel 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. > ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-07 19:28 ` Tabs Ergus @ 2019-10-08 7:42 ` Eli Zaretskii 2019-10-08 8:56 ` Tabs Ergus 0 siblings, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-08 7:42 UTC (permalink / raw) To: Ergus; +Cc: michael_heerdegen, emacs-devel, juri > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-08 7:42 ` Tabs Eli Zaretskii @ 2019-10-08 8:56 ` Ergus 2019-10-08 9:18 ` Tabs Eli Zaretskii 0 siblings, 1 reply; 209+ messages in thread From: Ergus @ 2019-10-08 8:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: michael_heerdegen, emacs-devel, juri [-- 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 --] ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-08 8:56 ` Tabs Ergus @ 2019-10-08 9:18 ` Eli Zaretskii 2019-10-08 13:58 ` Tabs Eli Zaretskii 2019-10-08 16:00 ` Tabs Ergus 0 siblings, 2 replies; 209+ messages in thread From: Eli Zaretskii @ 2019-10-08 9:18 UTC (permalink / raw) To: Ergus; +Cc: michael_heerdegen, juri, emacs-devel > 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". ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-08 9:18 ` Tabs Eli Zaretskii @ 2019-10-08 13:58 ` Eli Zaretskii 2019-10-08 16:00 ` Tabs Ergus 1 sibling, 0 replies; 209+ messages in thread From: Eli Zaretskii @ 2019-10-08 13:58 UTC (permalink / raw) To: spacibba; +Cc: michael_heerdegen, emacs-devel, juri > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-08 9:18 ` Tabs Eli Zaretskii 2019-10-08 13:58 ` Tabs Eli Zaretskii @ 2019-10-08 16:00 ` Ergus 2019-10-08 16:18 ` Tabs Eli Zaretskii 1 sibling, 1 reply; 209+ messages in thread From: Ergus @ 2019-10-08 16:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: michael_heerdegen, emacs-devel, juri 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-08 16:00 ` Tabs Ergus @ 2019-10-08 16:18 ` Eli Zaretskii 2019-10-08 16:40 ` Tabs Ergus 0 siblings, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-08 16:18 UTC (permalink / raw) To: Ergus; +Cc: michael_heerdegen, juri, emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-08 16:18 ` Tabs Eli Zaretskii @ 2019-10-08 16:40 ` Ergus 2019-10-08 17:03 ` Tabs Eli Zaretskii 0 siblings, 1 reply; 209+ messages in thread From: Ergus @ 2019-10-08 16:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: michael_heerdegen, juri, emacs-devel [-- 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] ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-08 16:40 ` Tabs Ergus @ 2019-10-08 17:03 ` Eli Zaretskii 2019-10-08 23:43 ` Tabs Ergus 0 siblings, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-08 17:03 UTC (permalink / raw) To: Ergus; +Cc: michael_heerdegen, emacs-devel, juri > 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-08 17:03 ` Tabs Eli Zaretskii @ 2019-10-08 23:43 ` Ergus 2019-10-09 8:37 ` Tabs Eli Zaretskii 0 siblings, 1 reply; 209+ messages in thread From: Ergus @ 2019-10-08 23:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: michael_heerdegen, juri, emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-08 23:43 ` Tabs Ergus @ 2019-10-09 8:37 ` Eli Zaretskii 2019-10-09 10:39 ` Tabs Ergus 0 siblings, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-09 8:37 UTC (permalink / raw) To: Ergus; +Cc: michael_heerdegen, emacs-devel, juri > 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; ^ permalink raw reply related [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-09 8:37 ` Tabs Eli Zaretskii @ 2019-10-09 10:39 ` Ergus 2019-10-09 11:35 ` Tabs Eli Zaretskii 0 siblings, 1 reply; 209+ messages in thread From: Ergus @ 2019-10-09 10:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: michael_heerdegen, juri, emacs-devel 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-09 10:39 ` Tabs Ergus @ 2019-10-09 11:35 ` Eli Zaretskii 2019-10-09 12:05 ` Tabs Ergus 0 siblings, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-09 11:35 UTC (permalink / raw) To: Ergus; +Cc: michael_heerdegen, emacs-devel, juri > 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 ^ permalink raw reply related [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-09 11:35 ` Tabs Eli Zaretskii @ 2019-10-09 12:05 ` Ergus 2019-10-09 12:18 ` Tabs Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 209+ messages in thread From: Ergus @ 2019-10-09 12:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: michael_heerdegen, juri, emacs-devel 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 :(. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-09 12:05 ` Tabs Ergus @ 2019-10-09 12:18 ` Eli Zaretskii 2019-10-09 12:32 ` Tabs Eli Zaretskii 2019-10-09 12:36 ` Tabs Eli Zaretskii 2 siblings, 0 replies; 209+ messages in thread From: Eli Zaretskii @ 2019-10-09 12:18 UTC (permalink / raw) To: Ergus; +Cc: michael_heerdegen, emacs-devel, juri > 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))) ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-09 12:05 ` Tabs Ergus 2019-10-09 12:18 ` Tabs Eli Zaretskii @ 2019-10-09 12:32 ` Eli Zaretskii 2019-10-09 18:12 ` Tabs martin rudalics 2019-10-09 12:36 ` Tabs Eli Zaretskii 2 siblings, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-09 12:32 UTC (permalink / raw) To: martin rudalics; +Cc: Ergus, emacs-devel, juri 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-09 12:32 ` Tabs Eli Zaretskii @ 2019-10-09 18:12 ` martin rudalics 2019-10-09 18:46 ` Tabs Eli Zaretskii 0 siblings, 1 reply; 209+ messages in thread From: martin rudalics @ 2019-10-09 18:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Ergus, emacs-devel, juri > 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-09 18:12 ` Tabs martin rudalics @ 2019-10-09 18:46 ` Eli Zaretskii 2019-10-10 9:15 ` Tabs martin rudalics 0 siblings, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-09 18:46 UTC (permalink / raw) To: martin rudalics; +Cc: spacibba, emacs-devel, juri > 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)... ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-09 18:46 ` Tabs Eli Zaretskii @ 2019-10-10 9:15 ` martin rudalics 2019-10-10 9:59 ` Tabs Eli Zaretskii 0 siblings, 1 reply; 209+ messages in thread From: martin rudalics @ 2019-10-10 9:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: spacibba, juri, emacs-devel > 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 9:15 ` Tabs martin rudalics @ 2019-10-10 9:59 ` Eli Zaretskii 2019-10-10 10:38 ` Tabs martin rudalics 0 siblings, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-10 9:59 UTC (permalink / raw) To: martin rudalics; +Cc: spacibba, juri, emacs-devel > 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 9:59 ` Tabs Eli Zaretskii @ 2019-10-10 10:38 ` martin rudalics 2019-10-10 11:33 ` Tabs Eli Zaretskii 0 siblings, 1 reply; 209+ messages in thread From: martin rudalics @ 2019-10-10 10:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: spacibba, juri, emacs-devel > 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 10:38 ` Tabs martin rudalics @ 2019-10-10 11:33 ` Eli Zaretskii 2019-10-10 11:53 ` Tabs Eli Zaretskii 0 siblings, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-10 11:33 UTC (permalink / raw) To: martin rudalics; +Cc: spacibba, juri, emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 11:33 ` Tabs Eli Zaretskii @ 2019-10-10 11:53 ` Eli Zaretskii 2019-10-10 14:58 ` Tabs martin rudalics 0 siblings, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-10 11:53 UTC (permalink / raw) To: rudalics; +Cc: spacibba, emacs-devel, juri > 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 11:53 ` Tabs Eli Zaretskii @ 2019-10-10 14:58 ` martin rudalics 0 siblings, 0 replies; 209+ messages in thread From: martin rudalics @ 2019-10-10 14:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: spacibba, emacs-devel, juri > 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-09 12:05 ` Tabs Ergus 2019-10-09 12:18 ` Tabs Eli Zaretskii 2019-10-09 12:32 ` Tabs Eli Zaretskii @ 2019-10-09 12:36 ` Eli Zaretskii 2019-10-09 13:55 ` Tabs Ergus 2 siblings, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-09 12:36 UTC (permalink / raw) To: Ergus; +Cc: michael_heerdegen, emacs-devel, juri > 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"? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-09 12:36 ` Tabs Eli Zaretskii @ 2019-10-09 13:55 ` Ergus 2019-10-09 14:21 ` Tabs Eli Zaretskii 0 siblings, 1 reply; 209+ messages in thread From: Ergus @ 2019-10-09 13:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: michael_heerdegen, juri, emacs-devel 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-09 13:55 ` Tabs Ergus @ 2019-10-09 14:21 ` Eli Zaretskii 2019-10-09 15:15 ` Tabs Ergus 2019-10-09 22:37 ` Tabs Juri Linkov 0 siblings, 2 replies; 209+ messages in thread From: Eli Zaretskii @ 2019-10-09 14:21 UTC (permalink / raw) To: Ergus, juri; +Cc: michael_heerdegen, emacs-devel > 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-09 14:21 ` Tabs Eli Zaretskii @ 2019-10-09 15:15 ` Ergus 2019-10-09 15:35 ` Tabs Eli Zaretskii 2019-10-09 22:37 ` Tabs Juri Linkov 1 sibling, 1 reply; 209+ messages in thread From: Ergus @ 2019-10-09 15:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: juri, michael_heerdegen, emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-09 15:15 ` Tabs Ergus @ 2019-10-09 15:35 ` Eli Zaretskii 2019-10-10 11:52 ` Tabs Eli Zaretskii 0 siblings, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-09 15:35 UTC (permalink / raw) To: Ergus; +Cc: michael_heerdegen, emacs-devel, juri > 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-09 15:35 ` Tabs Eli Zaretskii @ 2019-10-10 11:52 ` Eli Zaretskii 2019-10-10 13:12 ` Tabs Ergus 2019-10-10 13:29 ` Tabs Ergus 0 siblings, 2 replies; 209+ messages in thread From: Eli Zaretskii @ 2019-10-10 11:52 UTC (permalink / raw) To: spacibba; +Cc: juri, emacs-devel Please try the latest master, I made a change which could potentially affect the issue. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 11:52 ` Tabs Eli Zaretskii @ 2019-10-10 13:12 ` Ergus 2019-10-10 13:54 ` Tabs Eli Zaretskii 2019-10-10 13:29 ` Tabs Ergus 1 sibling, 1 reply; 209+ messages in thread From: Ergus @ 2019-10-10 13:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: juri, emacs-devel 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. > ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 13:12 ` Tabs Ergus @ 2019-10-10 13:54 ` Eli Zaretskii 2019-10-10 14:19 ` Tabs Ergus 0 siblings, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-10 13:54 UTC (permalink / raw) To: Ergus; +Cc: emacs-devel, juri > 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 13:54 ` Tabs Eli Zaretskii @ 2019-10-10 14:19 ` Ergus 2019-10-10 15:03 ` Tabs Eli Zaretskii 2019-10-16 9:16 ` Tabs martin rudalics 0 siblings, 2 replies; 209+ messages in thread From: Ergus @ 2019-10-10 14:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: juri, emacs-devel 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 14:19 ` Tabs Ergus @ 2019-10-10 15:03 ` Eli Zaretskii 2019-10-10 15:35 ` Tabs martin rudalics 2019-10-16 9:16 ` Tabs martin rudalics 1 sibling, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-10 15:03 UTC (permalink / raw) To: Ergus; +Cc: emacs-devel, juri > 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 15:03 ` Tabs Eli Zaretskii @ 2019-10-10 15:35 ` martin rudalics 2019-10-10 15:46 ` Tabs Ergus 0 siblings, 1 reply; 209+ messages in thread From: martin rudalics @ 2019-10-10 15:35 UTC (permalink / raw) To: Eli Zaretskii, Ergus; +Cc: juri, emacs-devel > 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 15:35 ` Tabs martin rudalics @ 2019-10-10 15:46 ` Ergus 2019-10-10 18:14 ` Tabs martin rudalics 0 siblings, 1 reply; 209+ messages in thread From: Ergus @ 2019-10-10 15:46 UTC (permalink / raw) To: martin rudalics; +Cc: Eli Zaretskii, emacs-devel, juri 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 15:46 ` Tabs Ergus @ 2019-10-10 18:14 ` martin rudalics 2019-10-10 18:26 ` Tabs Eli Zaretskii 0 siblings, 1 reply; 209+ messages in thread From: martin rudalics @ 2019-10-10 18:14 UTC (permalink / raw) To: Ergus; +Cc: Eli Zaretskii, juri, emacs-devel > 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 18:14 ` Tabs martin rudalics @ 2019-10-10 18:26 ` Eli Zaretskii 2019-10-11 8:18 ` Tabs martin rudalics 0 siblings, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-10 18:26 UTC (permalink / raw) To: martin rudalics; +Cc: spacibba, emacs-devel, juri > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 18:26 ` Tabs Eli Zaretskii @ 2019-10-11 8:18 ` martin rudalics 2019-10-11 9:16 ` Tabs Eli Zaretskii 0 siblings, 1 reply; 209+ messages in thread From: martin rudalics @ 2019-10-11 8:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: spacibba, juri, emacs-devel > 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-11 8:18 ` Tabs martin rudalics @ 2019-10-11 9:16 ` Eli Zaretskii 0 siblings, 0 replies; 209+ messages in thread From: Eli Zaretskii @ 2019-10-11 9:16 UTC (permalink / raw) To: martin rudalics; +Cc: spacibba, juri, emacs-devel > 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). ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 14:19 ` Tabs Ergus 2019-10-10 15:03 ` Tabs Eli Zaretskii @ 2019-10-16 9:16 ` martin rudalics 1 sibling, 0 replies; 209+ messages in thread From: martin rudalics @ 2019-10-16 9:16 UTC (permalink / raw) To: Ergus, Eli Zaretskii; +Cc: emacs-devel, juri >> 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 11:52 ` Tabs Eli Zaretskii 2019-10-10 13:12 ` Tabs Ergus @ 2019-10-10 13:29 ` Ergus 2019-10-10 13:47 ` Tabs Eli Zaretskii 1 sibling, 1 reply; 209+ messages in thread From: Ergus @ 2019-10-10 13:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: juri, emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 13:29 ` Tabs Ergus @ 2019-10-10 13:47 ` Eli Zaretskii 2019-10-10 14:15 ` Tabs Ergus 2019-10-10 14:40 ` Tabs Ergus 0 siblings, 2 replies; 209+ messages in thread From: Eli Zaretskii @ 2019-10-10 13:47 UTC (permalink / raw) To: Ergus; +Cc: emacs-devel, juri > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 13:47 ` Tabs Eli Zaretskii @ 2019-10-10 14:15 ` Ergus 2019-10-10 14:40 ` Tabs Ergus 1 sibling, 0 replies; 209+ messages in thread From: Ergus @ 2019-10-10 14:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel, juri 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 13:47 ` Tabs Eli Zaretskii 2019-10-10 14:15 ` Tabs Ergus @ 2019-10-10 14:40 ` Ergus 2019-10-10 15:11 ` Tabs Eli Zaretskii 2019-10-10 20:54 ` Tabs Juri Linkov 1 sibling, 2 replies; 209+ messages in thread From: Ergus @ 2019-10-10 14:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel, juri 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 14:40 ` Tabs Ergus @ 2019-10-10 15:11 ` Eli Zaretskii 2019-10-10 20:54 ` Tabs Juri Linkov 1 sibling, 0 replies; 209+ messages in thread From: Eli Zaretskii @ 2019-10-10 15:11 UTC (permalink / raw) To: Ergus; +Cc: juri, emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 14:40 ` Tabs Ergus 2019-10-10 15:11 ` Tabs Eli Zaretskii @ 2019-10-10 20:54 ` Juri Linkov 2019-10-11 7:08 ` Tabs Eli Zaretskii 1 sibling, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-10-10 20:54 UTC (permalink / raw) To: Ergus; +Cc: Eli Zaretskii, emacs-devel >>> 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 20:54 ` Tabs Juri Linkov @ 2019-10-11 7:08 ` Eli Zaretskii 2019-10-13 20:57 ` Tabs Juri Linkov 0 siblings, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-11 7:08 UTC (permalink / raw) To: Juri Linkov; +Cc: spacibba, emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-11 7:08 ` Tabs Eli Zaretskii @ 2019-10-13 20:57 ` Juri Linkov 0 siblings, 0 replies; 209+ messages in thread From: Juri Linkov @ 2019-10-13 20:57 UTC (permalink / raw) To: Eli Zaretskii; +Cc: spacibba, emacs-devel >> 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-09 14:21 ` Tabs Eli Zaretskii 2019-10-09 15:15 ` Tabs Ergus @ 2019-10-09 22:37 ` Juri Linkov 2019-10-10 7:51 ` Tabs Eli Zaretskii 1 sibling, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-10-09 22:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: michael_heerdegen, Ergus, emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-09 22:37 ` Tabs Juri Linkov @ 2019-10-10 7:51 ` Eli Zaretskii 2019-10-10 22:35 ` Tabs Juri Linkov 0 siblings, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-10 7:51 UTC (permalink / raw) To: Juri Linkov; +Cc: michael_heerdegen, spacibba, emacs-devel > 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 7:51 ` Tabs Eli Zaretskii @ 2019-10-10 22:35 ` Juri Linkov 2019-10-11 8:18 ` Tabs martin rudalics 2019-10-11 9:20 ` Tabs Eli Zaretskii 0 siblings, 2 replies; 209+ messages in thread From: Juri Linkov @ 2019-10-10 22:35 UTC (permalink / raw) To: Eli Zaretskii; +Cc: michael_heerdegen, spacibba, emacs-devel >> > 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; ^ permalink raw reply related [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 22:35 ` Tabs Juri Linkov @ 2019-10-11 8:18 ` martin rudalics 2019-10-12 22:42 ` Tabs Juri Linkov 2019-10-11 9:20 ` Tabs Eli Zaretskii 1 sibling, 1 reply; 209+ messages in thread From: martin rudalics @ 2019-10-11 8:18 UTC (permalink / raw) To: Juri Linkov, Eli Zaretskii; +Cc: michael_heerdegen, spacibba, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-11 8:18 ` Tabs martin rudalics @ 2019-10-12 22:42 ` Juri Linkov 2019-10-13 8:16 ` Tabs martin rudalics 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-10-12 22:42 UTC (permalink / raw) To: martin rudalics; +Cc: michael_heerdegen, Eli Zaretskii, spacibba, emacs-devel [-- 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-12 22:42 ` Tabs Juri Linkov @ 2019-10-13 8:16 ` martin rudalics 2019-10-14 18:02 ` Tabs martin rudalics 2019-10-14 19:00 ` Tabs Juri Linkov 0 siblings, 2 replies; 209+ messages in thread From: martin rudalics @ 2019-10-13 8:16 UTC (permalink / raw) To: Juri Linkov; +Cc: michael_heerdegen, Eli Zaretskii, spacibba, emacs-devel > 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-13 8:16 ` Tabs martin rudalics @ 2019-10-14 18:02 ` martin rudalics 2019-10-14 18:29 ` Tabs Eli Zaretskii 2019-10-14 19:35 ` Tabs Juri Linkov 2019-10-14 19:00 ` Tabs Juri Linkov 1 sibling, 2 replies; 209+ messages in thread From: martin rudalics @ 2019-10-14 18:02 UTC (permalink / raw) To: Juri Linkov; +Cc: michael_heerdegen, Eli Zaretskii, spacibba, emacs-devel [-- 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 (); ^ permalink raw reply related [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-14 18:02 ` Tabs martin rudalics @ 2019-10-14 18:29 ` Eli Zaretskii 2019-10-15 9:47 ` Tabs martin rudalics 2019-10-14 19:35 ` Tabs Juri Linkov 1 sibling, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-14 18:29 UTC (permalink / raw) To: martin rudalics; +Cc: michael_heerdegen, spacibba, emacs-devel, juri > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-14 18:29 ` Tabs Eli Zaretskii @ 2019-10-15 9:47 ` martin rudalics 0 siblings, 0 replies; 209+ messages in thread From: martin rudalics @ 2019-10-15 9:47 UTC (permalink / raw) To: Eli Zaretskii; +Cc: michael_heerdegen, spacibba, juri, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-14 18:02 ` Tabs martin rudalics 2019-10-14 18:29 ` Tabs Eli Zaretskii @ 2019-10-14 19:35 ` Juri Linkov 2019-10-14 21:17 ` Tabs T.V Raman 2019-10-15 9:47 ` Tabs martin rudalics 1 sibling, 2 replies; 209+ messages in thread From: Juri Linkov @ 2019-10-14 19:35 UTC (permalink / raw) To: martin rudalics; +Cc: michael_heerdegen, Eli Zaretskii, spacibba, emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-14 19:35 ` Tabs Juri Linkov @ 2019-10-14 21:17 ` T.V Raman 2019-10-14 21:53 ` Tabs Phil Sainty 2019-10-15 6:12 ` Tabs Eli Zaretskii 2019-10-15 9:47 ` Tabs martin rudalics 1 sibling, 2 replies; 209+ messages in thread From: T.V Raman @ 2019-10-14 21:17 UTC (permalink / raw) To: Juri Linkov Cc: martin rudalics, michael_heerdegen, Eli Zaretskii, spacibba, emacs-devel 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-14 21:17 ` Tabs T.V Raman @ 2019-10-14 21:53 ` Phil Sainty 2019-10-14 22:00 ` Tabs Juri Linkov 2019-10-15 6:12 ` Tabs Eli Zaretskii 1 sibling, 1 reply; 209+ messages in thread From: Phil Sainty @ 2019-10-14 21:53 UTC (permalink / raw) To: T.V Raman Cc: spacibba, michael_heerdegen, emacs-devel, martin rudalics, Eli Zaretskii, Juri Linkov 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-14 21:53 ` Tabs Phil Sainty @ 2019-10-14 22:00 ` Juri Linkov 2019-10-14 22:36 ` Tabs T.V Raman 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-10-14 22:00 UTC (permalink / raw) To: Phil Sainty Cc: spacibba, michael_heerdegen, emacs-devel, martin rudalics, Eli Zaretskii, T.V Raman >> 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-14 22:00 ` Tabs Juri Linkov @ 2019-10-14 22:36 ` T.V Raman 2019-10-15 20:39 ` Tabs Juri Linkov 0 siblings, 1 reply; 209+ messages in thread From: T.V Raman @ 2019-10-14 22:36 UTC (permalink / raw) To: juri Cc: psainty, raman, rudalics, michael_heerdegen, eliz, spacibba, emacs-devel 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-14 22:36 ` Tabs T.V Raman @ 2019-10-15 20:39 ` Juri Linkov 2019-10-16 0:14 ` Tabs T.V Raman 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-10-15 20:39 UTC (permalink / raw) To: T.V Raman Cc: spacibba, psainty, emacs-devel, rudalics, michael_heerdegen, eliz > 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-15 20:39 ` Tabs Juri Linkov @ 2019-10-16 0:14 ` T.V Raman 0 siblings, 0 replies; 209+ messages in thread From: T.V Raman @ 2019-10-16 0:14 UTC (permalink / raw) To: Juri Linkov Cc: spacibba, psainty, emacs-devel, rudalics, michael_heerdegen, eliz 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? > -- ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-14 21:17 ` Tabs T.V Raman 2019-10-14 21:53 ` Tabs Phil Sainty @ 2019-10-15 6:12 ` Eli Zaretskii 1 sibling, 0 replies; 209+ messages in thread From: Eli Zaretskii @ 2019-10-15 6:12 UTC (permalink / raw) To: T.V Raman; +Cc: michael_heerdegen, rudalics, spacibba, emacs-devel, juri > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-14 19:35 ` Tabs Juri Linkov 2019-10-14 21:17 ` Tabs T.V Raman @ 2019-10-15 9:47 ` martin rudalics 2019-10-15 17:45 ` Tabs Juri Linkov 1 sibling, 1 reply; 209+ messages in thread From: martin rudalics @ 2019-10-15 9:47 UTC (permalink / raw) To: Juri Linkov; +Cc: michael_heerdegen, Eli Zaretskii, spacibba, emacs-devel >> (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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-15 9:47 ` Tabs martin rudalics @ 2019-10-15 17:45 ` Juri Linkov 2019-10-16 9:16 ` Tabs martin rudalics 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-10-15 17:45 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-15 17:45 ` Tabs Juri Linkov @ 2019-10-16 9:16 ` martin rudalics 0 siblings, 0 replies; 209+ messages in thread From: martin rudalics @ 2019-10-16 9:16 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-13 8:16 ` Tabs martin rudalics 2019-10-14 18:02 ` Tabs martin rudalics @ 2019-10-14 19:00 ` Juri Linkov 2019-10-15 9:47 ` Tabs martin rudalics 1 sibling, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-10-14 19:00 UTC (permalink / raw) To: martin rudalics; +Cc: Eli Zaretskii, emacs-devel [-- 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); } ^ permalink raw reply related [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-14 19:00 ` Tabs Juri Linkov @ 2019-10-15 9:47 ` martin rudalics 0 siblings, 0 replies; 209+ messages in thread From: martin rudalics @ 2019-10-15 9:47 UTC (permalink / raw) To: Juri Linkov; +Cc: Eli Zaretskii, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 22:35 ` Tabs Juri Linkov 2019-10-11 8:18 ` Tabs martin rudalics @ 2019-10-11 9:20 ` Eli Zaretskii 2019-10-12 22:47 ` Tabs Juri Linkov 1 sibling, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-11 9:20 UTC (permalink / raw) To: Juri Linkov; +Cc: michael_heerdegen, spacibba, emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-11 9:20 ` Tabs Eli Zaretskii @ 2019-10-12 22:47 ` Juri Linkov 2019-10-13 6:51 ` Tabs Eli Zaretskii 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-10-12 22:47 UTC (permalink / raw) To: Eli Zaretskii; +Cc: michael_heerdegen, spacibba, emacs-devel >> @@ -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; ^ permalink raw reply related [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-12 22:47 ` Tabs Juri Linkov @ 2019-10-13 6:51 ` Eli Zaretskii 2019-10-13 20:48 ` Tabs Juri Linkov 0 siblings, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-13 6:51 UTC (permalink / raw) To: Juri Linkov; +Cc: michael_heerdegen, spacibba, emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-13 6:51 ` Tabs Eli Zaretskii @ 2019-10-13 20:48 ` Juri Linkov 2019-10-13 21:09 ` Tabs Eli Zaretskii 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-10-13 20:48 UTC (permalink / raw) To: Eli Zaretskii; +Cc: michael_heerdegen, spacibba, emacs-devel >> 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-13 20:48 ` Tabs Juri Linkov @ 2019-10-13 21:09 ` Eli Zaretskii 2019-10-13 21:33 ` Tabs Juri Linkov 0 siblings, 1 reply; 209+ messages in thread From: Eli Zaretskii @ 2019-10-13 21:09 UTC (permalink / raw) To: Juri Linkov; +Cc: michael_heerdegen, spacibba, emacs-devel > 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-13 21:09 ` Tabs Eli Zaretskii @ 2019-10-13 21:33 ` Juri Linkov 2019-10-14 8:24 ` Tabs Eli Zaretskii 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-10-13 21:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: michael_heerdegen, spacibba, emacs-devel >> >> 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-13 21:33 ` Tabs Juri Linkov @ 2019-10-14 8:24 ` Eli Zaretskii 0 siblings, 0 replies; 209+ messages in thread From: Eli Zaretskii @ 2019-10-14 8:24 UTC (permalink / raw) To: Juri Linkov; +Cc: michael_heerdegen, spacibba, emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-07 16:53 ` Tabs Michael Heerdegen 2019-10-07 17:12 ` Tabs Ergus @ 2019-10-07 17:58 ` Eli Zaretskii 1 sibling, 0 replies; 209+ messages in thread From: Eli Zaretskii @ 2019-10-07 17:58 UTC (permalink / raw) To: Michael Heerdegen; +Cc: emacs-devel, juri > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-07 16:05 ` Tabs Eli Zaretskii 2019-10-07 16:53 ` Tabs Michael Heerdegen @ 2019-10-07 19:11 ` Juri Linkov 1 sibling, 0 replies; 209+ messages in thread From: Juri Linkov @ 2019-10-07 19:11 UTC (permalink / raw) To: Eli Zaretskii; +Cc: michael_heerdegen, emacs-devel > Please try the latest master, I hope this is now fixed. Thanks, I confirm this is fixed. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-06 17:55 ` Tabs Juri Linkov 2019-10-06 18:05 ` Tabs Juri Linkov @ 2019-10-06 18:38 ` Michael Heerdegen 2019-10-06 19:03 ` Tabs Eli Zaretskii 2019-10-06 18:56 ` Tabs Eli Zaretskii 2 siblings, 1 reply; 209+ messages in thread From: Michael Heerdegen @ 2019-10-06 18:38 UTC (permalink / raw) To: Juri Linkov; +Cc: Eli Zaretskii, emacs-devel 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-06 18:38 ` Tabs Michael Heerdegen @ 2019-10-06 19:03 ` Eli Zaretskii 0 siblings, 0 replies; 209+ messages in thread From: Eli Zaretskii @ 2019-10-06 19:03 UTC (permalink / raw) To: Michael Heerdegen; +Cc: emacs-devel, juri > 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-06 17:55 ` Tabs Juri Linkov 2019-10-06 18:05 ` Tabs Juri Linkov 2019-10-06 18:38 ` Tabs Michael Heerdegen @ 2019-10-06 18:56 ` Eli Zaretskii 2 siblings, 0 replies; 209+ messages in thread From: Eli Zaretskii @ 2019-10-06 18:56 UTC (permalink / raw) To: Juri Linkov; +Cc: michael_heerdegen, emacs-devel > 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-06 8:22 ` Tabs Michael Heerdegen 2019-10-06 12:09 ` Tabs Michael Heerdegen @ 2019-10-08 19:15 ` Michael Heerdegen 2019-10-09 22:48 ` Tabs Juri Linkov 1 sibling, 1 reply; 209+ messages in thread From: Michael Heerdegen @ 2019-10-08 19:15 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-08 19:15 ` Tabs Michael Heerdegen @ 2019-10-09 22:48 ` Juri Linkov 2019-10-10 11:06 ` Tabs Michael Heerdegen 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-10-09 22:48 UTC (permalink / raw) To: Michael Heerdegen; +Cc: emacs-devel >> > 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-09 22:48 ` Tabs Juri Linkov @ 2019-10-10 11:06 ` Michael Heerdegen 2019-10-10 20:59 ` Tabs Juri Linkov 0 siblings, 1 reply; 209+ messages in thread From: Michael Heerdegen @ 2019-10-10 11:06 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 11:06 ` Tabs Michael Heerdegen @ 2019-10-10 20:59 ` Juri Linkov 2019-10-13 9:32 ` Tabs Michael Heerdegen 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-10-10 20:59 UTC (permalink / raw) To: Michael Heerdegen; +Cc: emacs-devel >> 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-10 20:59 ` Tabs Juri Linkov @ 2019-10-13 9:32 ` Michael Heerdegen 2019-10-13 20:24 ` Tabs Juri Linkov 0 siblings, 1 reply; 209+ messages in thread From: Michael Heerdegen @ 2019-10-13 9:32 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-13 9:32 ` Tabs Michael Heerdegen @ 2019-10-13 20:24 ` Juri Linkov 2019-10-15 14:42 ` Tabs Michael Heerdegen 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-10-13 20:24 UTC (permalink / raw) To: Michael Heerdegen; +Cc: emacs-devel >> > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-13 20:24 ` Tabs Juri Linkov @ 2019-10-15 14:42 ` Michael Heerdegen 2019-10-19 22:51 ` Tabs Juri Linkov 0 siblings, 1 reply; 209+ messages in thread From: Michael Heerdegen @ 2019-10-15 14:42 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-15 14:42 ` Tabs Michael Heerdegen @ 2019-10-19 22:51 ` Juri Linkov 2019-10-25 11:19 ` Tabs Michael Heerdegen 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-10-19 22:51 UTC (permalink / raw) To: Michael Heerdegen; +Cc: emacs-devel >> >> 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? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-19 22:51 ` Tabs Juri Linkov @ 2019-10-25 11:19 ` Michael Heerdegen 2019-10-26 22:40 ` Tabs Juri Linkov 0 siblings, 1 reply; 209+ messages in thread From: Michael Heerdegen @ 2019-10-25 11:19 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-25 11:19 ` Tabs Michael Heerdegen @ 2019-10-26 22:40 ` Juri Linkov 2019-10-29 19:09 ` Tabs Michael Heerdegen 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-10-26 22:40 UTC (permalink / raw) To: Michael Heerdegen; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-26 22:40 ` Tabs Juri Linkov @ 2019-10-29 19:09 ` Michael Heerdegen 2019-11-05 23:24 ` Tabs Juri Linkov 0 siblings, 1 reply; 209+ messages in thread From: Michael Heerdegen @ 2019-10-29 19:09 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-10-29 19:09 ` Tabs Michael Heerdegen @ 2019-11-05 23:24 ` Juri Linkov 2019-11-08 18:45 ` Tabs Michael Heerdegen 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-11-05 23:24 UTC (permalink / raw) To: Michael Heerdegen; +Cc: emacs-devel >> 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-11-05 23:24 ` Tabs Juri Linkov @ 2019-11-08 18:45 ` Michael Heerdegen 2019-11-08 19:56 ` Tabs Michael Heerdegen 0 siblings, 1 reply; 209+ messages in thread From: Michael Heerdegen @ 2019-11-08 18:45 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-11-08 18:45 ` Tabs Michael Heerdegen @ 2019-11-08 19:56 ` Michael Heerdegen 2019-11-12 21:31 ` Tabs Juri Linkov 0 siblings, 1 reply; 209+ messages in thread From: Michael Heerdegen @ 2019-11-08 19:56 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-11-08 19:56 ` Tabs Michael Heerdegen @ 2019-11-12 21:31 ` Juri Linkov 2019-11-13 16:47 ` Tabs Michael Heerdegen 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-11-12 21:31 UTC (permalink / raw) To: Michael Heerdegen; +Cc: emacs-devel >> 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-11-12 21:31 ` Tabs Juri Linkov @ 2019-11-13 16:47 ` Michael Heerdegen 2019-11-13 22:10 ` Tabs Juri Linkov 0 siblings, 1 reply; 209+ messages in thread From: Michael Heerdegen @ 2019-11-13 16:47 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-11-13 16:47 ` Tabs Michael Heerdegen @ 2019-11-13 22:10 ` Juri Linkov 2019-11-14 9:20 ` Tabs martin rudalics 0 siblings, 1 reply; 209+ messages in thread From: Juri Linkov @ 2019-11-13 22:10 UTC (permalink / raw) To: Michael Heerdegen; +Cc: emacs-devel >> 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. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2019-11-13 22:10 ` Tabs Juri Linkov @ 2019-11-14 9:20 ` martin rudalics 0 siblings, 0 replies; 209+ messages in thread From: martin rudalics @ 2019-11-14 9:20 UTC (permalink / raw) To: Juri Linkov, Michael Heerdegen; +Cc: emacs-devel >> 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 ^ permalink raw reply [flat|nested] 209+ messages in thread
* Tabs @ 2005-08-22 11:25 Maurizio Colucci 2005-08-22 12:13 ` Tabs Thomas Kjosmoen ` (2 more replies) 0 siblings, 3 replies; 209+ messages in thread From: Maurizio Colucci @ 2005-08-22 11:25 UTC (permalink / raw) Hello, I could not find an appropriate place to file a wish list item, so I am trying here. Would it be possible to add a "tab bar" to emacs, containing the open files? So I could switch between open files with a single click. And it would also be more evident what the open files are. Thanks, farewell Maurizio Colucci ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2005-08-22 11:25 Tabs Maurizio Colucci @ 2005-08-22 12:13 ` Thomas Kjosmoen 2005-08-22 15:48 ` Tabs Aaron S. Hawley 2005-08-23 1:29 ` Tabs Richard M. Stallman 2 siblings, 0 replies; 209+ messages in thread From: Thomas Kjosmoen @ 2005-08-22 12:13 UTC (permalink / raw) Cc: bug-gnu-emacs Hi, Take a look at ECB (http://ecb.sf.net) Good luck On Aug 22, 2005, at 6:25 AM, Maurizio Colucci wrote: > Hello, > > I could not find an appropriate place to file a wish list item, so I > am trying here. > > Would it be possible to add a "tab bar" to emacs, containing the open > files? So I could switch between open files with a single click. And > it would also be more evident what the open files are. > > Thanks, farewell > > Maurizio Colucci > > > _______________________________________________ > Bug-gnu-emacs mailing list > Bug-gnu-emacs@gnu.org > http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs > ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2005-08-22 11:25 Tabs Maurizio Colucci 2005-08-22 12:13 ` Tabs Thomas Kjosmoen @ 2005-08-22 15:48 ` Aaron S. Hawley 2005-08-23 1:29 ` Tabs Richard M. Stallman 2 siblings, 0 replies; 209+ messages in thread From: Aaron S. Hawley @ 2005-08-22 15:48 UTC (permalink / raw) Cc: bug-gnu-emacs This wish was added to <http://www.emacswiki.org/cgi-bin/emacs-en/WishList>, with a response of <http://www.emacswiki.org/cgi-bin/emacs-en/TabBarMode>. The wish list at emacswiki.org is not an official or authorative list. hope that helps, /a On Mon, 22 Aug 2005, Maurizio Colucci wrote: > Hello, > > I could not find an appropriate place to file a wish list item, so I > am trying here. > > Would it be possible to add a "tab bar" to emacs, containing the open > files? So I could switch between open files with a single click. And > it would also be more evident what the open files are. > > Thanks, farewell > > Maurizio Colucci ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2005-08-22 11:25 Tabs Maurizio Colucci 2005-08-22 12:13 ` Tabs Thomas Kjosmoen 2005-08-22 15:48 ` Tabs Aaron S. Hawley @ 2005-08-23 1:29 ` Richard M. Stallman 2005-08-23 10:49 ` Tabs Maurizio Colucci 2 siblings, 1 reply; 209+ messages in thread From: Richard M. Stallman @ 2005-08-23 1:29 UTC (permalink / raw) Cc: bug-gnu-emacs Would it be possible to add a "tab bar" to emacs, containing the open files? So I could switch between open files with a single click. And it would also be more evident what the open files are. People often have dozens, even hundreds, of buffers in one Emacs, so how would there be room for so many tabs? ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2005-08-23 1:29 ` Tabs Richard M. Stallman @ 2005-08-23 10:49 ` Maurizio Colucci 2005-08-24 10:32 ` Tabs Richard M. Stallman 0 siblings, 1 reply; 209+ messages in thread From: Maurizio Colucci @ 2005-08-23 10:49 UTC (permalink / raw) Cc: bug-gnu-emacs 2005/8/23, Richard M. Stallman <rms@gnu.org>: > Would it be possible to add a "tab bar" to emacs, containing the open > files? So I could switch between open files with a single click. And > it would also be more evident what the open files are. > > People often have dozens, even hundreds, of buffers in one Emacs, > so how would there be room for so many tabs? Maybe you could just show the N most recent buffers that fit in the tabBar. To switch to a less recent buffer you could still use C-c b. As an added bonus, we could sort the tabBar by recent usage. This way, having many open files is not so expensive anymore. And frequently toggling between two files becomes a very cheap operation. Maurizio ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2005-08-23 10:49 ` Tabs Maurizio Colucci @ 2005-08-24 10:32 ` Richard M. Stallman 0 siblings, 0 replies; 209+ messages in thread From: Richard M. Stallman @ 2005-08-24 10:32 UTC (permalink / raw) Cc: bug-gnu-emacs Maybe you could just show the N most recent buffers that fit in the tabBar. To switch to a less recent buffer you could still use C-c b. If someone implements it and people like it, we could install it. ^ permalink raw reply [flat|nested] 209+ messages in thread
* Tabs @ 2003-08-15 22:35 Paul 2003-08-15 23:23 ` Tabs Marcus Frings 0 siblings, 1 reply; 209+ messages in thread From: Paul @ 2003-08-15 22:35 UTC (permalink / raw) Whenever I start Emacs I have to set tab stops with "M-x edit-tab-stops" to get 4 columns per tabs. Is there any way to set this it once and not have to keep redoing it? Thanks Paul ^ permalink raw reply [flat|nested] 209+ messages in thread
* Re: Tabs 2003-08-15 22:35 Tabs Paul @ 2003-08-15 23:23 ` Marcus Frings 0 siblings, 0 replies; 209+ messages in thread From: Marcus Frings @ 2003-08-15 23:23 UTC (permalink / raw) * "Paul" <pault@HiWAAY.net> wrote: > Whenever I start Emacs I have to set tab stops with "M-x edit-tab-stops" to > get 4 columns per tabs. Is there any way to set this it once and not have to > keep redoing it? ,----[ C-h v tab-stop-list ] | tab-stop-list's value is | (8 16 24 32 40 48 56 64 72 80 88 96 104 112 120) | | Documentation: | *List of tab stop positions used by `tab-to-tab-stop'. | This should be a list of integers, ordered from smallest to largest. | | You can customize this variable. | | Defined in `indent'. `---- Regards, Marcus -- "Und selbst für die Verlorenen, denen Leben und Tod nur noch ein Spott ist, gibt es Dinge, die sie nicht zu ihrem Gespött machen wollen." ^ permalink raw reply [flat|nested] 209+ messages in thread
end of thread, other threads:[~2019-11-14 9:20 UTC | newest] Thread overview: 209+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <<87a7bpysm8.fsf@mail.linkov.net> [not found] ` <<d0768d60-979b-8635-b2b5-474742827552@gmx.at> [not found] ` <<87o903dc2j.fsf@mail.linkov.net> [not found] ` <<CADwFkmmgvyMzc_RZwz-AD6=cpUGfxdx5VZAv2eau4T9dAkTKQg@mail.gmail.com> [not found] ` <<CADtN0WKCHd9fA-tCaGckHFQ59+6ns72NdGrvAdKHss0GLYFZ6g@mail.gmail.com> [not found] ` <<87tv9ubirx.fsf@mail.linkov.net> [not found] ` <<courier.000000005D6DF86C.00005323@protected.rcdrun.com> 2019-09-03 15:24 ` Tabs Drew Adams 2019-09-03 9:20 Tabs Angelo Graziosi -- strict thread matches above, loose matches on Subject: below -- 2019-09-02 13:31 Tabs Angelo Graziosi 2019-09-02 19:46 ` Tabs Juri Linkov 2019-09-03 8:49 ` Tabs Angelo Graziosi 2019-09-03 19:48 ` Tabs Juri Linkov 2019-09-04 8:22 ` Tabs Angelo Graziosi 2019-09-04 19:05 ` Tabs Juri Linkov 2019-09-04 22:41 ` Tabs Angelo Graziosi 2019-09-05 21:40 ` Tabs Angelo Graziosi 2019-09-06 20:16 ` Tabs Angelo Graziosi 2019-09-07 20:28 ` Tabs Juri Linkov 2019-09-08 20:19 ` Tabs Juri Linkov 2019-09-16 7:56 ` Tabs Angelo Graziosi 2019-09-16 8:45 ` Tabs Angelo Graziosi 2019-09-16 20:43 ` Tabs Juri Linkov 2019-10-13 14:49 ` Tabs Angelo Graziosi 2019-10-13 15:07 ` Tabs Eli Zaretskii 2019-10-13 21:09 ` Tabs Angelo Graziosi 2019-10-14 8:23 ` Tabs Eli Zaretskii 2019-10-15 21:38 ` Tabs Angelo Graziosi 2019-10-16 6:53 ` Tabs Eli Zaretskii 2019-10-13 22:08 ` Tabs Juri Linkov 2019-10-14 6:37 ` Tabs Eli Zaretskii 2019-10-15 7:55 ` Tabs Eli Zaretskii 2019-10-15 19:44 ` Tabs Juri Linkov 2019-10-16 6:23 ` Tabs Eli Zaretskii 2019-10-16 22:17 ` Tabs Juri Linkov 2019-10-17 7:17 ` Tabs Eli Zaretskii 2019-10-13 22:01 ` Tabs Juri Linkov 2019-08-31 20:45 Tabs Juri Linkov 2019-09-01 8:12 ` Tabs martin rudalics 2019-09-01 14:40 ` Tabs Eli Zaretskii 2019-09-01 19:57 ` Tabs Juri Linkov 2019-09-02 0:40 ` Tabs Stefan Kangas 2019-09-02 10:11 ` Tabs Elias Mårtenson 2019-09-02 11:16 ` Tabs Dmitry Gutov 2019-09-02 19:27 ` Tabs Juri Linkov 2019-09-03 5:21 ` Tabs Jean Louis 2019-09-03 19:40 ` Tabs Juri Linkov 2019-09-03 20:14 ` Tabs Jean Louis 2019-09-02 19:17 ` Tabs Juri Linkov 2019-09-03 5:45 ` Tabs Yuri Khan 2019-09-03 19:45 ` Tabs Juri Linkov 2019-09-15 16:44 ` Tabs Stefan Kangas 2019-09-15 21:17 ` Tabs Juri Linkov 2019-09-02 2:29 ` Tabs Eli Zaretskii 2019-09-02 19:29 ` Tabs Juri Linkov 2019-09-03 2:27 ` Tabs Eli Zaretskii 2019-09-01 9:28 ` Tabs Alan Mackenzie 2019-09-01 19:18 ` Tabs Juri Linkov 2019-09-01 12:31 ` Tabs Ergus 2019-09-01 19:31 ` Tabs Juri Linkov 2019-09-02 4:51 ` Tabs Ergus 2019-09-02 19:33 ` Tabs Juri Linkov 2019-09-02 21:06 ` Tabs Stefan Monnier 2019-09-03 19:56 ` Tabs Juri Linkov 2019-09-03 2:30 ` Tabs Eli Zaretskii 2019-09-03 19:58 ` Tabs Juri Linkov 2019-09-03 5:39 ` Tabs Ergus 2019-09-05 22:24 ` Tabs Ergus 2019-09-07 20:14 ` Tabs Juri Linkov 2019-09-02 12:41 ` Tabs Stefan Monnier 2019-09-02 19:39 ` Tabs Juri Linkov 2019-09-02 21:03 ` Tabs Stefan Monnier 2019-09-03 12:22 ` Tabs Robert Pluim 2019-09-03 20:21 ` Tabs Juri Linkov 2019-09-15 19:21 ` Tabs Stefan Kangas 2019-09-15 21:32 ` Tabs Juri Linkov 2019-09-16 4:19 ` Tabs Yuri Khan 2019-09-16 20:59 ` Tabs Juri Linkov 2019-09-17 5:29 ` Tabs Yuri Khan 2019-09-17 20:37 ` Tabs Juri Linkov 2019-09-17 22:53 ` Tabs Drew Adams 2019-09-28 17:06 ` Tabs Stefan Kangas 2019-09-28 19:52 ` Tabs Juri Linkov 2019-10-20 22:38 ` Tabs Juri Linkov 2019-11-02 21:40 ` Tabs Juri Linkov 2019-09-19 23:57 ` Tabs Michael Heerdegen 2019-09-21 22:45 ` Tabs Juri Linkov 2019-09-22 0:31 ` Tabs Michael Heerdegen 2019-09-25 20:15 ` Tabs Juri Linkov 2019-10-05 13:57 ` Tabs Michael Heerdegen 2019-10-05 22:12 ` Tabs Juri Linkov 2019-10-06 8:22 ` Tabs Michael Heerdegen 2019-10-06 12:09 ` Tabs Michael Heerdegen 2019-10-06 15:16 ` Tabs Michael Heerdegen 2019-10-06 17:49 ` Tabs Eli Zaretskii 2019-10-06 17:55 ` Tabs Juri Linkov 2019-10-06 18:05 ` Tabs Juri Linkov 2019-10-06 18:58 ` Tabs Eli Zaretskii 2019-10-06 18:59 ` Tabs Eli Zaretskii 2019-10-06 19:08 ` Tabs Michael Heerdegen 2019-10-06 19:11 ` Tabs Juri Linkov 2019-10-06 19:21 ` Tabs Eli Zaretskii 2019-10-06 19:58 ` Tabs Juri Linkov 2019-10-07 16:05 ` Tabs Eli Zaretskii 2019-10-07 16:53 ` Tabs Michael Heerdegen 2019-10-07 17:12 ` Tabs Ergus 2019-10-07 18:24 ` Tabs Eli Zaretskii 2019-10-07 19:28 ` Tabs Ergus 2019-10-08 7:42 ` Tabs Eli Zaretskii 2019-10-08 8:56 ` Tabs Ergus 2019-10-08 9:18 ` Tabs Eli Zaretskii 2019-10-08 13:58 ` Tabs Eli Zaretskii 2019-10-08 16:00 ` Tabs Ergus 2019-10-08 16:18 ` Tabs Eli Zaretskii 2019-10-08 16:40 ` Tabs Ergus 2019-10-08 17:03 ` Tabs Eli Zaretskii 2019-10-08 23:43 ` Tabs Ergus 2019-10-09 8:37 ` Tabs Eli Zaretskii 2019-10-09 10:39 ` Tabs Ergus 2019-10-09 11:35 ` Tabs Eli Zaretskii 2019-10-09 12:05 ` Tabs Ergus 2019-10-09 12:18 ` Tabs Eli Zaretskii 2019-10-09 12:32 ` Tabs Eli Zaretskii 2019-10-09 18:12 ` Tabs martin rudalics 2019-10-09 18:46 ` Tabs Eli Zaretskii 2019-10-10 9:15 ` Tabs martin rudalics 2019-10-10 9:59 ` Tabs Eli Zaretskii 2019-10-10 10:38 ` Tabs martin rudalics 2019-10-10 11:33 ` Tabs Eli Zaretskii 2019-10-10 11:53 ` Tabs Eli Zaretskii 2019-10-10 14:58 ` Tabs martin rudalics 2019-10-09 12:36 ` Tabs Eli Zaretskii 2019-10-09 13:55 ` Tabs Ergus 2019-10-09 14:21 ` Tabs Eli Zaretskii 2019-10-09 15:15 ` Tabs Ergus 2019-10-09 15:35 ` Tabs Eli Zaretskii 2019-10-10 11:52 ` Tabs Eli Zaretskii 2019-10-10 13:12 ` Tabs Ergus 2019-10-10 13:54 ` Tabs Eli Zaretskii 2019-10-10 14:19 ` Tabs Ergus 2019-10-10 15:03 ` Tabs Eli Zaretskii 2019-10-10 15:35 ` Tabs martin rudalics 2019-10-10 15:46 ` Tabs Ergus 2019-10-10 18:14 ` Tabs martin rudalics 2019-10-10 18:26 ` Tabs Eli Zaretskii 2019-10-11 8:18 ` Tabs martin rudalics 2019-10-11 9:16 ` Tabs Eli Zaretskii 2019-10-16 9:16 ` Tabs martin rudalics 2019-10-10 13:29 ` Tabs Ergus 2019-10-10 13:47 ` Tabs Eli Zaretskii 2019-10-10 14:15 ` Tabs Ergus 2019-10-10 14:40 ` Tabs Ergus 2019-10-10 15:11 ` Tabs Eli Zaretskii 2019-10-10 20:54 ` Tabs Juri Linkov 2019-10-11 7:08 ` Tabs Eli Zaretskii 2019-10-13 20:57 ` Tabs Juri Linkov 2019-10-09 22:37 ` Tabs Juri Linkov 2019-10-10 7:51 ` Tabs Eli Zaretskii 2019-10-10 22:35 ` Tabs Juri Linkov 2019-10-11 8:18 ` Tabs martin rudalics 2019-10-12 22:42 ` Tabs Juri Linkov 2019-10-13 8:16 ` Tabs martin rudalics 2019-10-14 18:02 ` Tabs martin rudalics 2019-10-14 18:29 ` Tabs Eli Zaretskii 2019-10-15 9:47 ` Tabs martin rudalics 2019-10-14 19:35 ` Tabs Juri Linkov 2019-10-14 21:17 ` Tabs T.V Raman 2019-10-14 21:53 ` Tabs Phil Sainty 2019-10-14 22:00 ` Tabs Juri Linkov 2019-10-14 22:36 ` Tabs T.V Raman 2019-10-15 20:39 ` Tabs Juri Linkov 2019-10-16 0:14 ` Tabs T.V Raman 2019-10-15 6:12 ` Tabs Eli Zaretskii 2019-10-15 9:47 ` Tabs martin rudalics 2019-10-15 17:45 ` Tabs Juri Linkov 2019-10-16 9:16 ` Tabs martin rudalics 2019-10-14 19:00 ` Tabs Juri Linkov 2019-10-15 9:47 ` Tabs martin rudalics 2019-10-11 9:20 ` Tabs Eli Zaretskii 2019-10-12 22:47 ` Tabs Juri Linkov 2019-10-13 6:51 ` Tabs Eli Zaretskii 2019-10-13 20:48 ` Tabs Juri Linkov 2019-10-13 21:09 ` Tabs Eli Zaretskii 2019-10-13 21:33 ` Tabs Juri Linkov 2019-10-14 8:24 ` Tabs Eli Zaretskii 2019-10-07 17:58 ` Tabs Eli Zaretskii 2019-10-07 19:11 ` Tabs Juri Linkov 2019-10-06 18:38 ` Tabs Michael Heerdegen 2019-10-06 19:03 ` Tabs Eli Zaretskii 2019-10-06 18:56 ` Tabs Eli Zaretskii 2019-10-08 19:15 ` Tabs Michael Heerdegen 2019-10-09 22:48 ` Tabs Juri Linkov 2019-10-10 11:06 ` Tabs Michael Heerdegen 2019-10-10 20:59 ` Tabs Juri Linkov 2019-10-13 9:32 ` Tabs Michael Heerdegen 2019-10-13 20:24 ` Tabs Juri Linkov 2019-10-15 14:42 ` Tabs Michael Heerdegen 2019-10-19 22:51 ` Tabs Juri Linkov 2019-10-25 11:19 ` Tabs Michael Heerdegen 2019-10-26 22:40 ` Tabs Juri Linkov 2019-10-29 19:09 ` Tabs Michael Heerdegen 2019-11-05 23:24 ` Tabs Juri Linkov 2019-11-08 18:45 ` Tabs Michael Heerdegen 2019-11-08 19:56 ` Tabs Michael Heerdegen 2019-11-12 21:31 ` Tabs Juri Linkov 2019-11-13 16:47 ` Tabs Michael Heerdegen 2019-11-13 22:10 ` Tabs Juri Linkov 2019-11-14 9:20 ` Tabs martin rudalics 2005-08-22 11:25 Tabs Maurizio Colucci 2005-08-22 12:13 ` Tabs Thomas Kjosmoen 2005-08-22 15:48 ` Tabs Aaron S. Hawley 2005-08-23 1:29 ` Tabs Richard M. Stallman 2005-08-23 10:49 ` Tabs Maurizio Colucci 2005-08-24 10:32 ` Tabs Richard M. Stallman 2003-08-15 22:35 Tabs Paul 2003-08-15 23:23 ` Tabs Marcus Frings
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.