* Tabs @ 2019-08-31 20:45 Juri Linkov 2019-09-01 8:12 ` Tabs martin rudalics ` (6 more replies) 0 siblings, 7 replies; 219+ 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] 219+ 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 8:59 ` Tabs (on macos) Jean-Christophe Helary ` (5 subsequent siblings) 6 siblings, 2 replies; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-09-03 19:40 ` Tabs Juri Linkov @ 2019-09-03 20:14 ` Jean Louis 0 siblings, 0 replies; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-09-03 5:45 ` Tabs Yuri Khan @ 2019-09-03 19:45 ` Juri Linkov 0 siblings, 0 replies; 219+ 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] 219+ 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; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-09-15 16:44 ` Tabs Stefan Kangas @ 2019-09-15 21:17 ` Juri Linkov 0 siblings, 0 replies; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-09-02 19:29 ` Tabs Juri Linkov @ 2019-09-03 2:27 ` Eli Zaretskii 0 siblings, 0 replies; 219+ 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] 219+ messages in thread
* Re: Tabs (on macos) 2019-08-31 20:45 Tabs Juri Linkov 2019-09-01 8:12 ` Tabs martin rudalics @ 2019-09-01 8:59 ` Jean-Christophe Helary 2019-09-01 20:11 ` Juri Linkov 2019-09-01 9:28 ` Tabs Alan Mackenzie ` (4 subsequent siblings) 6 siblings, 1 reply; 219+ messages in thread From: Jean-Christophe Helary @ 2019-09-01 8:59 UTC (permalink / raw) To: Emacs developers When building on macos 10.14: cc nsterm.o outputs these error messages and the build fails: nsterm.m:2771: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, "Use NSScrollView to achieve scrolling views."); ^ nsterm.m:5442: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_14, "Create multiple pasteboard items with NSPasteboardTypeFileURL or ... ^ nsterm.m:6862:57: error: too few arguments to function call, expected 6, have 5 = window_from_coordinates (emacsframe, pt.x, pt.y, 0, 0); ~~~~~~~~~~~~~~~~~~~~~~~ ^ ./window.h:1091:1: note: 'window_from_coordinates' declared here extern Lisp_Object window_from_coordinates (struct frame *, int, int, ^ nsterm.m:8256:35: warning: 'NSFilenamesPboardType' is deprecated: first deprecated in macOS 10.14 - Create multiple pasteboard items with NSPasteboardTypeFileURL or kUTTypeFileURL instead [-Wdeprecated-declarations] else if ([type isEqualToString: 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_14, "Create multiple pasteboard items with NSPasteboardTypeFileURL or ... ^ nsterm.m:8271:35: warning: 'NSURLPboardType' is deprecated: first deprecated in macOS 10.14 [-Wdeprecated-declarations] else if ([type isEqualToString: NSURLPboardType]) ^~~~~~~~~~~~~~~ NSPasteboardTypeURL /System/Library/Frameworks/AppKit.framework/Headers/NSPasteboard.h:332:32: note: 'NSURLPboardType' has been explicitly marked deprecated here APPKIT_EXTERN NSPasteboardType NSURLPboardType NS_DEPRECATED_WITH_REPLACEMENT_MAC("NSPasteboardTypeURL", 10_0, 10_14); ^ nsterm.m:8280:35: warning: 'NSStringPboardType' is deprecated: first deprecated in macOS 10.14 [-Wdeprecated-declarations] else if ([type isEqualToString: NSStringPboardType] ^~~~~~~~~~~~~~~~~~ NSPasteboardTypeString /System/Library/Frameworks/AppKit.framework/Headers/NSPasteboard.h:322:32: note: 'NSStringPboardType' has been explicitly marked deprecated here APPKIT_EXTERN NSPasteboardType NSStringPboardType NS_DEPRECATED_WITH_REPLACEMENT_MAC("NSPasteboardTypeString", 10_0, 10_14); ^ nsterm.m:8281:38: warning: 'NSTabularTextPboardType' is deprecated: first deprecated in macOS 10.14 [-Wdeprecated-declarations] || [type isEqualToString: NSTabularTextPboardType]) ^~~~~~~~~~~~~~~~~~~~~~~ NSPasteboardTypeTabularText /System/Library/Frameworks/AppKit.framework/Headers/NSPasteboard.h:326:32: note: 'NSTabularTextPboardType' has been explicitly marked deprecated here APPKIT_EXTERN NSPasteboardType NSTabularTextPboardType NS_DEPRECATED_WITH_REPLACEMENT_MAC("NSPasteboardTypeTabularText", 10_0, 10_14); ^ 6 warnings and 1 error generated. make[1]: *** [nsterm.o] Error 1 make: *** [src] Error 2 Jean-Christophe Helary ----------------------------------------------- http://mac4translators.blogspot.com @brandelune > On Sep 1, 2019, at 5:45, Juri Linkov <juri@linkov.net> 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: > > <tabs.png> ^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: Tabs (on macos) 2019-09-01 8:59 ` Tabs (on macos) Jean-Christophe Helary @ 2019-09-01 20:11 ` Juri Linkov 2019-09-16 13:41 ` Stefan Kangas 0 siblings, 1 reply; 219+ messages in thread From: Juri Linkov @ 2019-09-01 20:11 UTC (permalink / raw) To: Jean-Christophe Helary; +Cc: Emacs developers > When building on macos 10.14: > > cc nsterm.o outputs these error messages and the build fails: Thanks for the compilation output. It shows that the error is in nsterm.m. I missed this file because to find all files where changes are needed I used M-x rgrep RET and the alias 'ch' with the assumption that it searches in all C-related files. But this alias ignores C files with the .m file extension. In grep-files-aliases, "ch" is expanded to "*.[ch]". Should it be "*.[chm]"? Now I fixed the error in nsterm.m. This fix doesn't guarantee everything would work on macos. Maybe more refactoring is needed for macos code as well. ^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: Tabs (on macos) 2019-09-01 20:11 ` Juri Linkov @ 2019-09-16 13:41 ` Stefan Kangas 2019-09-16 20:33 ` Juri Linkov 0 siblings, 1 reply; 219+ messages in thread From: Stefan Kangas @ 2019-09-16 13:41 UTC (permalink / raw) To: Juri Linkov; +Cc: Jean-Christophe Helary, Emacs developers [-- Attachment #1: Type: text/plain, Size: 342 bytes --] Juri Linkov <juri@linkov.net> writes: > Now I fixed the error in nsterm.m. This fix doesn't guarantee > everything would work on macos. Maybe more refactoring > is needed for macos code as well. I've tried to build commit a7289c0488fd on macOS 10.12 but it fails with errors. I've attached the build output. Best regards, Stefan Kangas [-- Attachment #2: build.log --] [-- Type: application/octet-stream, Size: 17149 bytes --] /Library/Developer/CommandLineTools/usr/bin/make -C lib all /Library/Developer/CommandLineTools/usr/bin/make info-real info-dir CC acl_entries.o CC fingerprint.o /Library/Developer/CommandLineTools/usr/bin/make -C doc/lispref info make[2]: Nothing to be done for `info'. /Library/Developer/CommandLineTools/usr/bin/make -C doc/lispintro info make[2]: Nothing to be done for `info'. /Library/Developer/CommandLineTools/usr/bin/make -C doc/emacs info make[2]: Nothing to be done for `info'. /Library/Developer/CommandLineTools/usr/bin/make -C doc/misc info make[1]: Nothing to be done for `info-dir'. make[2]: Nothing to be done for `info'. CC canonicalize-lgpl.o CC copy-file-range.o CC euidaccess.o CC explicit_bzero.o CC faccessat.o CC fpending.o CC fstatat.o CC fsusage.o CC getgroups.o CC getopt.o CC getopt1.o CC group-member.o CC lstat.o CC memmem.o CC memrchr.o CC mktime.o CC open.o CC openat-proc.o CC readlink.o CC readlinkat.o CC regex.o CC sig2str.o CC symlink.o CC time_rz.o CC timegm.o CC acl-errno-valid.o CC acl-internal.o CC get-permissions.o CC set-permissions.o CC allocator.o CC binary-io.o CC c-ctype.o CC c-strcasecmp.o CC c-strncasecmp.o CC careadlinkat.o CC cloexec.o CC close-stream.o CC count-leading-zeros.o CC count-one-bits.o CC count-trailing-zeros.o CC md5.o CC sha1.o CC sha256.o CC sha512.o CC dtoastr.o CC dtotimespec.o CC filemode.o CC filevercmp.o CC gettime.o CC malloca.o CC nstrftime.o CC pipe2.o CC qcopy-acl.o CC stat-time.o CC tempname.o CC timespec.o CC timespec-add.o CC timespec-sub.o CC u64.o CC unistd.o CC utimens.o CC openat-die.o CC save-cwd.o AR libgnu.a /Library/Developer/CommandLineTools/usr/bin/ranlib: file: libgnu.a(u64.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/ranlib: file: libgnu.a(unistd.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/ranlib: file: libgnu.a(u64.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/ranlib: file: libgnu.a(unistd.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/make -C lib-src all CCLD ctags CCLD etags CCLD emacsclient CCLD ebrowse CCLD hexl CC pop.o CCLD make-docfile CCLD make-fingerprint CCLD movemail /Library/Developer/CommandLineTools/usr/bin/make -C src VCSWITNESS='$(srcdir)/../.git/logs/HEAD' all /Library/Developer/CommandLineTools/usr/bin/make -C ../admin/charsets all GEN globals.h GEN buildobj.h make[2]: Nothing to be done for `all'. /Library/Developer/CommandLineTools/usr/bin/make -C ../admin/unidata charscript.el make[2]: Nothing to be done for `charscript.el'. /Library/Developer/CommandLineTools/usr/bin/make -C ../admin/charsets cp51932.el /Library/Developer/CommandLineTools/usr/bin/make -C ../admin/charsets eucjp-ms.el make[2]: Nothing to be done for `cp51932.el'. make[2]: Nothing to be done for `eucjp-ms.el'. CC dispnew.o CC frame.o CC scroll.o CC xdisp.o xdisp.c:13345:19: warning: implicit declaration of function 'gui_mouse_grabbed' is invalid in C99 [-Wimplicit-function-declaration] mouse_down_p = (gui_mouse_grabbed (dpyinfo) ^ CC menu.o CC window.o CC charset.o CC coding.o CC category.o CC ccl.o CC character.o CC chartab.o CC bidi.o CC cm.o CC term.o CC terminal.o CC xfaces.o CC emacs.o CC keyboard.o CC macros.o CC keymap.o 1 warning generated. CC sysdep.o CC bignum.o CC buffer.o CC filelock.o CC insdel.o CC marker.o CC minibuf.o CC fileio.o CC dired.o CC cmds.o CC casetab.o CC casefiddle.o CC indent.o CC search.o CC regex-emacs.o CC undo.o CC alloc.o CC pdumper.o CC data.o CC doc.o CC editfns.o CC callint.o CC eval.o CC floatfns.o CC fns.o CC font.o CC print.o CC lread.o CC syntax.o CC bytecode.o CC process.o CC gnutls.o CC callproc.o CC region-cache.o CC sound.o CC timefns.o CC atimer.o CC doprnt.o CC intervals.o CC textprop.o CC composite.o CC xml.o CC lcms.o CC kqueue.o CC profiler.o CC decompress.o CC thread.o CC systhread.o CC fontset.o CC fringe.o CC image.o CC nsterm.o CC nsfns.o CC nsmenu.o nsfns.m:636:7: warning: implicit declaration of function 'FRAME_EXTERNAL_TAB_BAR' is invalid in C99 [-Wimplicit-function-declaration] FRAME_EXTERNAL_TAB_BAR (f) = 1; ^ nsfns.m:636:34: error: expression is not assignable FRAME_EXTERNAL_TAB_BAR (f) = 1; ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ nsfns.m:644:38: error: expression is not assignable FRAME_EXTERNAL_TAB_BAR (f) = 0; ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ nsfns.m:1375:65: error: too few arguments to function call, expected 6, have 5 &x_width, &x_height); ^ ./frame.h:1635:1: note: 'gui_figure_window_size' declared here extern long gui_figure_window_size (struct frame *, Lisp_Object, bool, bool, int *, int *); ^ nsfns.m:2867:24: warning: 'NSWindow' may not respond to 'tabbar' int tab_bar_height = FRAME_TABBAR_HEIGHT (f); ^~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1086:33: note: expanded from macro 'FRAME_TABBAR_HEIGHT' (([[FRAME_NS_VIEW (f) window] tabbar] == nil \ ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ nsfns.m:2867:24: warning: 'NSWindow' may not respond to 'tabbar' int tab_bar_height = FRAME_TABBAR_HEIGHT (f); ^~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1087:38: note: expanded from macro 'FRAME_TABBAR_HEIGHT' || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ? \ ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ 3 warnings and 3 errors generated. make[1]: *** [nsfns.o] Error 1 make[1]: *** Waiting for unfinished jobs.... 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: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:1708:56: warning: 'NSWindow' may not respond to 'tabbar' f->top_pos = FRAME_PIXEL_HEIGHT (parent) + FRAME_TABBAR_HEIGHT (parent) + FRAME_TOOLBAR_HEIGHT (parent) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./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_TOOLBAR_HEIGHT (parent) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1087:38: 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: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: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:193:12: note: receiver is instance of class declared here @interface NSWindow : NSResponder <NSAnimatablePropertyContainer, NSUserInterfaceValidations, NSUserInterfaceItemIdentification, NSAppearanceCustomization, NSAccessibilityElement, NSAccessibility> ^ nsterm.m:2415:47: warning: 'NSWindow' may not respond to 'tabbar' FRAME_NS_TITLEBAR_HEIGHT(f) + 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:2415:47: warning: 'NSWindow' may not respond to 'tabbar' FRAME_NS_TITLEBAR_HEIGHT(f) + 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: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: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: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: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:193:12: note: receiver is instance of class declared here @interface NSWindow : NSResponder <NSAnimatablePropertyContainer, NSUserInterfaceValidations, NSUserInterfaceItemIdentification, NSAppearanceCustomization, NSAccessibilityElement, NSAccessibility> ^ nsterm.m:7759:26: error: use of undeclared identifier 'NSApplicationPresentationAutoHideTabbar'; did you mean 'NSApplicationPresentationAutoHideToolbar'? return proposedOptions|NSApplicationPresentationAutoHideTabbar|NSApplicationPresentationAutoHideToolbar; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NSApplicationPresentationAutoHideToolbar /System/Library/Frameworks/AppKit.framework/Headers/NSApplication.h:104:5: note: 'NSApplicationPresentationAutoHideToolbar' declared here NSApplicationPresentationAutoHideToolbar NS_ENUM_AVAILABLE_MAC(10_7) = (1 << 11), // Fullscreen window toolbar is detached from window and hides/shows with autoHidden menuBar. May be used only when both NSApplicationPresentationFullScreen and NSApplicationPresentationAutoHideMenuBar are also set ^ 19 warnings and 1 error generated. make[1]: *** [nsterm.o] Error 1 nsmenu.m:1038:10: warning: 'NSWindow' may not respond to 'tabbar' oldh = FRAME_TABBAR_HEIGHT (f); ^~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1086:33: note: expanded from macro 'FRAME_TABBAR_HEIGHT' (([[FRAME_NS_VIEW (f) window] tabbar] == nil \ ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ nsmenu.m:1038:10: warning: 'NSWindow' may not respond to 'tabbar' oldh = FRAME_TABBAR_HEIGHT (f); ^~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1087:38: note: expanded from macro 'FRAME_TABBAR_HEIGHT' || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ? \ ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ nsmenu.m:1144:15: warning: 'NSWindow' may not respond to 'tabbar' if (oldh != FRAME_TABBAR_HEIGHT (f)) ^~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1086:33: note: expanded from macro 'FRAME_TABBAR_HEIGHT' (([[FRAME_NS_VIEW (f) window] tabbar] == nil \ ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ nsmenu.m:1144:15: warning: 'NSWindow' may not respond to 'tabbar' if (oldh != FRAME_TABBAR_HEIGHT (f)) ^~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1087:38: note: expanded from macro 'FRAME_TABBAR_HEIGHT' || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ? \ ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ nsmenu.m:1146:33: warning: 'NSWindow' may not respond to 'tabbar' if (view->wait_for_tab_bar && FRAME_TABBAR_HEIGHT (f) > 0) ^~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1086:33: note: expanded from macro 'FRAME_TABBAR_HEIGHT' (([[FRAME_NS_VIEW (f) window] tabbar] == nil \ ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ nsmenu.m:1146:33: warning: 'NSWindow' may not respond to 'tabbar' if (view->wait_for_tab_bar && FRAME_TABBAR_HEIGHT (f) > 0) ^~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1087:38: note: expanded from macro 'FRAME_TABBAR_HEIGHT' || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ? \ ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ nsmenu.m:1238:13: warning: instance method '-setTabTip:' not found (return type defaults to 'id') [-Wobjc-method-access] [item setTabTip: [NSString stringWithUTF8String: help]]; ^~~~~~~~~ /System/Library/Frameworks/AppKit.framework/Headers/NSToolbarItem.h:17:12: note: receiver is instance of class declared here @interface NSToolbarItem : NSObject <NSCopying, NSValidatedUserInterfaceItem> { ^ 7 warnings generated. make: *** [src] Error 2 ^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: Tabs (on macos) 2019-09-16 13:41 ` Stefan Kangas @ 2019-09-16 20:33 ` Juri Linkov 2019-09-17 9:11 ` Stefan Kangas 0 siblings, 1 reply; 219+ messages in thread From: Juri Linkov @ 2019-09-16 20:33 UTC (permalink / raw) To: Stefan Kangas; +Cc: Jean-Christophe Helary, Emacs developers >> Now I fixed the error in nsterm.m. This fix doesn't guarantee >> everything would work on macos. Maybe more refactoring >> is needed for macos code as well. > > I've tried to build commit a7289c0488fd on macOS 10.12 but it fails > with errors. I've attached the build output. Thanks for the build output, I rely on your help because I have no macOS, I can even acquire a Windows box when necessary, but no one is using macOS in vicinity. Please try again to recompile. ^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: Tabs (on macos) 2019-09-16 20:33 ` Juri Linkov @ 2019-09-17 9:11 ` Stefan Kangas 2019-09-17 9:29 ` Stefan Kangas 0 siblings, 1 reply; 219+ messages in thread From: Stefan Kangas @ 2019-09-17 9:11 UTC (permalink / raw) To: Juri Linkov; +Cc: Jean-Christophe Helary, Emacs developers [-- Attachment #1: Type: text/plain, Size: 347 bytes --] Juri Linkov <juri@linkov.net> writes: > Thanks for the build output, I rely on your help because I have > no macOS, I can even acquire a Windows box when necessary, but > no one is using macOS in vicinity. Please try again to recompile. I'm happy to help. See the attached failing build log for commit 4260b29478. Best regards, Stefan Kangas [-- Attachment #2: build.log --] [-- Type: application/octet-stream, Size: 42309 bytes --] cd . && ./autogen.sh autoconf Checking whether you have the necessary tools... (Read INSTALL.REPO for more details on building Emacs) Checking for autoconf (need at least version 2.65) ... ok Your system has the required tools. Running 'autoreconf -fi -I m4' ... You can now run './configure'. if [ -x ./config.status ]; then \ ./config.status --recheck; \ else \ ./configure --cache-file=/dev/null; \ fi running CONFIG_SHELL=/bin/sh /bin/sh ./configure --no-create --no-recursion checking for xcrun... xcrun checking for make... yes checking for GNU Make... make checking build system type... x86_64-apple-darwin16.7.0 checking host system type... x86_64-apple-darwin16.7.0 checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to enable C11 features... none needed checking for ar... ar checking whether gcc and cc understand -c and -o together... yes checking for putenv... yes checking for sbrk... yes checking for fchmod... yes checking for canonicalize_file_name... no checking for getcwd... yes checking for readlink... yes checking for realpath... yes checking for readlinkat... yes checking for explicit_bzero... no checking for faccessat... yes checking for fcntl... yes checking for fdopendir... yes checking for fstatat... yes checking for fsync... yes checking for gettimeofday... yes checking for lstat... yes checking for mkostemp... yes checking for tzset... yes checking for pipe2... no checking for pselect... yes checking for isblank... yes checking for iswctype... yes checking for strtoimax... yes checking for symlink... yes checking for localtime_r... yes checking for timegm... yes checking for futimes... yes checking for futimesat... no checking for futimens... no checking for utimensat... no checking for lutimes... yes checking for getdtablesize... yes checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking whether _XOPEN_SOURCE should be defined... no checking for Minix Amsterdam compiler... no checking for ranlib... ranlib checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no checking whether gcc accepts -g3 -O2... yes checking whether the compiler is clang... yes checking whether C compiler handles -Werror -Wunknown-warning-option... yes checking whether C compiler handles -Wno-switch... yes checking whether C compiler handles -Wno-pointer-sign... yes checking whether C compiler handles -Wno-string-plus-int... yes checking whether C compiler handles -Wno-unknown-attributes... yes checking whether C compiler handles -Wno-initializer-overrides... yes checking whether C compiler handles -Wno-tautological-compare... yes checking whether C compiler handles -Wno-tautological-constant-out-of-range-compare... yes checking for a BSD-compatible install... /usr/local/bin/ginstall -c checking command to symlink files in the same directory... ln -s checking for install-info... /usr/bin/install-info checking for gzip... /usr/bin/gzip checking for 'find' args to delete a file... -delete checking for brew... brew checking for makeinfo... /usr/local/opt/texinfo/bin/makeinfo checking for -znocombreloc... not needed checking whether addresses are sanitized... no checking for library containing sqrt... none required checking for pkg-config... /usr/local/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for machine/soundcard.h... no checking for sys/soundcard.h... no checking for soundcard.h... no checking for mmsystem.h... no checking for _oss_ioctl in -lossaudio... no checking for alsa >= 1.0.0... no checking for linux/fs.h... no checking for malloc.h... no checking for sys/systeminfo.h... no checking for sys/sysinfo.h... no checking for coff.h... no checking for pty.h... no checking for sys/resource.h... yes checking for sys/utsname.h... yes checking for pwd.h... yes checking for utmp.h... yes checking for util.h... yes checking for sys/prctl.h... no checking for sys/socket.h... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for sys/param.h... yes checking for pthread.h... yes checking for malloc/malloc.h... yes checking for sys/un.h... yes checking for dirent.h... yes checking for execinfo.h... yes checking for stdio_ext.h... no checking for sys/vfs.h... no checking for sys/fs_types.h... no checking for getopt.h... yes checking for sys/cdefs.h... yes checking for sys/time.h... yes checking for ieee754.h... no checking for limits.h... yes checking for wchar.h... yes checking for stdint.h... (cached) yes checking for inttypes.h... (cached) yes checking for sys/select.h... yes checking for sys/stat.h... (cached) yes checking for ADDR_NO_RANDOMIZE... no checking for term.h... yes checking whether time.h and sys/time.h may both be included... yes checking whether sys_siglist is declared... yes checking for sys/wait.h that is POSIX.1 compatible... yes checking for net/if.h... yes checking for ifaddrs.h... yes checking for net/if_dl.h... yes checking for struct ifreq.ifr_flags... yes checking for struct ifreq.ifr_hwaddr... no checking for struct ifreq.ifr_netmask... no checking for struct ifreq.ifr_broadaddr... yes checking for struct ifreq.ifr_addr... yes checking for struct ifreq.ifr_addr.sa_len... yes checking whether gcc understands -MMD -MF... yes checking for X... libraries /usr/X11/lib, headers /usr/X11/include checking AppKit/AppKit.h usability... yes checking AppKit/AppKit.h presence... yes checking for AppKit/AppKit.h... yes checking for Mac OS X 10.6 or newer... yes checking for gcc... gcc checking whether we are using the GNU Objective C compiler... yes checking whether gcc accepts -g... yes checking if the Objective C compiler supports instancetype... yes checking whether malloc is Doug Lea style... no checking for getpagesize... yes checking for working mmap... yes checking for main in -lXbsd... no checking for pthread library... none needed checking for thread support... yes checking for librsvg-2.0 >= 2.14.0... no checking for getaddrinfo_a in -lanl... no checking for dbus-1 >= 1.0... no checking for lgetfilecon in -lselinux... no checking for gnutls >= 2.12.2... yes checking for libsystemd >= 222... no checking for jansson >= 2.7... no checking sys/inotify.h usability... no checking sys/inotify.h presence... no checking for sys/inotify.h... no checking for libkqueue... no checking for library containing kqueue... none required checking for lcms2... yes checking for library containing inflateEnd... -lz checking gpm.h usability... no checking gpm.h presence... no checking for gpm.h... no checking for libxml-2.0 > 2.6.17... yes checking for htmlReadMemory in -lxml2... yes checking for maillock in -lmail... no checking for maillock in -llockfile... no checking for liblockfile.so... no checking maillock.h usability... no checking maillock.h presence... no checking for maillock.h... no checking for accept4... no checking for fchdir... yes checking for gethostname... yes checking for getrusage... yes checking for get_current_dir_name... no checking for lrand48... yes checking for random... yes checking for rint... yes checking for trunc... yes checking for select... yes checking for getpagesize... (cached) yes checking for setlocale... yes checking for newlocale... yes checking for getrlimit... yes checking for setrlimit... yes checking for shutdown... yes checking for pthread_sigmask... (cached) yes checking for strsignal... yes checking for setitimer... yes checking for timer_getoverrun... no checking for sendto... yes checking for recvfrom... yes checking for getsockname... yes checking for getifaddrs... yes checking for freeifaddrs... yes checking for gai_strerror... yes checking for sync... yes checking for getpwent... yes checking for endpwent... yes checking for getgrent... yes checking for endgrent... yes checking for cfmakeraw... yes checking for cfsetspeed... yes checking for __executable_start... no checking for log2... yes checking for prctl... no checking for aligned_alloc... no checking for posix_memalign... yes checking whether aligned_alloc is declared... no checking for posix_madvise... yes checking for __builtin_frame_address... yes checking for __builtin_unwind_init... yes checking for _LARGEFILE_SOURCE value needed for large files... no checking for grantpt... yes checking for getpt... no checking for posix_openpt... yes checking for library containing tputs... -lncurses checking for timerfd interface... no checking whether signals can be handled on alternate stack... yes checking gmp.h usability... yes checking gmp.h presence... yes checking for gmp.h... yes checking for library containing __gmpz_roinit_n... -lgmp checking valgrind/valgrind.h usability... no checking valgrind/valgrind.h presence... no checking for valgrind/valgrind.h... no checking for struct unipair.unicode... no checking for pid_t... yes checking vfork.h usability... no checking vfork.h presence... no checking for vfork.h... no checking for fork... yes checking for vfork... yes checking for working fork... yes checking for working vfork... (cached) yes checking for snprintf... yes checking whether GLib is linked in... no checking for nl_langinfo and CODESET... yes checking for nl_langinfo and _NL_PAPER_WIDTH... no checking for mbstate_t... yes checking for _setjmp... yes checking for sigsetjmp... yes checking for usable FIONREAD... yes checking for usable SIGIO... yes checking for struct alignment... yes checking for typeof syntax and keyword spelling... typeof checking for statement expressions... yes checking for working alloca.h... yes checking for alloca... yes checking whether // is distinct from /... no checking whether realpath works... no checking for unsigned long long int... yes checking whether byte ordering is bigendian... no checking whether the preprocessor supports include_next... yes checking whether system header files limit the line length... no checking if environ is properly declared... no checking for complete errno.h... yes checking whether lstat correctly handles trailing slash... no checking for mode_t... yes checking for st_dm_mode in struct stat... no checking whether strmode is declared... yes checking for gawk... gawk checking for getopt.h... (cached) yes checking for getopt_long_only... yes checking whether getopt is POSIX compatible... no checking for C/C++ restrict keyword... __restrict checking for struct timeval... yes checking for wide-enough struct timeval.tv_sec member... yes checking whether limits.h has LLONG_MAX, WORD_BIT, ULLONG_WIDTH etc.... no checking for long long int... yes checking whether stdint.h conforms to C99... no checking sys/inttypes.h usability... no checking sys/inttypes.h presence... no checking for sys/inttypes.h... no checking sys/bitypes.h usability... no checking sys/bitypes.h presence... no checking for sys/bitypes.h... no checking for bit size of ptrdiff_t... 64 checking for bit size of size_t... 64 checking for bit size of sig_atomic_t... 32 checking for bit size of wchar_t... 32 checking for bit size of wint_t... 32 checking whether sig_atomic_t is signed... yes checking whether wchar_t is signed... yes checking whether wint_t is signed... yes checking for ptrdiff_t integer literal suffix... l checking for size_t integer literal suffix... ul checking for sig_atomic_t integer literal suffix... checking for wchar_t integer literal suffix... checking for wint_t integer literal suffix... checking whether memmem is declared... yes checking whether memrchr is declared... no checking whether <limits.h> defines MIN and MAX... no checking whether <sys/param.h> defines MIN and MAX... yes checking whether time_t is signed... yes checking whether alarm is declared... yes checking for working mktime... no checking whether struct tm is in sys/time.h or time.h... time.h checking for struct tm.tm_zone... yes checking for struct tm.tm_gmtoff... yes checking whether <sys/select.h> is self-contained... yes checking for inline... inline checking for stdlib.h... (cached) yes checking for GNU libc compatible malloc... yes checking whether we are using the GNU C Library >= 2.1 or uClibc... no checking for sigset_t... yes checking for wchar_t... yes checking whether strnlen is declared... yes checking whether strtoimax is declared... yes checking for a thread-safe mkdir -p... /usr/local/bin/gmkdir -p checking whether stat file-mode macros are broken... no checking for struct timespec in <time.h>... yes checking whether clearerr_unlocked is declared... yes checking whether feof_unlocked is declared... yes checking whether ferror_unlocked is declared... yes checking whether fflush_unlocked is declared... no checking whether fgets_unlocked is declared... no checking whether fputc_unlocked is declared... no checking whether fputs_unlocked is declared... no checking whether fread_unlocked is declared... no checking whether fwrite_unlocked is declared... no checking whether getc_unlocked is declared... yes checking whether getchar_unlocked is declared... yes checking whether putc_unlocked is declared... yes checking whether putchar_unlocked is declared... yes checking whether the utimes function works... yes checking type of array argument to getgroups... gid_t checking whether getdtablesize is declared... yes checking for O_CLOEXEC... yes checking for promoted mode_t type... int checking sys/acl.h usability... yes checking sys/acl.h presence... yes checking for sys/acl.h... yes checking for library containing acl_get_file... none required checking for acl_get_file... yes checking for acl_get_fd... yes checking for acl_set_file... yes checking for acl_set_fd... yes checking for acl_free... yes checking for acl_from_mode... no checking for acl_from_text... yes checking for acl_delete_def_file... yes checking for acl_extended_file... no checking for acl_delete_fd_np... yes checking for acl_delete_file_np... yes checking for acl_copy_ext_native... yes checking for acl_create_entry_np... yes checking for acl_to_short_text... no checking for acl_free_text... no checking for working acl_get_file... yes checking acl/libacl.h usability... no checking acl/libacl.h presence... no checking for acl/libacl.h... no checking for acl_entries... no checking for ACL_FIRST_ENTRY... yes checking for ACL_TYPE_EXTENDED... yes checking for alloca as a compiler built-in... yes checking for __builtin_expect... yes checking byteswap.h usability... no checking byteswap.h presence... no checking for byteswap.h... no checking for library containing clock_gettime... none required checking for clock_gettime... yes checking for clock_settime... yes checking for copy_file_range... no checking for d_type member in directory struct... yes checking whether // is distinct from /... (cached) no checking whether dup2 works... yes checking for library containing backtrace_symbols_fd... none required checking for explicit_memset... no checking for access... yes checking whether fcntl handles F_DUPFD correctly... yes checking whether fcntl understands F_DUPFD_CLOEXEC... yes checking whether fdopendir is declared... yes checking whether fdopendir works... yes checking for flexible array member... yes checking for __fpending... no checking whether fstatat (..., 0) works... yes checking for sys/mount.h... yes checking how to get file system space usage... checking for statvfs function (SVR4)... no checking for two-argument statfs with statfs.f_frsize member... no checking for 3-argument statfs function (DEC OSF/1)... no checking for two-argument statfs with statfs.f_bsize member (AIX, 4.3BSD)... yes checking sys/fs/s5param.h usability... no checking sys/fs/s5param.h presence... no checking for sys/fs/s5param.h... no checking sys/statfs.h usability... no checking sys/statfs.h presence... no checking for sys/statfs.h... no checking for statfs that truncates block counts... no checking for getloadavg... yes checking sys/loadavg.h usability... no checking sys/loadavg.h presence... no checking for sys/loadavg.h... no checking whether getloadavg is declared... yes checking whether gettimeofday clobbers localtime buffer... no checking for gettimeofday with POSIX signature... yes checking for memmem... yes checking whether memmem works... no checking for memrchr... no checking whether signature of pselect conforms to POSIX... yes checking whether pselect detects invalid fds... yes checking whether pthread_sigmask is a macro... no checking whether pthread_sigmask works without -lpthread... yes checking whether pthread_sigmask returns error numbers... yes checking whether pthread_sigmask unblocks signals correctly... guessing yes checking whether readlink signature is correct... yes checking whether readlink handles trailing slash correctly... no checking whether readlinkat signature is correct... yes checking for working re_compile_pattern... no checking libintl.h usability... no checking libintl.h presence... no checking for libintl.h... no checking whether isblank is declared... yes checking for sig2str... no checking for volatile sig_atomic_t... yes checking for sighandler_t... no checking for socklen_t... yes checking for ssize_t... yes checking for struct stat.st_atim.tv_nsec... no checking for struct stat.st_atimespec.tv_nsec... yes checking for struct stat.st_birthtimespec.tv_nsec... yes checking for working stdalign.h... yes checking for good max_align_t... yes checking whether NULL can be used in arbitrary expressions... yes checking which flavor of printf attribute matches inttypes macros... system checking for stpcpy... yes checking for working strnlen... yes checking whether strtoimax works... yes checking whether symlink handles trailing slash correctly... no checking for nlink_t... yes checking whether localtime_r is declared... yes checking whether localtime_r is compatible with its POSIX signature... yes checking whether localtime loops forever near extrema... no checking for timezone_t... no checking for library containing timer_settime... no checking for timer_settime... no checking for variable-length arrays... yes checking whether open recognizes a trailing slash... no checking for euidaccess... no checking libgen.h usability... yes checking libgen.h presence... yes checking for libgen.h... yes checking for getgroups... yes checking for working getgroups... yes checking for library containing eaccess... no checking for eaccess... no checking for group_member... no checking for getgroups... (cached) yes checking for working getgroups... (cached) yes checking whether getgroups handles negative values... no checking whether the compiler supports the __inline keyword... yes checking for __mktime_internal... no checking for gcc option to disable position independent executables... not needed Configured for 'x86_64-apple-darwin16.7.0'. Where should the build process find the source code? . What compiler should emacs be built with? gcc -g3 -O2 Should Emacs use the GNU version of malloc? no (The GNU allocators don't work with this system configuration.) Should Emacs use a relocating allocator for buffers? no Should Emacs use mmap(2) for buffer allocation? no What window system should Emacs use? nextstep What toolkit should Emacs use? none Where do we find X Windows header files? /usr/X11/include Where do we find X Windows libraries? /usr/X11/lib Does Emacs use -lXaw3d? no Does Emacs use -lXpm? no Does Emacs use -ljpeg? no Does Emacs use -ltiff? no Does Emacs use a gif library? no Does Emacs use a png library? no Does Emacs use -lrsvg-2? no Does Emacs use cairo? no Does Emacs use -llcms2? yes Does Emacs use imagemagick? no Does Emacs support sound? no Does Emacs use -lgpm? no Does Emacs use -ldbus? no Does Emacs use -lgconf? no Does Emacs use GSettings? no Does Emacs use a file notification library? yes (kqueue) Does Emacs use access control lists? yes Does Emacs use -lselinux? no Does Emacs use -lgnutls? yes Does Emacs use -lxml2? yes Does Emacs use -lfreetype? no Does Emacs use HarfBuzz? no Does Emacs use -lm17n-flt? no Does Emacs use -lotf? no Does Emacs use -lxft? no Does Emacs use -lsystemd? no Does Emacs use -ljansson? no Does Emacs use -lgmp? yes Does Emacs directly use zlib? yes Does Emacs have dynamic modules support? no Does Emacs use toolkit scroll bars? yes Does Emacs support Xwidgets (requires gtk3)? no Does Emacs have threading support in lisp? yes Does Emacs support the portable dumper? yes Does Emacs support legacy unexec dumping? no Which dumping strategy does Emacs use? pdumper Run 'make' to build Emacs, then run 'src/emacs' to test it. Run 'make install' in order to build an application bundle. The application will go to nextstep/Emacs.app and can be run or moved from there. The application will be fully self-contained. configure: creating ./config.status configure: WARNING: This configuration installs a 'movemail' program that does not retrieve POP3 email. By default, Emacs 25 and earlier installed a 'movemail' program that retrieved POP3 email via only insecure channels, a practice that is no longer recommended but that you can continue to support by using './configure --with-pop'. configure: You might want to install GNU Mailutils <https://mailutils.org> and use './configure --with-mailutils'. MAKE='/Library/Developer/CommandLineTools/usr/bin/make' ./config.status config.status: creating src/emacs-module.h config.status: creating nextstep/Cocoa/Emacs.base/Contents/Info.plist config.status: creating nextstep/Cocoa/Emacs.base/Contents/Resources/English.lproj/InfoPlist.strings config.status: creating Makefile config.status: creating lib/gnulib.mk config.status: creating ./doc/man/emacs.1 config.status: creating lib/Makefile config.status: creating lib-src/Makefile config.status: creating oldXMenu/Makefile config.status: creating doc/emacs/Makefile config.status: creating doc/misc/Makefile config.status: creating doc/lispintro/Makefile config.status: creating doc/lispref/Makefile config.status: creating src/Makefile config.status: creating lwlib/Makefile config.status: creating lisp/Makefile config.status: creating leim/Makefile config.status: creating nextstep/Makefile config.status: creating nt/Makefile config.status: creating test/Makefile config.status: creating admin/charsets/Makefile config.status: creating admin/unidata/Makefile config.status: creating admin/grammars/Makefile config.status: creating src/config.h config.status: src/config.h is unchanged config.status: executing src/epaths.h commands config.status: executing src/.gdbinit commands config.status: executing doc/emacs/emacsver.texi commands config.status: executing etc-refcards-emacsver.tex commands /Library/Developer/CommandLineTools/usr/bin/make -C lib all /Library/Developer/CommandLineTools/usr/bin/make info-real info-dir GEN alloca.h GEN byteswap.h /Library/Developer/CommandLineTools/usr/bin/make -C doc/lispref info /Library/Developer/CommandLineTools/usr/bin/make -C doc/lispintro info GEN ../../info/elisp.info GEN dirent.h make[2]: Nothing to be done for `info'. /Library/Developer/CommandLineTools/usr/bin/make -C doc/emacs info GEN ../../info/emacs.info GEN fcntl.h GEN getopt.h GEN getopt-cdefs.h GEN ieee754.h GEN inttypes.h GEN limits.h GEN signal.h GEN stdint.h GEN stdio.h GEN stdlib.h GEN string.h GEN sys/select.h GEN sys/stat.h GEN sys/time.h GEN sys/types.h GEN time.h GEN unistd.h CC fingerprint.o CC acl_entries.o CC canonicalize-lgpl.o CC copy-file-range.o CC euidaccess.o CC explicit_bzero.o CC faccessat.o CC fpending.o CC fstatat.o CC fsusage.o CC getgroups.o CC getopt.o CC getopt1.o CC group-member.o CC lstat.o CC memmem.o CC memrchr.o CC mktime.o CC open.o CC openat-proc.o CC readlink.o CC readlinkat.o CC regex.o CC sig2str.o CC symlink.o CC time_rz.o CC timegm.o CC acl-errno-valid.o CC acl-internal.o CC get-permissions.o CC set-permissions.o CC allocator.o CC binary-io.o CC c-ctype.o CC c-strcasecmp.o CC c-strncasecmp.o CC careadlinkat.o CC cloexec.o CC close-stream.o CC count-leading-zeros.o CC count-one-bits.o CC count-trailing-zeros.o CC md5.o CC sha1.o CC sha256.o CC sha512.o CC dtoastr.o CC dtotimespec.o CC filemode.o CC filevercmp.o CC gettime.o CC malloca.o CC nstrftime.o CC pipe2.o CC qcopy-acl.o CC stat-time.o CC tempname.o CC timespec.o CC timespec-add.o CC timespec-sub.o CC u64.o CC unistd.o CC utimens.o CC openat-die.o CC save-cwd.o AR libgnu.a /Library/Developer/CommandLineTools/usr/bin/ranlib: file: libgnu.a(u64.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/ranlib: file: libgnu.a(unistd.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/ranlib: file: libgnu.a(u64.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/ranlib: file: libgnu.a(unistd.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/make -C doc/misc info GEN ../../info/emacs-mime.info GEN ../../info/efaq.info GEN ../../info/gnus.info /Library/Developer/CommandLineTools/usr/bin/make -C lib-src all CCLD etags CCLD ctags GEN ../../info/smtpmail.info CCLD emacsclient CCLD ebrowse GEN info/dir CCLD hexl CC pop.o CCLD make-docfile CCLD make-fingerprint CCLD movemail /Library/Developer/CommandLineTools/usr/bin/make -C src VCSWITNESS='$(srcdir)/../.git/logs/HEAD' all GEN lisp.mk GEN globals.h GEN buildobj.h /Library/Developer/CommandLineTools/usr/bin/make -C ../admin/charsets all make[2]: Nothing to be done for `all'. /Library/Developer/CommandLineTools/usr/bin/make -C ../admin/unidata charscript.el make[2]: Nothing to be done for `charscript.el'. /Library/Developer/CommandLineTools/usr/bin/make -C ../admin/charsets cp51932.el make[2]: Nothing to be done for `cp51932.el'. /Library/Developer/CommandLineTools/usr/bin/make -C ../admin/charsets eucjp-ms.el make[2]: Nothing to be done for `eucjp-ms.el'. CC dispnew.o CC frame.o CC scroll.o CC xdisp.o CC menu.o xdisp.c:13345:19: warning: implicit declaration of function 'gui_mouse_grabbed' is invalid in C99 [-Wimplicit-function-declaration] mouse_down_p = (gui_mouse_grabbed (dpyinfo) ^ CC window.o CC charset.o CC coding.o CC category.o CC ccl.o CC character.o 1 warning generated. CC chartab.o CC bidi.o CC cm.o CC term.o CC terminal.o CC xfaces.o CC emacs.o CC keyboard.o CC macros.o CC keymap.o CC sysdep.o CC bignum.o CC buffer.o CC filelock.o CC insdel.o CC marker.o CC minibuf.o CC fileio.o CC dired.o CC cmds.o CC casetab.o CC casefiddle.o CC indent.o CC search.o CC regex-emacs.o CC undo.o CC alloc.o CC pdumper.o CC data.o CC doc.o CC editfns.o CC callint.o CC eval.o CC floatfns.o CC fns.o CC font.o CC print.o CC lread.o CC syntax.o CC bytecode.o CC process.o CC gnutls.o CC callproc.o CC region-cache.o CC sound.o CC timefns.o CC atimer.o CC doprnt.o CC intervals.o CC textprop.o CC composite.o CC xml.o CC lcms.o CC kqueue.o CC profiler.o CC decompress.o CC thread.o CC systhread.o CC fontset.o CC fringe.o CC image.o CC nsterm.o CC nsfns.o nsfns.m:636:7: warning: implicit declaration of function 'FRAME_EXTERNAL_TAB_BAR' is invalid in C99 [-Wimplicit-function-declaration] FRAME_EXTERNAL_TAB_BAR (f) = 1; ^ nsfns.m:636:34: error: expression is not assignable FRAME_EXTERNAL_TAB_BAR (f) = 1; ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ nsfns.m:644:38: error: expression is not assignable FRAME_EXTERNAL_TAB_BAR (f) = 0; ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ CC nsmenu.o nsfns.m:1375:65: error: too few arguments to function call, expected 6, have 5 &x_width, &x_height); ^ ./frame.h:1635:1: note: 'gui_figure_window_size' declared here extern long gui_figure_window_size (struct frame *, Lisp_Object, bool, bool, int *, int *); ^ nsfns.m:2867:24: warning: 'NSWindow' may not respond to 'tabbar' int tab_bar_height = FRAME_TABBAR_HEIGHT (f); ^~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1086:33: note: expanded from macro 'FRAME_TABBAR_HEIGHT' (([[FRAME_NS_VIEW (f) window] tabbar] == nil \ ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ nsfns.m:2867:24: warning: 'NSWindow' may not respond to 'tabbar' int tab_bar_height = FRAME_TABBAR_HEIGHT (f); ^~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1087:38: note: expanded from macro 'FRAME_TABBAR_HEIGHT' || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ? \ ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ 3 warnings and 3 errors generated. make[1]: *** [nsfns.o] Error 1 make[1]: *** Waiting for unfinished jobs.... 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: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:1708:56: warning: 'NSWindow' may not respond to 'tabbar' f->top_pos = FRAME_PIXEL_HEIGHT (parent) + FRAME_TABBAR_HEIGHT (parent) + FRAME_TOOLBAR_HEIGHT (parent) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./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_TOOLBAR_HEIGHT (parent) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1087:38: 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: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: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:193:12: note: receiver is instance of class declared here @interface NSWindow : NSResponder <NSAnimatablePropertyContainer, NSUserInterfaceValidations, NSUserInterfaceItemIdentification, NSAppearanceCustomization, NSAccessibilityElement, NSAccessibility> ^ nsterm.m:2415:47: warning: 'NSWindow' may not respond to 'tabbar' FRAME_NS_TITLEBAR_HEIGHT(f) + 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:2415:47: warning: 'NSWindow' may not respond to 'tabbar' FRAME_NS_TITLEBAR_HEIGHT(f) + 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: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: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: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: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:193:12: note: receiver is instance of class declared here @interface NSWindow : NSResponder <NSAnimatablePropertyContainer, NSUserInterfaceValidations, NSUserInterfaceItemIdentification, NSAppearanceCustomization, NSAccessibilityElement, NSAccessibility> ^ nsterm.m:7759:26: error: use of undeclared identifier 'NSApplicationPresentationAutoHideTabbar'; did you mean 'NSApplicationPresentationAutoHideToolbar'? return proposedOptions|NSApplicationPresentationAutoHideTabbar|NSApplicationPresentationAutoHideToolbar; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NSApplicationPresentationAutoHideToolbar /System/Library/Frameworks/AppKit.framework/Headers/NSApplication.h:104:5: note: 'NSApplicationPresentationAutoHideToolbar' declared here NSApplicationPresentationAutoHideToolbar NS_ENUM_AVAILABLE_MAC(10_7) = (1 << 11), // Fullscreen window toolbar is detached from window and hides/shows with autoHidden menuBar. May be used only when both NSApplicationPresentationFullScreen and NSApplicationPresentationAutoHideMenuBar are also set ^ 19 warnings and 1 error generated. make[1]: *** [nsterm.o] Error 1 nsmenu.m:1038:10: warning: 'NSWindow' may not respond to 'tabbar' oldh = FRAME_TABBAR_HEIGHT (f); ^~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1086:33: note: expanded from macro 'FRAME_TABBAR_HEIGHT' (([[FRAME_NS_VIEW (f) window] tabbar] == nil \ ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ nsmenu.m:1038:10: warning: 'NSWindow' may not respond to 'tabbar' oldh = FRAME_TABBAR_HEIGHT (f); ^~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1087:38: note: expanded from macro 'FRAME_TABBAR_HEIGHT' || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ? \ ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ nsmenu.m:1144:15: warning: 'NSWindow' may not respond to 'tabbar' if (oldh != FRAME_TABBAR_HEIGHT (f)) ^~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1086:33: note: expanded from macro 'FRAME_TABBAR_HEIGHT' (([[FRAME_NS_VIEW (f) window] tabbar] == nil \ ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ nsmenu.m:1144:15: warning: 'NSWindow' may not respond to 'tabbar' if (oldh != FRAME_TABBAR_HEIGHT (f)) ^~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1087:38: note: expanded from macro 'FRAME_TABBAR_HEIGHT' || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ? \ ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ nsmenu.m:1146:33: warning: 'NSWindow' may not respond to 'tabbar' if (view->wait_for_tab_bar && FRAME_TABBAR_HEIGHT (f) > 0) ^~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1086:33: note: expanded from macro 'FRAME_TABBAR_HEIGHT' (([[FRAME_NS_VIEW (f) window] tabbar] == nil \ ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ nsmenu.m:1146:33: warning: 'NSWindow' may not respond to 'tabbar' if (view->wait_for_tab_bar && FRAME_TABBAR_HEIGHT (f) > 0) ^~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1087:38: note: expanded from macro 'FRAME_TABBAR_HEIGHT' || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ? \ ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ nsmenu.m:1238:13: warning: instance method '-setTabTip:' not found (return type defaults to 'id') [-Wobjc-method-access] [item setTabTip: [NSString stringWithUTF8String: help]]; ^~~~~~~~~ /System/Library/Frameworks/AppKit.framework/Headers/NSToolbarItem.h:17:12: note: receiver is instance of class declared here @interface NSToolbarItem : NSObject <NSCopying, NSValidatedUserInterfaceItem> { ^ 7 warnings generated. make: *** [src] Error 2 ^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: Tabs (on macos) 2019-09-17 9:11 ` Stefan Kangas @ 2019-09-17 9:29 ` Stefan Kangas 2019-09-17 20:28 ` Juri Linkov 2019-09-17 23:29 ` Stefan Kangas 0 siblings, 2 replies; 219+ messages in thread From: Stefan Kangas @ 2019-09-17 9:29 UTC (permalink / raw) To: Juri Linkov; +Cc: Jean-Christophe Helary, Emacs developers [-- Attachment #1: Type: text/plain, Size: 3942 bytes --] Stefan Kangas <stefan@marxist.se> writes: > I'm happy to help. See the attached failing build log for commit 4260b29478. Please disregard that, I fooled up. Correct build log attached for commit e3e0920b9f3. It now builds but emacs crashes on start. I don't have time to debug it in gdb right now, but I'll look into it and send a proper backtrace. For now, here's the crash output: $ ./src/emacs -Q 2019-09-17 11:25:22.701 emacs[85246:9193823] -[EmacsWindow setTabbar:]: unrecognized selector sent to instance 0x7fef9ad9e1a0 2019-09-17 11:25:22.706 emacs[85246:9193823] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[EmacsWindow setTabbar:]: unrecognized selector sent to instance 0x7fef9ad9e1a0' *** First throw call stack: ( 0 CoreFoundation 0x00007fff94faf46b __exceptionPreprocess + 171 1 libobjc.A.dylib 0x00007fffa9def48d objc_exception_throw + 48 2 CoreFoundation 0x00007fff950310e4 -[NSObject(NSObject) doesNotRecognizeSelector:] + 132 3 CoreFoundation 0x00007fff94f20b05 ___forwarding___ + 1061 4 CoreFoundation 0x00007fff94f20658 _CF_forwarding_prep_0 + 120 5 emacs 0x0000000105582cb1 -[EmacsView createTabbar:] + 161 6 emacs 0x00000001055831a1 -[EmacsView initFrameFromEmacs:] + 897 7 emacs 0x0000000105592ea1 Fx_create_frame + 3457 8 emacs 0x00000001054fd4bf funcall_subr + 239 9 emacs 0x00000001054fca9b Ffuncall + 827 10 emacs 0x000000010553a3fc exec_byte_code + 1932 11 emacs 0x00000001054fca39 Ffuncall + 729 12 emacs 0x000000010553a3fc exec_byte_code + 1932 13 emacs 0x00000001054fca39 Ffuncall + 729 14 emacs 0x00000001054fca9b Ffuncall + 827 15 emacs 0x000000010553a3fc exec_byte_code + 1932 16 emacs 0x00000001054fca39 Ffuncall + 729 17 emacs 0x000000010553a3fc exec_byte_code + 1932 18 emacs 0x00000001054fca39 Ffuncall + 729 19 emacs 0x000000010553a3fc exec_byte_code + 1932 20 emacs 0x00000001054fca39 Ffuncall + 729 21 emacs 0x000000010553a3fc exec_byte_code + 1932 22 emacs 0x00000001054fca39 Ffuncall + 729 23 emacs 0x000000010553a3fc exec_byte_code + 1932 24 emacs 0x00000001054fc2b2 apply_lambda + 386 25 emacs 0x00000001054f8d23 eval_sub + 915 26 emacs 0x00000001054fbfea Feval + 106 27 emacs 0x00000001054fb222 internal_condition_case + 82 28 emacs 0x0000000105482c3d top_level_1 + 45 29 emacs 0x00000001054fab79 internal_catch + 73 30 emacs 0x000000010547202f command_loop + 143 31 emacs 0x0000000105471f53 recursive_edit_1 + 115 32 emacs 0x0000000105472182 Frecursive_edit + 226 33 emacs 0x0000000105470a54 main + 6260 34 libdyld.dylib 0x00007fffaa729235 start + 1 35 ??? 0x0000000000000002 0x0 + 2 ) libc++abi.dylib: terminating with uncaught exception of type NSException Fatal error 6: Abort trap Abort trap: 6 Best regards, Stefan Kangas [-- Attachment #2: build.log --] [-- Type: application/octet-stream, Size: 51742 bytes --] cd . && ./autogen.sh autoconf Checking whether you have the necessary tools... (Read INSTALL.REPO for more details on building Emacs) Checking for autoconf (need at least version 2.65) ... ok Your system has the required tools. Running 'autoreconf -fi -I m4' ... You can now run './configure'. if [ -x ./config.status ]; then \ ./config.status --recheck; \ else \ ./configure --cache-file=/dev/null; \ fi running CONFIG_SHELL=/bin/sh /bin/sh ./configure --no-create --no-recursion checking for xcrun... xcrun checking for make... yes checking for GNU Make... make checking build system type... x86_64-apple-darwin16.7.0 checking host system type... x86_64-apple-darwin16.7.0 checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to enable C11 features... none needed checking for ar... ar checking whether gcc and cc understand -c and -o together... yes checking for putenv... yes checking for sbrk... yes checking for fchmod... yes checking for canonicalize_file_name... no checking for getcwd... yes checking for readlink... yes checking for realpath... yes checking for readlinkat... yes checking for explicit_bzero... no checking for faccessat... yes checking for fcntl... yes checking for fdopendir... yes checking for fstatat... yes checking for fsync... yes checking for gettimeofday... yes checking for lstat... yes checking for mkostemp... yes checking for tzset... yes checking for pipe2... no checking for pselect... yes checking for isblank... yes checking for iswctype... yes checking for strtoimax... yes checking for symlink... yes checking for localtime_r... yes checking for timegm... yes checking for futimes... yes checking for futimesat... no checking for futimens... no checking for utimensat... no checking for lutimes... yes checking for getdtablesize... yes checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking whether _XOPEN_SOURCE should be defined... no checking for Minix Amsterdam compiler... no checking for ranlib... ranlib checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no checking whether gcc accepts -g3 -O2... yes checking whether the compiler is clang... yes checking whether C compiler handles -Werror -Wunknown-warning-option... yes checking whether C compiler handles -Wno-switch... yes checking whether C compiler handles -Wno-pointer-sign... yes checking whether C compiler handles -Wno-string-plus-int... yes checking whether C compiler handles -Wno-unknown-attributes... yes checking whether C compiler handles -Wno-initializer-overrides... yes checking whether C compiler handles -Wno-tautological-compare... yes checking whether C compiler handles -Wno-tautological-constant-out-of-range-compare... yes checking for a BSD-compatible install... /usr/local/bin/ginstall -c checking command to symlink files in the same directory... ln -s checking for install-info... /usr/bin/install-info checking for gzip... /usr/bin/gzip checking for 'find' args to delete a file... -delete checking for brew... brew checking for makeinfo... /usr/local/opt/texinfo/bin/makeinfo checking for -znocombreloc... not needed checking whether addresses are sanitized... no checking for library containing sqrt... none required checking for pkg-config... /usr/local/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for machine/soundcard.h... no checking for sys/soundcard.h... no checking for soundcard.h... no checking for mmsystem.h... no checking for _oss_ioctl in -lossaudio... no checking for alsa >= 1.0.0... no checking for linux/fs.h... no checking for malloc.h... no checking for sys/systeminfo.h... no checking for sys/sysinfo.h... no checking for coff.h... no checking for pty.h... no checking for sys/resource.h... yes checking for sys/utsname.h... yes checking for pwd.h... yes checking for utmp.h... yes checking for util.h... yes checking for sys/prctl.h... no checking for sys/socket.h... yes checking for stdlib.h... (cached) yes checking for unistd.h... (cached) yes checking for sys/param.h... yes checking for pthread.h... yes checking for malloc/malloc.h... yes checking for sys/un.h... yes checking for dirent.h... yes checking for execinfo.h... yes checking for stdio_ext.h... no checking for sys/vfs.h... no checking for sys/fs_types.h... no checking for getopt.h... yes checking for sys/cdefs.h... yes checking for sys/time.h... yes checking for ieee754.h... no checking for limits.h... yes checking for wchar.h... yes checking for stdint.h... (cached) yes checking for inttypes.h... (cached) yes checking for sys/select.h... yes checking for sys/stat.h... (cached) yes checking for ADDR_NO_RANDOMIZE... no checking for term.h... yes checking whether time.h and sys/time.h may both be included... yes checking whether sys_siglist is declared... yes checking for sys/wait.h that is POSIX.1 compatible... yes checking for net/if.h... yes checking for ifaddrs.h... yes checking for net/if_dl.h... yes checking for struct ifreq.ifr_flags... yes checking for struct ifreq.ifr_hwaddr... no checking for struct ifreq.ifr_netmask... no checking for struct ifreq.ifr_broadaddr... yes checking for struct ifreq.ifr_addr... yes checking for struct ifreq.ifr_addr.sa_len... yes checking whether gcc understands -MMD -MF... yes checking for X... libraries /usr/X11/lib, headers /usr/X11/include checking AppKit/AppKit.h usability... yes checking AppKit/AppKit.h presence... yes checking for AppKit/AppKit.h... yes checking for Mac OS X 10.6 or newer... yes checking for gcc... gcc checking whether we are using the GNU Objective C compiler... yes checking whether gcc accepts -g... yes checking if the Objective C compiler supports instancetype... yes checking whether malloc is Doug Lea style... no checking for getpagesize... yes checking for working mmap... yes checking for main in -lXbsd... no checking for pthread library... none needed checking for thread support... yes checking for librsvg-2.0 >= 2.14.0... no checking for getaddrinfo_a in -lanl... no checking for dbus-1 >= 1.0... no checking for lgetfilecon in -lselinux... no checking for gnutls >= 2.12.2... yes checking for libsystemd >= 222... no checking for jansson >= 2.7... no checking sys/inotify.h usability... no checking sys/inotify.h presence... no checking for sys/inotify.h... no checking for libkqueue... no checking for library containing kqueue... none required checking for lcms2... yes checking for library containing inflateEnd... -lz checking gpm.h usability... no checking gpm.h presence... no checking for gpm.h... no checking for libxml-2.0 > 2.6.17... yes checking for htmlReadMemory in -lxml2... yes checking for maillock in -lmail... no checking for maillock in -llockfile... no checking for liblockfile.so... no checking maillock.h usability... no checking maillock.h presence... no checking for maillock.h... no checking for accept4... no checking for fchdir... yes checking for gethostname... yes checking for getrusage... yes checking for get_current_dir_name... no checking for lrand48... yes checking for random... yes checking for rint... yes checking for trunc... yes checking for select... yes checking for getpagesize... (cached) yes checking for setlocale... yes checking for newlocale... yes checking for getrlimit... yes checking for setrlimit... yes checking for shutdown... yes checking for pthread_sigmask... (cached) yes checking for strsignal... yes checking for setitimer... yes checking for timer_getoverrun... no checking for sendto... yes checking for recvfrom... yes checking for getsockname... yes checking for getifaddrs... yes checking for freeifaddrs... yes checking for gai_strerror... yes checking for sync... yes checking for getpwent... yes checking for endpwent... yes checking for getgrent... yes checking for endgrent... yes checking for cfmakeraw... yes checking for cfsetspeed... yes checking for __executable_start... no checking for log2... yes checking for prctl... no checking for aligned_alloc... no checking for posix_memalign... yes checking whether aligned_alloc is declared... no checking for posix_madvise... yes checking for __builtin_frame_address... yes checking for __builtin_unwind_init... yes checking for _LARGEFILE_SOURCE value needed for large files... no checking for grantpt... yes checking for getpt... no checking for posix_openpt... yes checking for library containing tputs... -lncurses checking for timerfd interface... no checking whether signals can be handled on alternate stack... yes checking gmp.h usability... yes checking gmp.h presence... yes checking for gmp.h... yes checking for library containing __gmpz_roinit_n... -lgmp checking valgrind/valgrind.h usability... no checking valgrind/valgrind.h presence... no checking for valgrind/valgrind.h... no checking for struct unipair.unicode... no checking for pid_t... yes checking vfork.h usability... no checking vfork.h presence... no checking for vfork.h... no checking for fork... yes checking for vfork... yes checking for working fork... yes checking for working vfork... (cached) yes checking for snprintf... yes checking whether GLib is linked in... no checking for nl_langinfo and CODESET... yes checking for nl_langinfo and _NL_PAPER_WIDTH... no checking for mbstate_t... yes checking for _setjmp... yes checking for sigsetjmp... yes checking for usable FIONREAD... yes checking for usable SIGIO... yes checking for struct alignment... yes checking for typeof syntax and keyword spelling... typeof checking for statement expressions... yes checking for working alloca.h... yes checking for alloca... yes checking whether // is distinct from /... no checking whether realpath works... no checking for unsigned long long int... yes checking whether byte ordering is bigendian... no checking whether the preprocessor supports include_next... yes checking whether system header files limit the line length... no checking if environ is properly declared... no checking for complete errno.h... yes checking whether lstat correctly handles trailing slash... no checking for mode_t... yes checking for st_dm_mode in struct stat... no checking whether strmode is declared... yes checking for gawk... gawk checking for getopt.h... (cached) yes checking for getopt_long_only... yes checking whether getopt is POSIX compatible... no checking for C/C++ restrict keyword... __restrict checking for struct timeval... yes checking for wide-enough struct timeval.tv_sec member... yes checking whether limits.h has LLONG_MAX, WORD_BIT, ULLONG_WIDTH etc.... no checking for long long int... yes checking whether stdint.h conforms to C99... no checking sys/inttypes.h usability... no checking sys/inttypes.h presence... no checking for sys/inttypes.h... no checking sys/bitypes.h usability... no checking sys/bitypes.h presence... no checking for sys/bitypes.h... no checking for bit size of ptrdiff_t... 64 checking for bit size of size_t... 64 checking for bit size of sig_atomic_t... 32 checking for bit size of wchar_t... 32 checking for bit size of wint_t... 32 checking whether sig_atomic_t is signed... yes checking whether wchar_t is signed... yes checking whether wint_t is signed... yes checking for ptrdiff_t integer literal suffix... l checking for size_t integer literal suffix... ul checking for sig_atomic_t integer literal suffix... checking for wchar_t integer literal suffix... checking for wint_t integer literal suffix... checking whether memmem is declared... yes checking whether memrchr is declared... no checking whether <limits.h> defines MIN and MAX... no checking whether <sys/param.h> defines MIN and MAX... yes checking whether time_t is signed... yes checking whether alarm is declared... yes checking for working mktime... no checking whether struct tm is in sys/time.h or time.h... time.h checking for struct tm.tm_zone... yes checking for struct tm.tm_gmtoff... yes checking whether <sys/select.h> is self-contained... yes checking for inline... inline checking for stdlib.h... (cached) yes checking for GNU libc compatible malloc... yes checking whether we are using the GNU C Library >= 2.1 or uClibc... no checking for sigset_t... yes checking for wchar_t... yes checking whether strnlen is declared... yes checking whether strtoimax is declared... yes checking for a thread-safe mkdir -p... /usr/local/bin/gmkdir -p checking whether stat file-mode macros are broken... no checking for struct timespec in <time.h>... yes checking whether clearerr_unlocked is declared... yes checking whether feof_unlocked is declared... yes checking whether ferror_unlocked is declared... yes checking whether fflush_unlocked is declared... no checking whether fgets_unlocked is declared... no checking whether fputc_unlocked is declared... no checking whether fputs_unlocked is declared... no checking whether fread_unlocked is declared... no checking whether fwrite_unlocked is declared... no checking whether getc_unlocked is declared... yes checking whether getchar_unlocked is declared... yes checking whether putc_unlocked is declared... yes checking whether putchar_unlocked is declared... yes checking whether the utimes function works... yes checking type of array argument to getgroups... gid_t checking whether getdtablesize is declared... yes checking for O_CLOEXEC... yes checking for promoted mode_t type... int checking sys/acl.h usability... yes checking sys/acl.h presence... yes checking for sys/acl.h... yes checking for library containing acl_get_file... none required checking for acl_get_file... yes checking for acl_get_fd... yes checking for acl_set_file... yes checking for acl_set_fd... yes checking for acl_free... yes checking for acl_from_mode... no checking for acl_from_text... yes checking for acl_delete_def_file... yes checking for acl_extended_file... no checking for acl_delete_fd_np... yes checking for acl_delete_file_np... yes checking for acl_copy_ext_native... yes checking for acl_create_entry_np... yes checking for acl_to_short_text... no checking for acl_free_text... no checking for working acl_get_file... yes checking acl/libacl.h usability... no checking acl/libacl.h presence... no checking for acl/libacl.h... no checking for acl_entries... no checking for ACL_FIRST_ENTRY... yes checking for ACL_TYPE_EXTENDED... yes checking for alloca as a compiler built-in... yes checking for __builtin_expect... yes checking byteswap.h usability... no checking byteswap.h presence... no checking for byteswap.h... no checking for library containing clock_gettime... none required checking for clock_gettime... yes checking for clock_settime... yes checking for copy_file_range... no checking for d_type member in directory struct... yes checking whether // is distinct from /... (cached) no checking whether dup2 works... yes checking for library containing backtrace_symbols_fd... none required checking for explicit_memset... no checking for access... yes checking whether fcntl handles F_DUPFD correctly... yes checking whether fcntl understands F_DUPFD_CLOEXEC... yes checking whether fdopendir is declared... yes checking whether fdopendir works... yes checking for flexible array member... yes checking for __fpending... no checking whether fstatat (..., 0) works... yes checking for sys/mount.h... yes checking how to get file system space usage... checking for statvfs function (SVR4)... no checking for two-argument statfs with statfs.f_frsize member... no checking for 3-argument statfs function (DEC OSF/1)... no checking for two-argument statfs with statfs.f_bsize member (AIX, 4.3BSD)... yes checking sys/fs/s5param.h usability... no checking sys/fs/s5param.h presence... no checking for sys/fs/s5param.h... no checking sys/statfs.h usability... no checking sys/statfs.h presence... no checking for sys/statfs.h... no checking for statfs that truncates block counts... no checking for getloadavg... yes checking sys/loadavg.h usability... no checking sys/loadavg.h presence... no checking for sys/loadavg.h... no checking whether getloadavg is declared... yes checking whether gettimeofday clobbers localtime buffer... no checking for gettimeofday with POSIX signature... yes checking for memmem... yes checking whether memmem works... no checking for memrchr... no checking whether signature of pselect conforms to POSIX... yes checking whether pselect detects invalid fds... yes checking whether pthread_sigmask is a macro... no checking whether pthread_sigmask works without -lpthread... yes checking whether pthread_sigmask returns error numbers... yes checking whether pthread_sigmask unblocks signals correctly... guessing yes checking whether readlink signature is correct... yes checking whether readlink handles trailing slash correctly... no checking whether readlinkat signature is correct... yes checking for working re_compile_pattern... no checking libintl.h usability... no checking libintl.h presence... no checking for libintl.h... no checking whether isblank is declared... yes checking for sig2str... no checking for volatile sig_atomic_t... yes checking for sighandler_t... no checking for socklen_t... yes checking for ssize_t... yes checking for struct stat.st_atim.tv_nsec... no checking for struct stat.st_atimespec.tv_nsec... yes checking for struct stat.st_birthtimespec.tv_nsec... yes checking for working stdalign.h... yes checking for good max_align_t... yes checking whether NULL can be used in arbitrary expressions... yes checking which flavor of printf attribute matches inttypes macros... system checking for stpcpy... yes checking for working strnlen... yes checking whether strtoimax works... yes checking whether symlink handles trailing slash correctly... no checking for nlink_t... yes checking whether localtime_r is declared... yes checking whether localtime_r is compatible with its POSIX signature... yes checking whether localtime loops forever near extrema... no checking for timezone_t... no checking for library containing timer_settime... no checking for timer_settime... no checking for variable-length arrays... yes checking whether open recognizes a trailing slash... no checking for euidaccess... no checking libgen.h usability... yes checking libgen.h presence... yes checking for libgen.h... yes checking for getgroups... yes checking for working getgroups... yes checking for library containing eaccess... no checking for eaccess... no checking for group_member... no checking for getgroups... (cached) yes checking for working getgroups... (cached) yes checking whether getgroups handles negative values... no checking whether the compiler supports the __inline keyword... yes checking for __mktime_internal... no checking for gcc option to disable position independent executables... not needed Configured for 'x86_64-apple-darwin16.7.0'. Where should the build process find the source code? . What compiler should emacs be built with? gcc -g3 -O2 Should Emacs use the GNU version of malloc? no (The GNU allocators don't work with this system configuration.) Should Emacs use a relocating allocator for buffers? no Should Emacs use mmap(2) for buffer allocation? no What window system should Emacs use? nextstep What toolkit should Emacs use? none Where do we find X Windows header files? /usr/X11/include Where do we find X Windows libraries? /usr/X11/lib Does Emacs use -lXaw3d? no Does Emacs use -lXpm? no Does Emacs use -ljpeg? no Does Emacs use -ltiff? no Does Emacs use a gif library? no Does Emacs use a png library? no Does Emacs use -lrsvg-2? no Does Emacs use cairo? no Does Emacs use -llcms2? yes Does Emacs use imagemagick? no Does Emacs support sound? no Does Emacs use -lgpm? no Does Emacs use -ldbus? no Does Emacs use -lgconf? no Does Emacs use GSettings? no Does Emacs use a file notification library? yes (kqueue) Does Emacs use access control lists? yes Does Emacs use -lselinux? no Does Emacs use -lgnutls? yes Does Emacs use -lxml2? yes Does Emacs use -lfreetype? no Does Emacs use HarfBuzz? no Does Emacs use -lm17n-flt? no Does Emacs use -lotf? no Does Emacs use -lxft? no Does Emacs use -lsystemd? no Does Emacs use -ljansson? no Does Emacs use -lgmp? yes Does Emacs directly use zlib? yes Does Emacs have dynamic modules support? no Does Emacs use toolkit scroll bars? yes Does Emacs support Xwidgets (requires gtk3)? no Does Emacs have threading support in lisp? yes Does Emacs support the portable dumper? yes Does Emacs support legacy unexec dumping? no Which dumping strategy does Emacs use? pdumper Run 'make' to build Emacs, then run 'src/emacs' to test it. Run 'make install' in order to build an application bundle. The application will go to nextstep/Emacs.app and can be run or moved from there. The application will be fully self-contained. configure: creating ./config.status configure: WARNING: This configuration installs a 'movemail' program that does not retrieve POP3 email. By default, Emacs 25 and earlier installed a 'movemail' program that retrieved POP3 email via only insecure channels, a practice that is no longer recommended but that you can continue to support by using './configure --with-pop'. configure: You might want to install GNU Mailutils <https://mailutils.org> and use './configure --with-mailutils'. MAKE='/Library/Developer/CommandLineTools/usr/bin/make' ./config.status config.status: creating src/emacs-module.h config.status: creating nextstep/Cocoa/Emacs.base/Contents/Info.plist config.status: creating nextstep/Cocoa/Emacs.base/Contents/Resources/English.lproj/InfoPlist.strings config.status: creating Makefile config.status: creating lib/gnulib.mk config.status: creating ./doc/man/emacs.1 config.status: creating lib/Makefile config.status: creating lib-src/Makefile config.status: creating oldXMenu/Makefile config.status: creating doc/emacs/Makefile config.status: creating doc/misc/Makefile config.status: creating doc/lispintro/Makefile config.status: creating doc/lispref/Makefile config.status: creating src/Makefile config.status: creating lwlib/Makefile config.status: creating lisp/Makefile config.status: creating leim/Makefile config.status: creating nextstep/Makefile config.status: creating nt/Makefile config.status: creating test/Makefile config.status: creating admin/charsets/Makefile config.status: creating admin/unidata/Makefile config.status: creating admin/grammars/Makefile config.status: creating src/config.h config.status: src/config.h is unchanged config.status: executing src/epaths.h commands config.status: executing src/.gdbinit commands config.status: executing doc/emacs/emacsver.texi commands config.status: executing etc-refcards-emacsver.tex commands /Library/Developer/CommandLineTools/usr/bin/make -C lib all /Library/Developer/CommandLineTools/usr/bin/make info-real info-dir GEN alloca.h GEN byteswap.h /Library/Developer/CommandLineTools/usr/bin/make -C doc/lispref info GEN ../../info/elisp.info /Library/Developer/CommandLineTools/usr/bin/make -C doc/lispintro info GEN dirent.h make[2]: Nothing to be done for `info'. /Library/Developer/CommandLineTools/usr/bin/make -C doc/emacs info GEN ../../info/emacs.info GEN fcntl.h GEN getopt.h GEN getopt-cdefs.h GEN ieee754.h GEN inttypes.h GEN limits.h GEN signal.h GEN stdint.h GEN stdio.h GEN stdlib.h GEN string.h GEN sys/select.h GEN sys/stat.h GEN sys/time.h GEN sys/types.h GEN time.h GEN unistd.h CC fingerprint.o CC acl_entries.o CC canonicalize-lgpl.o CC copy-file-range.o CC euidaccess.o CC explicit_bzero.o CC faccessat.o CC fpending.o CC fstatat.o CC fsusage.o CC getgroups.o CC getopt.o CC getopt1.o CC group-member.o CC lstat.o CC memmem.o CC memrchr.o CC mktime.o CC open.o CC openat-proc.o CC readlink.o CC readlinkat.o CC regex.o CC sig2str.o CC symlink.o CC time_rz.o CC timegm.o CC acl-errno-valid.o CC acl-internal.o CC get-permissions.o CC set-permissions.o CC allocator.o CC binary-io.o CC c-ctype.o CC c-strcasecmp.o CC c-strncasecmp.o CC careadlinkat.o CC cloexec.o CC close-stream.o CC count-leading-zeros.o CC count-one-bits.o CC count-trailing-zeros.o CC md5.o CC sha1.o CC sha256.o CC sha512.o CC dtoastr.o CC dtotimespec.o CC filemode.o CC filevercmp.o CC gettime.o CC malloca.o CC nstrftime.o CC pipe2.o CC qcopy-acl.o CC stat-time.o CC tempname.o CC timespec.o CC timespec-add.o CC timespec-sub.o CC u64.o CC unistd.o CC utimens.o CC openat-die.o CC save-cwd.o AR libgnu.a /Library/Developer/CommandLineTools/usr/bin/ranlib: file: libgnu.a(u64.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/ranlib: file: libgnu.a(unistd.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/ranlib: file: libgnu.a(u64.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/ranlib: file: libgnu.a(unistd.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/make -C doc/misc info GEN ../../info/emacs-mime.info GEN ../../info/efaq.info GEN ../../info/gnus.info /Library/Developer/CommandLineTools/usr/bin/make -C lib-src all CCLD etags GEN ../../info/smtpmail.info CCLD ctags CCLD emacsclient GEN info/dir CCLD ebrowse CCLD hexl CC pop.o CCLD make-docfile CCLD make-fingerprint CCLD movemail /Library/Developer/CommandLineTools/usr/bin/make -C src VCSWITNESS='$(srcdir)/../.git/logs/HEAD' all GEN globals.h GEN buildobj.h /Library/Developer/CommandLineTools/usr/bin/make -C ../admin/charsets all make[2]: Nothing to be done for `all'. /Library/Developer/CommandLineTools/usr/bin/make -C ../admin/unidata charscript.el make[2]: Nothing to be done for `charscript.el'. /Library/Developer/CommandLineTools/usr/bin/make -C ../admin/charsets cp51932.el make[2]: Nothing to be done for `cp51932.el'. /Library/Developer/CommandLineTools/usr/bin/make -C ../admin/charsets eucjp-ms.el make[2]: Nothing to be done for `eucjp-ms.el'. CC dispnew.o CC frame.o CC scroll.o CC xdisp.o CC menu.o CC window.o CC charset.o CC coding.o CC category.o CC ccl.o CC character.o CC chartab.o CC bidi.o CC cm.o CC term.o CC terminal.o CC xfaces.o CC emacs.o CC keyboard.o CC macros.o CC keymap.o CC sysdep.o CC bignum.o CC buffer.o CC filelock.o CC insdel.o CC marker.o CC minibuf.o CC fileio.o CC dired.o CC cmds.o CC casetab.o CC casefiddle.o CC indent.o CC search.o CC regex-emacs.o CC undo.o CC alloc.o CC pdumper.o CC data.o CC doc.o CC editfns.o CC callint.o CC eval.o CC floatfns.o CC fns.o CC font.o CC print.o CC lread.o CC syntax.o CC bytecode.o CC process.o CC gnutls.o CC callproc.o CC region-cache.o CC sound.o CC timefns.o CC atimer.o CC doprnt.o CC intervals.o CC textprop.o CC composite.o CC xml.o CC lcms.o CC kqueue.o CC profiler.o CC decompress.o CC thread.o CC systhread.o CC fontset.o CC fringe.o CC image.o CC nsterm.o CC nsfns.o CC nsmenu.o nsfns.m:2842:24: warning: 'NSWindow' may not respond to 'tabbar' int tab_bar_height = FRAME_TABBAR_HEIGHT (f); ^~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1086:33: note: expanded from macro 'FRAME_TABBAR_HEIGHT' (([[FRAME_NS_VIEW (f) window] tabbar] == nil \ ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ nsfns.m:2842:24: warning: 'NSWindow' may not respond to 'tabbar' int tab_bar_height = FRAME_TABBAR_HEIGHT (f); ^~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1087:38: note: expanded from macro 'FRAME_TABBAR_HEIGHT' || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ? \ ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ 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:1708:56: warning: 'NSWindow' may not respond to 'tabbar' f->top_pos = FRAME_PIXEL_HEIGHT (parent) + FRAME_TABBAR_HEIGHT (parent) + FRAME_TOOLBAR_HEIGHT (parent) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./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_TOOLBAR_HEIGHT (parent) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1087:38: 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: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: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:193:12: note: receiver is instance of class declared here @interface NSWindow : NSResponder <NSAnimatablePropertyContainer, NSUserInterfaceValidations, NSUserInterfaceItemIdentification, NSAppearanceCustomization, NSAccessibilityElement, NSAccessibility> ^ nsterm.m:2415:47: warning: 'NSWindow' may not respond to 'tabbar' FRAME_NS_TITLEBAR_HEIGHT(f) + 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:2415:47: warning: 'NSWindow' may not respond to 'tabbar' FRAME_NS_TITLEBAR_HEIGHT(f) + 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: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: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: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: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:193:12: note: receiver is instance of class declared here @interface NSWindow : NSResponder <NSAnimatablePropertyContainer, NSUserInterfaceValidations, NSUserInterfaceItemIdentification, NSAppearanceCustomization, NSAccessibilityElement, NSAccessibility> ^ nsmenu.m:1038:10: warning: 'NSWindow' may not respond to 'tabbar' oldh = FRAME_TABBAR_HEIGHT (f); ^~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1086:33: note: expanded from macro 'FRAME_TABBAR_HEIGHT' (([[FRAME_NS_VIEW (f) window] tabbar] == nil \ ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ nsmenu.m:1038:10: warning: 'NSWindow' may not respond to 'tabbar' oldh = FRAME_TABBAR_HEIGHT (f); ^~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1087:38: note: expanded from macro 'FRAME_TABBAR_HEIGHT' || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ? \ ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ nsmenu.m:1144:15: warning: 'NSWindow' may not respond to 'tabbar' if (oldh != FRAME_TABBAR_HEIGHT (f)) ^~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1086:33: note: expanded from macro 'FRAME_TABBAR_HEIGHT' (([[FRAME_NS_VIEW (f) window] tabbar] == nil \ ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ nsmenu.m:1144:15: warning: 'NSWindow' may not respond to 'tabbar' if (oldh != FRAME_TABBAR_HEIGHT (f)) ^~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1087:38: note: expanded from macro 'FRAME_TABBAR_HEIGHT' || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ? \ ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ nsmenu.m:1146:33: warning: 'NSWindow' may not respond to 'tabbar' if (view->wait_for_tab_bar && FRAME_TABBAR_HEIGHT (f) > 0) ^~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1086:33: note: expanded from macro 'FRAME_TABBAR_HEIGHT' (([[FRAME_NS_VIEW (f) window] tabbar] == nil \ ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ nsmenu.m:1146:33: warning: 'NSWindow' may not respond to 'tabbar' if (view->wait_for_tab_bar && FRAME_TABBAR_HEIGHT (f) > 0) ^~~~~~~~~~~~~~~~~~~~~~~ ./nsterm.h:1087:38: note: expanded from macro 'FRAME_TABBAR_HEIGHT' || ! [[FRAME_NS_VIEW (f) window] tabbar].isVisible) ? \ ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ nsmenu.m:1238:13: warning: instance method '-setTabTip:' not found (return type defaults to 'id') [-Wobjc-method-access] [item setTabTip: [NSString stringWithUTF8String: help]]; ^~~~~~~~~ /System/Library/Frameworks/AppKit.framework/Headers/NSToolbarItem.h:17:12: note: receiver is instance of class declared here @interface NSToolbarItem : NSObject <NSCopying, NSValidatedUserInterfaceItem> { ^ 2 warnings generated. CC nsselect.o 7 warnings generated. CC nsimage.o CC macfont.o CC terminfo.o CC lastfile.o 18 warnings generated. CCLD temacs /usr/local/bin/gmkdir -p ../etc /Library/Developer/CommandLineTools/usr/bin/make -C ../lisp update-subdirs cp -f temacs bootstrap-emacs rm -f bootstrap-emacs.pdmp ./temacs --batch -l loadup --temacs=pbootstrap Loading loadup.el (source)... dump mode: pbootstrap Using load-path (/Users/skangas/wip/emacs/lisp /Users/skangas/wip/emacs/lisp/emacs-lisp /Users/skangas/wip/emacs/lisp/progmodes /Users/skangas/wip/emacs/lisp/language /Users/skangas/wip/emacs/lisp/international /Users/skangas/wip/emacs/lisp/textmodes /Users/skangas/wip/emacs/lisp/vc) Loading emacs-lisp/byte-run... Loading emacs-lisp/backquote... Loading subr (source)... Loading version... Loading widget... Loading custom (source)... Loading emacs-lisp/map-ynp... Loading international/mule... Loading international/mule-conf... Loading env... Loading format... Loading bindings... Loading window (source)... Loading /Users/skangas/wip/emacs/lisp/files.el (source)... Loading emacs-lisp/macroexp... Loading cus-face... Loading faces... Loading button... Loading /Users/skangas/wip/emacs/lisp/loaddefs.el (source)... Loading emacs-lisp/nadvice... Loading emacs-lisp/cl-preloaded... Loading minibuffer... Loading obarray... Loading abbrev... Loading simple... Loading help... Loading jka-cmpr-hook... Loading epa-hook... Loading international/mule-cmds... Loading case-table... Loading /Users/skangas/wip/emacs/lisp/international/charprop.el (source)... Loading international/characters... Loading international/charscript... Loading /Users/skangas/wip/emacs/lisp/composite.el (source)... Loading language/chinese... Loading language/cyrillic... Loading language/indian... Loading language/sinhala... Loading language/english... Loading language/ethiopic... Loading language/european... Loading language/czech... Loading language/slovak... Loading language/romanian... Loading language/greek... Loading language/hebrew... Loading international/cp51932... Loading international/eucjp-ms... Loading language/japanese... Loading language/korean... Loading language/lao... Loading language/tai-viet... Loading language/thai... Loading language/tibetan... Loading language/vietnamese... Loading language/misc-lang... Loading language/utf-8-lang... Loading language/georgian... Loading language/khmer... Loading language/burmese... Loading language/cham... Loading indent... Loading emacs-lisp/cl-generic... Loading /Users/skangas/wip/emacs/lisp/frame.el (source)... Loading /Users/skangas/wip/emacs/lisp/startup.el (source)... Loading term/tty-colors... Loading font-core... Loading facemenu... Loading emacs-lisp/syntax... Loading font-lock... Loading jit-lock... Loading mouse... Loading scroll-bar... Loading /Users/skangas/wip/emacs/lisp/select.el (source)... Loading emacs-lisp/timer... Loading /Users/skangas/wip/emacs/lisp/isearch.el (source)... Loading rfn-eshadow... Loading /Users/skangas/wip/emacs/lisp/menu-bar.el (source)... Loading /Users/skangas/wip/emacs/lisp/tab-bar.el (source)... Loading emacs-lisp/lisp... Loading textmodes/page... Loading register... Loading textmodes/paragraphs... Loading progmodes/prog-mode... Loading emacs-lisp/lisp-mode... Loading progmodes/elisp-mode... Loading textmodes/text-mode... Loading textmodes/fill... Loading newcomment... Loading /Users/skangas/wip/emacs/lisp/replace.el (source)... Loading emacs-lisp/tabulated-list... Loading buff-menu... Loading fringe... Loading emacs-lisp/regexp-opt... Loading image... Loading international/fontset... Loading dnd... Loading tool-bar... Loading term/common-win... Loading international/mule-util... Loading international/ucs-normalize... Loading term/ns-win... Loading mwheel... Loading emacs-lisp/float-sup... Loading vc/vc-hooks... Loading vc/ediff-hook... Loading uniquify... Loading electric... Loading emacs-lisp/eldoc... Loading /Users/skangas/wip/emacs/lisp/cus-start.el (source)... Loading /Users/skangas/wip/emacs/lisp/tooltip.el (source)... Loading /Users/skangas/wip/emacs/lisp/leim/leim-list.el (source)... Finding pointers to doc strings... Finding pointers to doc strings...done Dumping under the name bootstrap-emacs.pdmp dumping fingerprint: 27d336e615f925f56b7bd68723e6010aa6d4692896a420de40673c741bf0bccc Dump complete Byte counts: header=80 hot=13310232 discardable=119040 cold=7424472 Reloc counts: hot=797203 discardable=4566 /Library/Developer/CommandLineTools/usr/bin/make -C ../lisp compile-first EMACS="../src/bootstrap-emacs" ELC emacs-lisp/bytecomp.elc ELC emacs-lisp/autoload.elc /Library/Developer/CommandLineTools/usr/bin/make -C ../lisp autoloads EMACS="../src/bootstrap-emacs" /Library/Developer/CommandLineTools/usr/bin/make -C ../leim all EMACS="../src/bootstrap-emacs" ELC ../lisp/cus-start.elc ELC ../lisp/composite.elc make[3]: Nothing to be done for `all'. /Library/Developer/CommandLineTools/usr/bin/make -C ../admin/grammars all EMACS="../../src/bootstrap-emacs" make[3]: Nothing to be done for `all'. GEN net/tramp-loaddefs.el ELC ../lisp/custom.elc ELC ../lisp/files.elc INFO Scraping files for tramp-loaddefs.el... INFO Scraping files for tramp-loaddefs.el...done Directories for loaddefs: . ./calc ./calendar ./cedet ./cedet/ede ./cedet/semantic ./cedet/semantic/analyze ./cedet/semantic/bovine ./cedet/semantic/decorate ./cedet/semantic/symref ./cedet/semantic/wisent ./cedet/srecode ./emacs-lisp ./emulation ./erc ./eshell ./gnus ./image ./international ./language ./leim ./leim/ja-dic ./leim/quail ./mail ./mh-e ./net ./nxml ./org ./play ./progmodes ./textmodes ./url ./vc GEN loaddefs.el ELC ../lisp/frame.elc /Library/Developer/CommandLineTools/usr/bin/make -C ../admin/unidata all EMACS="../../src/bootstrap-emacs" make[2]: Nothing to be done for `all'. ELC ../lisp/isearch.elc ELC ../lisp/menu-bar.elc ELC ../lisp/replace.elc ELC ../lisp/select.elc ELC ../lisp/startup.elc ELC ../lisp/subr.elc ELC ../lisp/tab-bar.elc INFO Scraping files for loaddefs.el... ELC ../lisp/tooltip.elc ELC ../lisp/window.elc INFO Scraping files for loaddefs.el...72% INFO Scraping files for loaddefs.el...100% INFO Scraping files for loaddefs.el...done GEN ../etc/DOC rm -f emacs && cp -f temacs emacs LC_ALL=C ./temacs -batch -l loadup --temacs=pdump Loading loadup.el (source)... dump mode: pdump Using load-path (/Users/skangas/wip/emacs/lisp) Loading emacs-lisp/byte-run... Loading emacs-lisp/backquote... Loading subr... Loading version... Loading widget... Loading custom... Loading emacs-lisp/map-ynp... Loading international/mule... Loading international/mule-conf... Loading env... Loading format... Loading bindings... Loading window... Loading files... Loading emacs-lisp/macroexp... Loading cus-face... Loading faces... Loading button... Loading loaddefs.el (source)... Loading emacs-lisp/nadvice... Loading emacs-lisp/cl-preloaded... Loading minibuffer... Loading obarray... Loading abbrev... Loading simple... Loading help... Loading jka-cmpr-hook... Loading epa-hook... Loading international/mule-cmds... Loading case-table... Loading international/charprop.el (source)... Loading international/characters... Loading international/charscript... Loading composite... Loading language/chinese... Loading language/cyrillic... Loading language/indian... Loading language/sinhala... Loading language/english... Loading language/ethiopic... Loading language/european... Loading language/czech... Loading language/slovak... Loading language/romanian... Loading language/greek... Loading language/hebrew... Loading international/cp51932... Loading international/eucjp-ms... Loading language/japanese... Loading language/korean... Loading language/lao... Loading language/tai-viet... Loading language/thai... Loading language/tibetan... Loading language/vietnamese... Loading language/misc-lang... Loading language/utf-8-lang... Loading language/georgian... Loading language/khmer... Loading language/burmese... Loading language/cham... Loading indent... Loading emacs-lisp/cl-generic... Loading frame... Loading startup... Loading term/tty-colors... Loading font-core... Loading facemenu... Loading emacs-lisp/syntax... Loading font-lock... Loading jit-lock... Loading mouse... Loading scroll-bar... Loading select... Loading emacs-lisp/timer... Loading isearch... Loading rfn-eshadow... Loading menu-bar... Loading tab-bar... Loading emacs-lisp/lisp... Loading textmodes/page... Loading register... Loading textmodes/paragraphs... Loading progmodes/prog-mode... Loading emacs-lisp/lisp-mode... Loading progmodes/elisp-mode... Loading textmodes/text-mode... Loading textmodes/fill... Loading newcomment... Loading replace... Loading emacs-lisp/tabulated-list... Loading buff-menu... Loading fringe... Loading emacs-lisp/regexp-opt... Loading image... Loading international/fontset... Loading dnd... Loading tool-bar... Loading term/common-win... Loading international/mule-util... Loading international/ucs-normalize... Loading term/ns-win... Loading mwheel... Loading emacs-lisp/float-sup... Loading vc/vc-hooks... Loading vc/ediff-hook... Loading uniquify... Loading electric... Loading emacs-lisp/eldoc... Loading cus-start... Loading tooltip... Loading leim/leim-list.el (source)... Waiting for git... Waiting for git... Finding pointers to doc strings... Finding pointers to doc strings...done Pure-hashed: 15462 strings, 4521 vectors, 39800 conses, 4161 bytecodes, 242 others Dumping under the name emacs.pdmp dumping fingerprint: 27d336e615f925f56b7bd68723e6010aa6d4692896a420de40673c741bf0bccc Dump complete Byte counts: header=80 hot=10615248 discardable=119040 cold=4521816 Reloc counts: hot=592723 discardable=4622 Adding name emacs-27.0.50.1 Adding name emacs-27.0.50.1.pdmp cp -f emacs.pdmp bootstrap-emacs.pdmp /Library/Developer/CommandLineTools/usr/bin/make -C ../nextstep all rm -rf /Users/skangas/wip/emacs/nextstep/Emacs.app rm -rf /Users/skangas/wip/emacs/nextstep/Emacs.app /usr/local/bin/gmkdir -p /Users/skangas/wip/emacs/nextstep/Emacs.app /Library/Developer/CommandLineTools/usr/bin/make -C ../src emacs /usr/local/bin/gmkdir -p /Users/skangas/wip/emacs/nextstep/Emacs.app ( cd ./Cocoa/Emacs.base ; tar cfh - . ) | \ ( cd /Users/skangas/wip/emacs/nextstep/Emacs.app ; umask 022; tar xf - ) ( cd ./Cocoa/Emacs.base ; tar cfh - . ) | \ ( cd /Users/skangas/wip/emacs/nextstep/Emacs.app ; umask 022; tar xf - ) ./Contents/Resources/Emacs.icns: Can't create 'Contents/Resources/Emacs.icns' tar: Error exit delayed from previous errors. make[2]: *** [/Users/skangas/wip/emacs/nextstep/Emacs.app/Contents/Info.plist] Error 1 make[2]: *** Waiting for unfinished jobs.... [ "`cd . && /bin/pwd`" = "`/bin/pwd`" ] || \ ( cd Cocoa/Emacs.base ; tar cfh - . ) | \ ( cd /Users/skangas/wip/emacs/nextstep/Emacs.app ; umask 022; tar xf - ) touch /Users/skangas/wip/emacs/nextstep/Emacs.app /Library/Developer/CommandLineTools/usr/bin/make -C ../admin/charsets all /Library/Developer/CommandLineTools/usr/bin/make -C ../admin/unidata charscript.el /Library/Developer/CommandLineTools/usr/bin/make -C ../admin/charsets cp51932.el make[4]: Nothing to be done for `cp51932.el'. /Library/Developer/CommandLineTools/usr/bin/make -C ../admin/charsets eucjp-ms.el make[4]: Nothing to be done for `eucjp-ms.el'. make[4]: Nothing to be done for `charscript.el'. make[4]: Nothing to be done for `all'. /Library/Developer/CommandLineTools/usr/bin/make -C ../admin/unidata all EMACS="../../src/bootstrap-emacs" make[4]: Nothing to be done for `all'. make[1]: *** [ns-app] Error 2 make: *** [src] Error 2 ^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: Tabs (on macos) 2019-09-17 9:29 ` Stefan Kangas @ 2019-09-17 20:28 ` Juri Linkov 2019-09-17 22:38 ` Stefan Kangas 2019-09-20 18:26 ` Alan Third 2019-09-17 23:29 ` Stefan Kangas 1 sibling, 2 replies; 219+ messages in thread From: Juri Linkov @ 2019-09-17 20:28 UTC (permalink / raw) To: Stefan Kangas; +Cc: Jean-Christophe Helary, Emacs developers > It now builds but emacs crashes on start. I don't have time to debug > it in gdb right now, but I'll look into it and send a proper > backtrace. For now, here's the crash output: Meanwhile, could you please answer a quick question: Does macOS builds support non-native tool-bar? (info "(emacs) Tool Bars") contains this explanation: NS builds consider the tool bar to be a window decoration, and therefore do not display it when a window is undecorated. *Note (elisp)Frame Parameters::. On macOS the tool bar is hidden when the frame is put into fullscreen, but can be displayed by moving the mouse pointer to the top of the screen. Does this mean that NS builds implement only external tool-bar? This might imply the need to use an external tab-bar as well. ^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: Tabs (on macos) 2019-09-17 20:28 ` Juri Linkov @ 2019-09-17 22:38 ` Stefan Kangas 2019-09-20 18:26 ` Alan Third 1 sibling, 0 replies; 219+ messages in thread From: Stefan Kangas @ 2019-09-17 22:38 UTC (permalink / raw) To: Juri Linkov; +Cc: Jean-Christophe Helary, Emacs developers Juri Linkov <juri@linkov.net> writes: > Meanwhile, could you please answer a quick question: Sorry, I don't know the answer to these questions. I'm not a macOS developer, I just use it because I have to at work. Best regards, Stefan Kangas ^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: Tabs (on macos) 2019-09-17 20:28 ` Juri Linkov 2019-09-17 22:38 ` Stefan Kangas @ 2019-09-20 18:26 ` Alan Third 1 sibling, 0 replies; 219+ messages in thread From: Alan Third @ 2019-09-20 18:26 UTC (permalink / raw) To: Juri Linkov; +Cc: Jean-Christophe Helary, Stefan Kangas, Emacs developers On Tue, Sep 17, 2019 at 11:28:14PM +0300, Juri Linkov wrote: > > It now builds but emacs crashes on start. I don't have time to debug > > it in gdb right now, but I'll look into it and send a proper > > backtrace. For now, here's the crash output: > > Meanwhile, could you please answer a quick question: > Does macOS builds support non-native tool-bar? > > (info "(emacs) Tool Bars") contains this explanation: > > NS builds consider the tool bar to be a window decoration, and > therefore do not display it when a window is undecorated. *Note > (elisp)Frame Parameters::. On macOS the tool bar is hidden when the > frame is put into fullscreen, but can be displayed by moving the mouse > pointer to the top of the screen. > > Does this mean that NS builds implement only external tool-bar? > This might imply the need to use an external tab-bar as well. NS doesn’t support a non‐native toolbar. I don’t see any reason why a non‐native tab bar couldn’t be written, although I suppose it may have to be a completely new implementation. Cocoa provides a native tab bar, but it’s not programmable, it simply merges (OS) windows together in one. -- Alan Third ^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: Tabs (on macos) 2019-09-17 9:29 ` Stefan Kangas 2019-09-17 20:28 ` Juri Linkov @ 2019-09-17 23:29 ` Stefan Kangas 1 sibling, 0 replies; 219+ messages in thread From: Stefan Kangas @ 2019-09-17 23:29 UTC (permalink / raw) To: Juri Linkov; +Cc: Jean-Christophe Helary, Emacs developers [-- Attachment #1: Type: text/plain, Size: 2243 bytes --] > It now builds but emacs crashes on start. I don't have time to debug > it in gdb right now, but I'll look into it and send a proper > backtrace. Here's the backtrace, quoted so gmail doesn't foul up the line breaks: > (gdb) bt full > #0 0x00007fffaa857d42 in ?? () from /usr/lib/system/libsystem_kernel.dylib > No symbol table info available. > #1 0x00007fffaa945457 in pthread_kill () from /usr/lib/system/libsystem_pthread.dylib > No symbol table info available. > #2 0x00007fffaa7bd420 in abort () from /usr/lib/system/libsystem_c.dylib > No symbol table info available. > #3 0xffffffff5fbf44b0 in ?? () > No symbol table info available. > #4 0x0000000000000030 in ?? () > No symbol table info available. > #5 0x00007fffffffffdf in ?? () > No symbol table info available. > #6 0x00007fffb363ea20 in ?? () > No symbol table info available. > #7 0x00007fff5fbf44a0 in ?? () > No symbol table info available. > #8 0x00007fffa92bd94a in vtable for std::__1::codecvt<wchar_t, char, __mbstate_t> () from /usr/lib/libc++.1.dylib > No symbol table info available. > #9 0x0000000000000e5b in ?? () > No symbol table info available. > #10 0x00007fffa92e3ce2 in __cxxabiv1::(anonymous namespace)::parse_block_invoke<__cxxabiv1::(anonymous namespace)::Db>(char const*, char const*, __cxxabiv1::(anonymous namespace)::Db&)::test () from /usr/lib/libc++abi.dylib > No symbol table info available. > #11 0x00007fff95322bd0 in ?? () from /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation > No symbol table info available. > #12 0x00007fffa9dfd553 in ?? () from /usr/lib/libobjc.A.dylib > No symbol table info available. > #13 0x9ac464e898fa0089 in ?? () > No symbol table info available. > #14 0x00007fff95322bd0 in ?? () from /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation > No symbol table info available. > #15 0x0000000000000000 in ?? () > No symbol table info available. > > Lisp Backtrace: > Cannot access memory at address 0x20ecf40 Not sure why I'm getting "No symbol table info available". I've configured using CFLAGS='-O0 -g3' after running make maintainer-clean. There is also the apple backtrace. Please see the attached file for that. Best regards, Stefan Kangas [-- Attachment #2: apple-backtrace.txt --] [-- Type: text/plain, Size: 54452 bytes --] Process: emacs [79936] Path: /Users/USER/*/emacs Identifier: emacs Version: 0 Code Type: X86-64 (Native) Parent Process: bash [73574] Responsible: emacs [79936] User ID: 501 Date/Time: 2019-09-18 01:24:29.411 +0200 OS Version: Mac OS X 10.12.6 (16G2128) Report Version: 12 Anonymous UUID: 7494B2A9-35AD-169B-5A72-B76AC2BB0CA9 Sleep/Wake UUID: D9A0776A-E9B1-4FCF-9530-8C8EFCD8C453 Time Awake Since Boot: 720000 seconds Time Since Wake: 18000 seconds System Integrity Protection: enabled Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Application Specific Information: *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[EmacsWindow setTabbar:]: unrecognized selector sent to instance 0x7fe4cae809f0' terminating with uncaught exception of type NSException abort() called Application Specific Backtrace 1: 0 CoreFoundation 0x00007fff94faf46b __exceptionPreprocess + 171 1 libobjc.A.dylib 0x00007fffa9def48d objc_exception_throw + 48 2 CoreFoundation 0x00007fff950310e4 -[NSObject(NSObject) doesNotRecognizeSelector:] + 132 3 CoreFoundation 0x00007fff94f20b05 ___forwarding___ + 1061 4 CoreFoundation 0x00007fff94f20658 _CF_forwarding_prep_0 + 120 5 emacs 0x0000000109b64a2f -[EmacsView createTabbar:] + 239 6 emacs 0x0000000109b6547d -[EmacsView initFrameFromEmacs:] + 2125 7 emacs 0x0000000109b85361 Fx_create_frame + 9921 8 emacs 0x0000000109a17884 funcall_subr + 884 9 emacs 0x0000000109a15eee Ffuncall + 494 10 emacs 0x0000000109aa5fff exec_byte_code + 14415 11 emacs 0x0000000109a17f75 funcall_lambda + 965 12 emacs 0x0000000109a15f3e Ffuncall + 574 13 emacs 0x0000000109aa5fff exec_byte_code + 14415 14 emacs 0x0000000109a17f75 funcall_lambda + 965 15 emacs 0x0000000109a15f3e Ffuncall + 574 16 emacs 0x0000000109a107c8 Fapply + 280 17 emacs 0x0000000109a17766 funcall_subr + 598 18 emacs 0x0000000109a15eee Ffuncall + 494 19 emacs 0x0000000109aa5fff exec_byte_code + 14415 20 emacs 0x0000000109a17f75 funcall_lambda + 965 21 emacs 0x0000000109a15f3e Ffuncall + 574 22 emacs 0x0000000109aa5fff exec_byte_code + 14415 23 emacs 0x0000000109a17f75 funcall_lambda + 965 24 emacs 0x0000000109a15f3e Ffuncall + 574 25 emacs 0x0000000109aa5fff exec_byte_code + 14415 26 emacs 0x0000000109a17f75 funcall_lambda + 965 27 emacs 0x0000000109a15f3e Ffuncall + 574 28 emacs 0x0000000109aa5fff exec_byte_code + 14415 29 emacs 0x0000000109a17f75 funcall_lambda + 965 30 emacs 0x0000000109a15f3e Ffuncall + 574 31 emacs 0x0000000109aa5fff exec_byte_code + 14415 32 emacs 0x0000000109a17f75 funcall_lambda + 965 33 emacs 0x0000000109a105ae apply_lambda + 9198 34 emacs 0x0000000109a04bf7 eval_sub + 12935 35 emacs 0x0000000109a0df6d Feval + 173 36 emacs 0x00000001098e77ca top_level_2 + 42 37 emacs 0x0000000109a0c3ff internal_condition_case + 127 38 emacs 0x00000001098e73e1 top_level_1 + 97 39 emacs 0x0000000109a0b558 internal_catch + 72 40 emacs 0x00000001098c4604 command_loop + 276 41 emacs 0x00000001098c4437 recursive_edit_1 + 215 42 emacs 0x00000001098c4886 Frecursive_edit + 470 43 emacs 0x00000001098c194a main + 7162 44 libdyld.dylib 0x00007fffaa729235 start + 1 45 ??? 0x0000000000000002 0x0 + 2 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fffaa857d42 __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fffaa945457 pthread_kill + 90 2 libsystem_c.dylib 0x00007fffaa76e497 raise + 26 3 emacs 0x00000001098bf887 terminate_due_to_signal + 380 (emacs.c:405) 4 emacs 0x0000000109907a3a emacs_abort + 19 5 emacs 0x0000000109b5a648 ns_term_shutdown + 168 (nsterm.m:5492) 6 emacs 0x00000001098bfcc5 shut_down_emacs + 661 (emacs.c:2513) 7 emacs 0x00000001098bf823 terminate_due_to_signal + 280 (emacs.c:389) 8 emacs 0x000000010990cd88 handle_fatal_signal + 24 9 emacs 0x000000010990ce22 deliver_thread_signal + 146 (sysdep.c:1765) 10 emacs 0x000000010990a0da deliver_fatal_thread_signal + 26 (sysdep.c:1803) 11 libsystem_platform.dylib 0x00007fffaa938b3a _sigtramp + 26 12 ??? 0x00000003b363e240 0 + 15894569536 13 libsystem_c.dylib 0x00007fffaa7bd420 abort + 129 14 libc++abi.dylib 0x00007fffa92bd94a abort_message + 266 15 libc++abi.dylib 0x00007fffa92e2c2f default_terminate_handler() + 267 16 libobjc.A.dylib 0x00007fffa9df16fe _objc_terminate() + 103 17 libc++abi.dylib 0x00007fffa92dfd49 std::__terminate(void (*)()) + 8 18 libc++abi.dylib 0x00007fffa92df7be __cxa_throw + 121 19 libobjc.A.dylib 0x00007fffa9def5b6 objc_exception_throw + 345 20 com.apple.CoreFoundation 0x00007fff950310e4 -[NSObject(NSObject) doesNotRecognizeSelector:] + 132 21 com.apple.CoreFoundation 0x00007fff94f20b05 ___forwarding___ + 1061 22 com.apple.CoreFoundation 0x00007fff94f20658 _CF_forwarding_prep_0 + 120 23 emacs 0x0000000109b64a2f -[EmacsView createTabbar:] + 239 (nsterm.m:7327) 24 emacs 0x0000000109b6547d -[EmacsView initFrameFromEmacs:] + 2125 (nsterm.m:7456) 25 emacs 0x0000000109b85361 Fx_create_frame + 9921 (nsfns.m:1384) 26 emacs 0x0000000109a17884 funcall_subr + 884 (eval.c:2876) 27 emacs 0x0000000109a15eee Ffuncall + 494 (eval.c:2803) 28 emacs 0x0000000109aa5fff exec_byte_code + 14415 (bytecode.c:633) 29 emacs 0x0000000109a17f75 funcall_lambda + 965 (eval.c:2998) 30 emacs 0x0000000109a15f3e Ffuncall + 574 (eval.c:2805) 31 emacs 0x0000000109aa5fff exec_byte_code + 14415 (bytecode.c:633) 32 emacs 0x0000000109a17f75 funcall_lambda + 965 (eval.c:2998) 33 emacs 0x0000000109a15f3e Ffuncall + 574 (eval.c:2805) 34 emacs 0x0000000109a107c8 Fapply + 280 (eval.c:2382) 35 emacs 0x0000000109a17766 funcall_subr + 598 (eval.c:2856) 36 emacs 0x0000000109a15eee Ffuncall + 494 (eval.c:2803) 37 emacs 0x0000000109aa5fff exec_byte_code + 14415 (bytecode.c:633) 38 emacs 0x0000000109a17f75 funcall_lambda + 965 (eval.c:2998) 39 emacs 0x0000000109a15f3e Ffuncall + 574 (eval.c:2805) 40 emacs 0x0000000109aa5fff exec_byte_code + 14415 (bytecode.c:633) 41 emacs 0x0000000109a17f75 funcall_lambda + 965 (eval.c:2998) 42 emacs 0x0000000109a15f3e Ffuncall + 574 (eval.c:2805) 43 emacs 0x0000000109aa5fff exec_byte_code + 14415 (bytecode.c:633) 44 emacs 0x0000000109a17f75 funcall_lambda + 965 (eval.c:2998) 45 emacs 0x0000000109a15f3e Ffuncall + 574 (eval.c:2805) 46 emacs 0x0000000109aa5fff exec_byte_code + 14415 (bytecode.c:633) 47 emacs 0x0000000109a17f75 funcall_lambda + 965 (eval.c:2998) 48 emacs 0x0000000109a15f3e Ffuncall + 574 (eval.c:2805) 49 emacs 0x0000000109aa5fff exec_byte_code + 14415 (bytecode.c:633) 50 emacs 0x0000000109a17f75 funcall_lambda + 965 (eval.c:2998) 51 emacs 0x0000000109a105ae apply_lambda + 9198 (eval.c:2935) 52 emacs 0x0000000109a04bf7 eval_sub + 12935 (eval.c:2319) 53 emacs 0x0000000109a0df6d Feval + 173 (eval.c:2103) 54 emacs 0x00000001098e77ca top_level_2 + 42 (keyboard.c:1100) 55 emacs 0x0000000109a0c3ff internal_condition_case + 127 (eval.c:1355) 56 emacs 0x00000001098e73e1 top_level_1 + 97 (keyboard.c:1108) 57 emacs 0x0000000109a0b558 internal_catch + 72 (eval.c:1116) 58 emacs 0x00000001098c4604 command_loop + 276 (keyboard.c:1069) 59 emacs 0x00000001098c4437 recursive_edit_1 + 215 (keyboard.c:714) 60 emacs 0x00000001098c4886 Frecursive_edit + 470 (keyboard.c:786) 61 emacs 0x00000001098c194a main + 7162 (emacs.c:2086) 62 libdyld.dylib 0x00007fffaa729235 start + 1 Thread 1: 0 libsystem_kernel.dylib 0x00007fffaa85844e __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fffaa942621 _pthread_wqthread + 1426 2 libsystem_pthread.dylib 0x00007fffaa94207d start_wqthread + 13 Thread 2: 0 libsystem_kernel.dylib 0x00007fffaa85844e __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fffaa942621 _pthread_wqthread + 1426 2 libsystem_pthread.dylib 0x00007fffaa94207d start_wqthread + 13 Thread 3: 0 libsystem_kernel.dylib 0x00007fffaa85844e __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fffaa94248e _pthread_wqthread + 1023 2 libsystem_pthread.dylib 0x00007fffaa94207d start_wqthread + 13 Thread 4: 0 libsystem_kernel.dylib 0x00007fffaa857eb6 __select + 10 1 emacs 0x0000000109b5c3ba -[EmacsApp fd_handler:] + 202 (nsterm.m:5981) 2 com.apple.Foundation 0x00007fff969497dd __NSThread__start__ + 1243 3 libsystem_pthread.dylib 0x00007fffaa94293b _pthread_body + 180 4 libsystem_pthread.dylib 0x00007fffaa942887 _pthread_start + 286 5 libsystem_pthread.dylib 0x00007fffaa94208d thread_start + 13 Thread 5:: com.apple.NSEventThread 0 libsystem_kernel.dylib 0x00007fffaa85034a mach_msg_trap + 10 1 libsystem_kernel.dylib 0x00007fffaa84f797 mach_msg + 55 2 com.apple.CoreFoundation 0x00007fff94f257e4 __CFRunLoopServiceMachPort + 212 3 com.apple.CoreFoundation 0x00007fff94f24c71 __CFRunLoopRun + 1361 4 com.apple.CoreFoundation 0x00007fff94f244c4 CFRunLoopRunSpecific + 420 5 com.apple.AppKit 0x00007fff92b66f02 _NSEventThread + 205 6 libsystem_pthread.dylib 0x00007fffaa94293b _pthread_body + 180 7 libsystem_pthread.dylib 0x00007fffaa942887 _pthread_start + 286 8 libsystem_pthread.dylib 0x00007fffaa94208d thread_start + 13 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0000000000000000 rbx: 0x0000000000000006 rcx: 0x00007fff56504868 rdx: 0x0000000000000000 rdi: 0x0000000000000307 rsi: 0x0000000000000006 rbp: 0x00007fff56504890 rsp: 0x00007fff56504868 r8: 0x0000000000000002 r9: 0x00007fe4cad1d710 r10: 0x0000000008000000 r11: 0x0000000000000206 r12: 0x00007fff565053e0 r13: 0x0000000000000030 r14: 0x00007fffb365a3c0 r15: 0x0000000000000008 rip: 0x00007fffaa857d42 rfl: 0x0000000000000206 cr2: 0x00007fff95072420 Logical CPU: 0 Error Code: 0x02000148 Trap Number: 133 Binary Images: 0x1096ef000 - 0x109c32ff3 +emacs (0) <84204CBE-7A29-30D5-AE5D-6EFC6C4B724F> /Users/USER/*/emacs 0x10a25a000 - 0x10a3a4fcb +libgnutls.30.dylib (0) <5B80947A-73B0-3451-80EA-B211D8046100> /usr/local/opt/gnutls/lib/libgnutls.30.dylib 0x10a3ee000 - 0x10a426ffb +liblcms2.2.dylib (0) <16969B00-10FD-31FC-BB14-DE1C056658A5> /usr/local/opt/little-cms2/lib/liblcms2.2.dylib 0x10a43d000 - 0x10a49cfc7 +libgmp.10.dylib (0) <795EB8F9-E194-3677-B253-2EDB84AB55FB> /usr/local/opt/gmp/lib/libgmp.10.dylib 0x10a4a9000 - 0x10a551fff +libp11-kit.0.dylib (0) <998DC264-D10E-3F55-B61C-7C66FDC359B4> /usr/local/opt/p11-kit/lib/libp11-kit.0.dylib 0x10a59f000 - 0x10a5bbffb +libidn2.0.dylib (0) <42960C9F-F71B-3F82-AD8C-A08E30AF5048> /usr/local/opt/libidn2/lib/libidn2.0.dylib 0x10a5c0000 - 0x10a726ff7 +libunistring.2.dylib (0) <FD8AE4C2-FA79-3935-AAA7-146844F92462> /usr/local/opt/libunistring/lib/libunistring.2.dylib 0x10a73e000 - 0x10a749ffb +libtasn1.6.dylib (0) <6202466B-49DD-3E60-A8FB-E93FA215C2E8> /usr/local/opt/libtasn1/lib/libtasn1.6.dylib 0x10a74f000 - 0x10a775ffb +libnettle.6.dylib (0) <D9206C76-D0A1-3C45-AC35-CA19A5056F08> /usr/local/opt/nettle/lib/libnettle.6.dylib 0x10a782000 - 0x10a7abff7 +libhogweed.4.dylib (0) <F51E95CD-688C-3A95-BE32-F7FEC1B5C6C0> /usr/local/opt/nettle/lib/libhogweed.4.dylib 0x10a7bb000 - 0x10a7c3ffb +libintl.8.dylib (0) <663DB8F0-422F-3181-8788-FE5DE974B7FA> /usr/local/opt/gettext/lib/libintl.8.dylib 0x10a7cd000 - 0x10a7d1ff7 +libffi.6.dylib (0) <45DBAA49-5541-3015-9C4B-BF0E7C813B35> /usr/local/opt/libffi/lib/libffi.6.dylib 0x10dcf5000 - 0x10dd0cffb libCGInterfaces.dylib (331.5) <17109679-A284-3C72-AA60-DBA815D3062B> /System/Library/Frameworks/Accelerate.framework/Frameworks/vImage.framework/Versions/A/Libraries/libCGInterfaces.dylib 0x1198a1000 - 0x1198dedc7 dyld (434) <33DB4E37-BC29-37A4-92AB-30328E66A8FA> /usr/lib/dyld 0x7fff8fb4c000 - 0x7fff8fe91ff7 com.apple.RawCamera.bundle (7.04 - 914) <86A67D11-9791-3CE6-9FF5-3387C0AB925B> /System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera 0x7fff919f5000 - 0x7fff919f5fff com.apple.Accelerate (1.11 - Accelerate 1.11) <916E360F-323C-3AE1-AB3D-D1F3B284AEE9> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate 0x7fff91a0e000 - 0x7fff91f27feb com.apple.vImage (8.1 - ???) <B58A7937-BEE2-38FE-87F4-5D5F40D31DC9> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage 0x7fff91f28000 - 0x7fff92099ff3 libBLAS.dylib (1185.50.4) <4087FFE0-627E-3623-96B4-F0A9A1991E09> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 0x7fff9209a000 - 0x7fff920aeffb libBNNS.dylib (15) <254698C7-7D36-3FFF-864E-ADEEEE543076> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBNNS.dylib 0x7fff920af000 - 0x7fff924a5fef libLAPACK.dylib (1185.50.4) <C35FFB2F-A0E6-3903-8A3C-113A74BCBCA2> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib 0x7fff924a6000 - 0x7fff924bcfff libLinearAlgebra.dylib (1185.50.4) <345CAACF-7263-36EF-B69B-793EA8B390AF> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLinearAlgebra.dylib 0x7fff924bd000 - 0x7fff924c3fff libQuadrature.dylib (3) <EF56C8E6-DE22-3C69-B543-A8648F335FDD> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libQuadrature.dylib 0x7fff924c4000 - 0x7fff924d8ff7 libSparseBLAS.dylib (1185.50.4) <67BA432E-FB59-3C78-A8BE-ED4274CBC359> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparseBLAS.dylib 0x7fff924d9000 - 0x7fff92660fe7 libvDSP.dylib (600.60.1) <4155F45B-41CD-3782-AE8F-7AE740FD83C3> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib 0x7fff92661000 - 0x7fff92713fff libvMisc.dylib (600.60.1) <E18365D7-DCC4-3304-A8D1-395E656D7B99> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib 0x7fff92714000 - 0x7fff92714fff com.apple.Accelerate.vecLib (3.11 - vecLib 3.11) <7C5733E7-0568-3E7D-AF61-160F19FED544> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib 0x7fff929d3000 - 0x7fff937acff3 com.apple.AppKit (6.9 - 1504.83.101) <C7A0F7F4-F4F5-3735-8A6B-EE01CF527E80> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x7fff937be000 - 0x7fff937befff com.apple.ApplicationServices (48 - 48) <36EB2785-BBD2-33F0-BB13-8C804D47110A> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices 0x7fff937bf000 - 0x7fff9382dff7 com.apple.ApplicationServices.ATS (377 - 422.4) <78B556FF-28E6-3147-AE0D-8E0EC45EEE77> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS 0x7fff938c7000 - 0x7fff939f6fff libFontParser.dylib (194.15) <FF329191-6339-363E-9D95-FFE9D55E7F60> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib 0x7fff939f7000 - 0x7fff93a41ff7 libFontRegistry.dylib (196.8) <5E5F95FD-F69B-3F1A-9592-C0AB8F5FF57C> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib 0x7fff93a9f000 - 0x7fff93ad2fff libTrueTypeScaler.dylib (194.15) <513743F9-500B-37C5-A925-A82E7182F3E9> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libTrueTypeScaler.dylib 0x7fff93b3f000 - 0x7fff93be9ff7 com.apple.ColorSync (4.12.0 - 502.2) <ACA4001E-A0E3-33F6-9CD6-EEC2AA15E322> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync 0x7fff93bea000 - 0x7fff93c3bfff com.apple.HIServices (1.22 - 594) <EF8432A1-15C5-360C-9D14-19ADA43FCFDC> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices 0x7fff93c3c000 - 0x7fff93c4bff3 com.apple.LangAnalysis (1.7.0 - 1.7.0) <2CBE7F61-2056-3F96-99A1-0D527796AFA6> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis 0x7fff93c4c000 - 0x7fff93c99fff com.apple.print.framework.PrintCore (12 - 491) <5027FD58-F0EE-33E4-8577-934CA06CD2AF> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore 0x7fff93c9a000 - 0x7fff93cd5fff com.apple.QD (3.12 - 313) <B339C41D-8CDF-3342-8414-F9717DCCADD4> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD 0x7fff93cd6000 - 0x7fff93ce1fff com.apple.speech.synthesis.framework (6.6.2 - 6.6.2) <7853EFF4-62B9-394E-B7B8-41A645656820> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis 0x7fff93ce2000 - 0x7fff93eeeff7 com.apple.audio.toolbox.AudioToolbox (1.14 - 1.14) <1F4026C6-23C1-39E8-823D-72298FECF75C> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox 0x7fff93eef000 - 0x7fff93eeffff com.apple.audio.units.AudioUnit (1.14 - 1.14) <2CEE36AF-79E6-3B3E-B369-285E6C1886F7> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit 0x7fff94058000 - 0x7fff94435fff com.apple.CFNetwork (811.11 - 811.11) <5E5A7D4D-BCBA-3995-8C13-4D01DE1FAB33> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork 0x7fff9444f000 - 0x7fff9444ffff com.apple.Carbon (154 - 157) <69F403C7-F0CB-34E6-89B0-235CF4978C17> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 0x7fff94450000 - 0x7fff94453fff com.apple.CommonPanels (1.2.6 - 98) <BF04BB22-D54C-309E-9F5C-897D969CAF70> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels 0x7fff94454000 - 0x7fff9475dfff com.apple.HIToolbox (2.1.1 - 857.8) <25E0AC26-27FE-32E5-9226-F4D42B25ED30> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox 0x7fff9475e000 - 0x7fff94761ff7 com.apple.help (1.3.5 - 49) <B1A930E3-5907-3677-BACD-858EF68B172D> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help 0x7fff94762000 - 0x7fff94767fff com.apple.ImageCapture (9.0 - 9.0) <341252B4-E082-361A-B756-6A330259C741> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture 0x7fff94768000 - 0x7fff947ffff3 com.apple.ink.framework (10.9 - 219) <1BD40B45-FD33-3177-A935-565EE5FC79D7> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink 0x7fff94800000 - 0x7fff9481afff com.apple.openscripting (1.7 - 172.1) <78F3256B-AF4C-324A-A591-ECA4443A469F> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting 0x7fff9481b000 - 0x7fff9481cff3 com.apple.print.framework.Print (12 - 267) <E2F82F1F-DC27-3EF0-9F75-B354F701450A> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print 0x7fff9481d000 - 0x7fff9481fff7 com.apple.securityhi (9.0 - 55006) <0DA7BABC-CE24-35FC-BF23-8EDF72D8C237> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI 0x7fff94820000 - 0x7fff94826ff7 com.apple.speech.recognition.framework (6.0.1 - 6.0.1) <082895DC-3AC7-3DEF-ADCA-5B018C19C9D3> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition 0x7fff94a51000 - 0x7fff94adefff com.apple.audio.CoreAudio (4.3.0 - 4.3.0) <78767F88-91D4-31CE-AAC6-1F9407F479BB> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio 0x7fff94adf000 - 0x7fff94af2fff com.apple.CoreBluetooth (1.0 - 1) <BCB78777-76F0-3CC1-8443-9E61AEF7EF63> /System/Library/Frameworks/CoreBluetooth.framework/Versions/A/CoreBluetooth 0x7fff94af3000 - 0x7fff94deefff com.apple.CoreData (120 - 754.2) <4C9CAB2C-60D4-3694-A0A0-5B04B14BD14E> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData 0x7fff94def000 - 0x7fff94e9cff7 com.apple.CoreDisplay (1.0 - 1) <53D1EAFE-23A4-398D-BF52-E4299E670DB6> /System/Library/Frameworks/CoreDisplay.framework/Versions/A/CoreDisplay 0x7fff94e9d000 - 0x7fff95338fe7 com.apple.CoreFoundation (6.9 - 1349.98) <78CE7738-61B5-3997-902E-053426B3C2A9> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x7fff95339000 - 0x7fff959bbfff com.apple.CoreGraphics (2.0 - 1070.22.1) <8A053296-AA99-371C-B9C5-FCBF87C6CEFE> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics 0x7fff959bc000 - 0x7fff95bffffb com.apple.CoreImage (12.4.0 - 451.4.9) <BE4303C9-C9D9-361D-AC94-DBE40EB6700E> /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage 0x7fff95d64000 - 0x7fff95d64fff com.apple.CoreServices (775.20 - 775.20) <6DE824F2-B5FF-3EDA-8618-AED3C8020024> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 0x7fff95d65000 - 0x7fff95db6fff com.apple.AE (712.6 - 712.6) <9E9B4EC3-564D-3BA9-A9A4-1603E1F97F40> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE 0x7fff95db7000 - 0x7fff96092ff7 com.apple.CoreServices.CarbonCore (1159.8 - 1159.8) <2B661676-E4F2-3E6F-BD25-DB685FCCA06A> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore 0x7fff96093000 - 0x7fff960c6fff com.apple.DictionaryServices (1.2 - 274) <D23866E2-F7C8-3984-A9D4-96552CCDE573> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices 0x7fff960c7000 - 0x7fff960cfff3 com.apple.CoreServices.FSEvents (1230.50.1 - 1230.50.1) <2AD1B0E5-7214-37C4-8D11-A27C9CAC0F74> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/FSEvents.framework/Versions/A/FSEvents 0x7fff960d0000 - 0x7fff9623cffb com.apple.LaunchServices (775.20 - 775.20) <9106FF16-9587-313F-822C-2CD56204903E> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices 0x7fff9623d000 - 0x7fff962edffb com.apple.Metadata (10.7.0 - 1075.41) <FE2BC948-5014-3C50-9ED7-F9544B611363> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata 0x7fff962ee000 - 0x7fff9634dfff com.apple.CoreServices.OSServices (775.20 - 775.20) <82D7E763-999D-31A0-AAE7-4F7A40105739> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices 0x7fff9634e000 - 0x7fff963befff com.apple.SearchKit (1.4.0 - 1.4.0) <7A6DDA2B-03F1-3137-BA9E-1CC211973E26> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit 0x7fff963bf000 - 0x7fff96404ff7 com.apple.coreservices.SharedFileList (38 - 38) <DA096678-93AB-3291-BDE2-482F1D544589> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SharedFileList.framework/Versions/A/SharedFileList 0x7fff9648d000 - 0x7fff965daffb com.apple.CoreText (352.0 - 544.18) <B883809B-561B-31C5-949E-D2564B6F808A> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText 0x7fff965db000 - 0x7fff96610ff3 com.apple.CoreVideo (1.8 - 235.3) <AC11D5FB-C77B-34F5-B942-F698E84C229F> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo 0x7fff96611000 - 0x7fff96682ffb com.apple.framework.CoreWLAN (11.0 - 1200.31) <7300F2B4-0976-37F3-95E9-4B3BC102ED01> /System/Library/Frameworks/CoreWLAN.framework/Versions/A/CoreWLAN 0x7fff96780000 - 0x7fff96785fff com.apple.DiskArbitration (2.7 - 2.7) <F47E07A4-D69D-312A-82C8-A1EE3C7C0EAC> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration 0x7fff96917000 - 0x7fff96cbdff3 com.apple.Foundation (6.9 - 1349.92) <CF64A84C-CBBD-3B6B-BC49-CF05398F2280> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 0x7fff96ce9000 - 0x7fff96d1afff com.apple.GSS (4.0 - 2.0) <453B5C6D-08B0-3199-AFC8-C71BABD6B704> /System/Library/Frameworks/GSS.framework/Versions/A/GSS 0x7fff96dda000 - 0x7fff96e7dff7 com.apple.Bluetooth (5.0.5 - 5.0.5f7) <DC83B429-A8C1-34F1-9FD9-C9BB99156DBE> /System/Library/Frameworks/IOBluetooth.framework/Versions/A/IOBluetooth 0x7fff96e7e000 - 0x7fff96f14fff com.apple.framework.IOKit (2.0.2 - 1324.60.8) <46DA8966-AC27-3F51-BBB2-359A229BB0F7> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 0x7fff96f15000 - 0x7fff96f1bffb com.apple.IOSurface (159.12 - 159.12) <E3D6FCED-F938-30A3-AD08-0998B674A492> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface 0x7fff96f6e000 - 0x7fff970cefef com.apple.ImageIO.framework (3.3.0 - 1599.13.1) <B48585FF-3B2D-32F6-85A6-07ECDDB2A6E9> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x7fff970cf000 - 0x7fff970d3fff libGIF.dylib (1599.13.1) <79C31DCF-3D95-32DE-9869-C1FA91F7C572> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib 0x7fff970d4000 - 0x7fff971c4ff7 libJP2.dylib (1599.13.1) <5E34964D-36BC-3DDD-936B-D859B39117BB> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib 0x7fff971c5000 - 0x7fff971e8ffb libJPEG.dylib (1599.13.1) <863E6D9C-E45A-33F7-8C52-2D2B81FCAE63> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib 0x7fff971e9000 - 0x7fff97210ff7 libPng.dylib (1599.13.1) <06282D7B-70EC-34A5-9240-A80FD18DC2D0> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib 0x7fff97211000 - 0x7fff97213ff3 libRadiance.dylib (1599.13.1) <823DDB0C-6BD0-3073-ABE4-313FDA38E3B4> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib 0x7fff97214000 - 0x7fff97262fff libTIFF.dylib (1599.13.1) <B48CCFEF-BD6E-37EA-8F1C-CC2CF6775A0E> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib 0x7fff97fcb000 - 0x7fff97fe4ff7 com.apple.Kerberos (3.0 - 1) <B9D242EB-E325-3A21-9812-C77CBBFB0D51> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos 0x7fff987c4000 - 0x7fff9881ffff com.apple.Metal (87.18 - 87.18) <E3618B54-C728-34CA-9E8A-9BD33A295D31> /System/Library/Frameworks/Metal.framework/Versions/A/Metal 0x7fff99108000 - 0x7fff99110fff com.apple.NetFS (6.0 - 4.0) <14A24D00-5673-330A-959D-87F72040DEFF> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS 0x7fff992f0000 - 0x7fff9933eff3 com.apple.opencl (2.8.6 - 2.8.6) <E7958F3E-F56C-35EC-87CD-6ADFC25D4512> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL 0x7fff9933f000 - 0x7fff99358ffb com.apple.CFOpenDirectory (10.12 - 194) <A64E9A01-3F6E-36EA-9C10-88C564A68C9D> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory 0x7fff99359000 - 0x7fff99364ff7 com.apple.OpenDirectory (10.12 - 194) <4298FFD0-B1A7-3064-AF5B-708B3FA38671> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory 0x7fff99365000 - 0x7fff99367fff libCVMSPluginSupport.dylib (14.0.16) <25655EB3-7BF6-36EC-BD17-47F4DF499D7F> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib 0x7fff99368000 - 0x7fff9936bff7 libCoreFSCache.dylib (156.3) <687C4CC3-6537-344B-8BE1-5234C8CB2864> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreFSCache.dylib 0x7fff9936c000 - 0x7fff99370fff libCoreVMClient.dylib (156.3) <E7AEFCBE-B6BF-3C7C-9A4E-E78CB04DB794> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib 0x7fff99371000 - 0x7fff9937aff7 libGFXShared.dylib (14.0.16) <679D8495-1C5F-3932-A452-050A21E0EEBB> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib 0x7fff9937b000 - 0x7fff99386fff libGL.dylib (14.0.16) <0801F3B9-A525-32BB-9BC0-478947CE21D9> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib 0x7fff99387000 - 0x7fff993c3ff7 libGLImage.dylib (14.0.16) <FE39C57B-056C-3CBF-B653-A8F2005631C1> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib 0x7fff9953b000 - 0x7fff9957cff7 libGLU.dylib (14.0.16) <B285EAD6-B3AA-3753-BB85-75864BD6E76C> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib 0x7fff99ee4000 - 0x7fff99ef2fff com.apple.opengl (14.0.16 - 14.0.16) <8D4CC067-4A70-34AE-945D-29407D780452> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 0x7fff9aa44000 - 0x7fff9ac44fff com.apple.QuartzCore (1.11 - 453.41.2) <564FBF07-0072-3587-91BE-7B0EFD6FBC1D> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore 0x7fff9b1af000 - 0x7fff9b4b1fff com.apple.security (7.0 - 57740.60.30) <2DD7275B-40E5-3F8C-8258-8C73DD3EE438> /System/Library/Frameworks/Security.framework/Versions/A/Security 0x7fff9b4b2000 - 0x7fff9b527fff com.apple.securityfoundation (6.0 - 55132.50.7) <2AF6A217-45D3-30C2-86B6-F35AF827E698> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation 0x7fff9b552000 - 0x7fff9b555ff3 com.apple.xpc.ServiceManagement (1.0 - 1) <F2AACDEF-7DCC-35B9-A6B6-119FF8D83DBB> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement 0x7fff9b8dc000 - 0x7fff9b94bff7 com.apple.SystemConfiguration (1.14 - 1.14) <98E76341-BB2F-3DF4-9DD4-F4AC7648EF0F> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration 0x7fff9e1ce000 - 0x7fff9e1f0ffb com.apple.framework.Apple80211 (12.0 - 1200.47.1) <F362FADE-B6F5-32B5-84E8-C3CE7FE5F851> /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Apple80211 0x7fff9e1f1000 - 0x7fff9e200feb com.apple.AppleFSCompression (88.50.3 - 1.0) <478E8BFF-8BA2-375E-BE02-BA27F115C15A> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression 0x7fff9e2f4000 - 0x7fff9e37f97f com.apple.AppleJPEG (1.0 - 1) <B9E9570D-04A4-34E4-B756-D200043B25B8> /System/Library/PrivateFrameworks/AppleJPEG.framework/Versions/A/AppleJPEG 0x7fff9e7b2000 - 0x7fff9e830ff7 com.apple.backup.framework (1.8.6 - 1.8.6) <2D75451A-8818-3D72-8480-489DF77D708B> /System/Library/PrivateFrameworks/Backup.framework/Versions/A/Backup 0x7fff9f4bb000 - 0x7fff9f4e2ff3 com.apple.ChunkingLibrary (173 - 173) <FC2165F9-FC93-39C0-8323-C2F43A5E00A3> /System/Library/PrivateFrameworks/ChunkingLibrary.framework/Versions/A/ChunkingLibrary 0x7fff9fe07000 - 0x7fff9fe10ffb com.apple.CommonAuth (4.0 - 2.0) <A71AD8F9-5CC8-3072-8A0B-F5427D3E8163> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth 0x7fffa0559000 - 0x7fffa0569fff com.apple.CoreEmoji (1.0 - 40.3.3) <E9A28301-2D79-3A97-A046-028258A6ABE5> /System/Library/PrivateFrameworks/CoreEmoji.framework/Versions/A/CoreEmoji 0x7fffa08a4000 - 0x7fffa08d4ff3 com.apple.CoreServicesInternal (276.2 - 276.2) <05EB7D45-DD4C-3A0F-AC63-A0C2A68E6481> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal 0x7fffa0b65000 - 0x7fffa0bf4ff7 com.apple.CoreSymbolication (62046) <2D4C3324-B647-3696-B92E-AAB1053EEB54> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication 0x7fffa0bf5000 - 0x7fffa0d34fe7 com.apple.coreui (2.1 - 431.3) <8D0FA478-9B6C-3D6D-8ADF-8677BA0BF134> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI 0x7fffa0d35000 - 0x7fffa0e05ff3 com.apple.CoreUtils (5.1 - 510.31) <B6636BBF-D37E-360E-A3EE-61BDC1736EEA> /System/Library/PrivateFrameworks/CoreUtils.framework/Versions/A/CoreUtils 0x7fffa0e55000 - 0x7fffa0ebaff3 com.apple.framework.CoreWiFi (12.0 - 1200.31) <1B3FE242-8AEB-38BD-84A4-65DBC476FEEA> /System/Library/PrivateFrameworks/CoreWiFi.framework/Versions/A/CoreWiFi 0x7fffa0ebb000 - 0x7fffa0ec9ff7 com.apple.CrashReporterSupport (10.12 - 827) <802A9B81-E349-348B-90AB-10E40B654250> /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport 0x7fffa0f3b000 - 0x7fffa0f45ffb com.apple.framework.DFRFoundation (1.0 - 104.25) <7CFF896C-EF22-3941-BB3D-F3615CE4C908> /System/Library/PrivateFrameworks/DFRFoundation.framework/Versions/A/DFRFoundation 0x7fffa0f46000 - 0x7fffa0f4aff3 com.apple.DSExternalDisplay (3.1 - 380) <4B5E3FF0-E8C3-38CC-BF72-418C928956AB> /System/Library/PrivateFrameworks/DSExternalDisplay.framework/Versions/A/DSExternalDisplay 0x7fffa0f80000 - 0x7fffa0ff5ffb com.apple.datadetectorscore (7.0 - 539.1) <D84B64BA-CD56-368E-A31A-AC47C3780D0B> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore 0x7fffa1031000 - 0x7fffa1070fff com.apple.DebugSymbols (137 - 137) <58A70B66-2628-3CFE-B103-2200D95FC5F7> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols 0x7fffa1071000 - 0x7fffa1182fff com.apple.desktopservices (1.11.6 - 1.11.6) <225B3746-8626-34CD-8FA9-48A7C04ACCCF> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv 0x7fffa146a000 - 0x7fffa189bff7 com.apple.vision.FaceCore (3.3.2 - 3.3.2) <9391D5A3-738C-3136-9D07-518CB43DBADA> /System/Library/PrivateFrameworks/FaceCore.framework/Versions/A/FaceCore 0x7fffa2bf2000 - 0x7fffa2bf2fff libmetal_timestamp.dylib (600.0.49.9) <E5EED927-1671-3390-BCBB-D76201D63C73> /System/Library/PrivateFrameworks/GPUCompiler.framework/libmetal_timestamp.dylib 0x7fffa2ec3000 - 0x7fffa2edffff com.apple.GenerationalStorage (2.0 - 267.2) <22381303-B9A8-32D8-BDBF-871F0CDD81A5> /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/GenerationalStorage 0x7fffa35f0000 - 0x7fffa3666ff3 com.apple.Heimdal (4.0 - 2.0) <9E554667-2A6D-3A86-883A-50C8AF98D0C0> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal 0x7fffa3c81000 - 0x7fffa3c88ffb com.apple.IOAccelerator (311.16.4 - 311.16.4) <F41EB563-1439-3745-BE98-4A4B6F45A7DF> /System/Library/PrivateFrameworks/IOAccelerator.framework/Versions/A/IOAccelerator 0x7fffa3c8a000 - 0x7fffa3c9eff7 com.apple.IOPresentment (1.0 - 29.10) <30DF04EE-10E2-353F-845F-A97B87DF3207> /System/Library/PrivateFrameworks/IOPresentment.framework/Versions/A/IOPresentment 0x7fffa3c9f000 - 0x7fffa3cc1fff com.apple.IconServices (74.4 - 74.4) <218DDD05-35F4-3833-B98D-471ED0EBC031> /System/Library/PrivateFrameworks/IconServices.framework/Versions/A/IconServices 0x7fffa3da8000 - 0x7fffa3f5ffff com.apple.LanguageModeling (1.0 - 123.2.5) <A8CA965F-0399-310D-91C3-B93DDDE9A442> /System/Library/PrivateFrameworks/LanguageModeling.framework/Versions/A/LanguageModeling 0x7fffa4880000 - 0x7fffa48f9ff7 com.apple.MetalPerformanceShaders.MetalPerformanceShaders (1.0 - 1) <C323FC94-FFA5-3EE6-B2AC-7E61EA92F304> /System/Library/PrivateFrameworks/MetalPerformanceShaders.framework/Versions/A/MetalPerformanceShaders 0x7fffa4a96000 - 0x7fffa4abeff7 com.apple.MultitouchSupport.framework (368.16 - 368.16) <F6EFB289-F4B1-36E7-88D4-D1C7B1630A23> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport 0x7fffa4b70000 - 0x7fffa4b7bfff com.apple.NetAuth (6.2 - 6.2) <E1D6BFF0-7F37-3866-9925-5DF40EB3A1F4> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth 0x7fffa5454000 - 0x7fffa5495ff3 com.apple.PerformanceAnalysis (1.148.3 - 148.3) <DE16079A-5267-372A-9435-E993EB41252A> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis 0x7fffa5b7d000 - 0x7fffa5b97fff com.apple.ProtocolBuffer (1 - 249.1) <A1F1B0F3-078F-378F-A9A9-0DEEA70E816A> /System/Library/PrivateFrameworks/ProtocolBuffer.framework/Versions/A/ProtocolBuffer 0x7fffa5bb0000 - 0x7fffa5bd3ff3 com.apple.RemoteViewServices (2.0 - 124) <6B967FDA-6591-302C-BA0A-76C4856E584E> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices 0x7fffa692f000 - 0x7fffa69bcfff com.apple.Sharing (696.2.67.1 - 696.2.67.1) <267A3C7C-BB70-3E92-B773-A3F9EDD12E84> /System/Library/PrivateFrameworks/Sharing.framework/Versions/A/Sharing 0x7fffa69dd000 - 0x7fffa6c43ff3 com.apple.SkyLight (1.600.0 - 170.3.11.11) <0F7F9F9B-90E2-3FE4-9A39-DE7EC10DAF79> /System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/SkyLight 0x7fffa6e22000 - 0x7fffa6e2eff7 com.apple.SpeechRecognitionCore (3.3.2 - 3.3.2) <684BD1EA-8268-331C-A5A9-080EB375C658> /System/Library/PrivateFrameworks/SpeechRecognitionCore.framework/Versions/A/SpeechRecognitionCore 0x7fffa751a000 - 0x7fffa758efdf com.apple.Symbolication (62048.1) <1A30ED19-7532-3F46-9DD3-9879A973D0CF> /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication 0x7fffa79cd000 - 0x7fffa79d3ff7 com.apple.TCC (1.0 - 1) <911B534B-4AC7-34E4-935E-E42ECD008CBC> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC 0x7fffa7a5f000 - 0x7fffa7b25ff7 com.apple.TextureIO (2.8 - 2.8) <3D61E533-4156-3B21-B7ED-CB823E680DFC> /System/Library/PrivateFrameworks/TextureIO.framework/Versions/A/TextureIO 0x7fffa7b9b000 - 0x7fffa7d2cff3 com.apple.UIFoundation (1.0 - 490.8) <0342C3E6-AB89-3F0D-A9CE-5F2CD3587B75> /System/Library/PrivateFrameworks/UIFoundation.framework/Versions/A/UIFoundation 0x7fffa8ddd000 - 0x7fffa8ddfffb com.apple.loginsupport (1.0 - 1) <F3140B97-12C3-35A7-9D3D-43DA2D13C113> /System/Library/PrivateFrameworks/login.framework/Versions/A/Frameworks/loginsupport.framework/Versions/A/loginsupport 0x7fffa8e34000 - 0x7fffa8e4fff7 libCRFSuite.dylib (34) <F78B7F5F-0B4F-35C6-AA2F-84EE9CB22137> /usr/lib/libCRFSuite.dylib 0x7fffa8e50000 - 0x7fffa8e5bfff libChineseTokenizer.dylib (21) <0886E908-A825-36AF-B94B-2361FD8BC2A1> /usr/lib/libChineseTokenizer.dylib 0x7fffa8eed000 - 0x7fffa8eeeff3 libDiagnosticMessagesClient.dylib (102) <84A04D24-0E60-3810-A8C0-90A65E2DF61A> /usr/lib/libDiagnosticMessagesClient.dylib 0x7fffa8eef000 - 0x7fffa9102fff libFosl_dynamic.dylib (16.39) <E22A4243-D148-3C74-BA15-2D906A3D1F9E> /usr/lib/libFosl_dynamic.dylib 0x7fffa9126000 - 0x7fffa9126fff libOpenScriptingUtil.dylib (172.1) <0F1BA407-97D1-36F6-882D-A355EAAD5E00> /usr/lib/libOpenScriptingUtil.dylib 0x7fffa9127000 - 0x7fffa912bffb libScreenReader.dylib (477.40.7) <F7305560-6CF0-3000-8301-72E04BEAA693> /usr/lib/libScreenReader.dylib 0x7fffa912c000 - 0x7fffa912dffb libSystem.B.dylib (1238.60.2) <58358A17-4318-3AD9-B18E-CC36502B9127> /usr/lib/libSystem.B.dylib 0x7fffa9199000 - 0x7fffa91c4ff3 libarchive.2.dylib (41.70.2) <907D1FB1-9A65-33F5-AFC8-0B6E5AE9D83A> /usr/lib/libarchive.2.dylib 0x7fffa91c5000 - 0x7fffa9241fc7 libate.dylib (1.12.13) <D0767875-D02E-3377-84D8-5F174C27BEA9> /usr/lib/libate.dylib 0x7fffa9245000 - 0x7fffa9245ff3 libauto.dylib (187) <34388D0B-C539-3C1B-9408-2BC152162E43> /usr/lib/libauto.dylib 0x7fffa9246000 - 0x7fffa9256ff3 libbsm.0.dylib (34) <20084796-B04D-3B35-A003-EA11459557A9> /usr/lib/libbsm.0.dylib 0x7fffa9257000 - 0x7fffa9265ff7 libbz2.1.0.dylib (38) <ADFA329A-DCE7-356D-8F09-A3168DFC6610> /usr/lib/libbz2.1.0.dylib 0x7fffa9266000 - 0x7fffa92bcff7 libc++.1.dylib (307.5) <0B43BB5D-E6EB-3464-8DE9-B41AC8ED9D1C> /usr/lib/libc++.1.dylib 0x7fffa92bd000 - 0x7fffa92e6ff7 libc++abi.dylib (307.4) <BC271AD3-831B-362A-9DA7-E8C51F285FE4> /usr/lib/libc++abi.dylib 0x7fffa92e7000 - 0x7fffa92f7ffb libcmph.dylib (6) <2B5D405E-2D0B-3320-ABD6-622934C86ABE> /usr/lib/libcmph.dylib 0x7fffa92f8000 - 0x7fffa930efcf libcompression.dylib (39) <F2726F95-F54E-3B21-BCB5-F7151DEFDC2F> /usr/lib/libcompression.dylib 0x7fffa930f000 - 0x7fffa930fff7 libcoretls.dylib (121.50.4) <64B1001E-10F6-3542-A3B2-C4B49F51817F> /usr/lib/libcoretls.dylib 0x7fffa9310000 - 0x7fffa9311ff3 libcoretls_cfhelpers.dylib (121.50.4) <1A10303E-5EB0-3C7C-9165-021FCDFD934D> /usr/lib/libcoretls_cfhelpers.dylib 0x7fffa964d000 - 0x7fffa96a0ff7 libcups.2.dylib (450.4) <2DA65D4A-1428-3F74-869A-E16246DE88C7> /usr/lib/libcups.2.dylib 0x7fffa971d000 - 0x7fffa971dfff libenergytrace.dylib (15) <A1B040A2-7977-3097-9ADF-34FF181EB970> /usr/lib/libenergytrace.dylib 0x7fffa972d000 - 0x7fffa9732ff7 libheimdal-asn1.dylib (498.50.12) <1AC5AB99-2E62-3B9C-ADE4-AE65CFCDA471> /usr/lib/libheimdal-asn1.dylib 0x7fffa9733000 - 0x7fffa9825ff7 libiconv.2.dylib (50) <42125B35-81D7-3FC4-9475-A26DBE10884D> /usr/lib/libiconv.2.dylib 0x7fffa9826000 - 0x7fffa9a4bffb libicucore.A.dylib (57168.0.1) <99D53A36-19F6-34F0-86AB-D8BD6C9BD3AD> /usr/lib/libicucore.A.dylib 0x7fffa9a51000 - 0x7fffa9a52fff liblangid.dylib (126) <2085E7A7-9A34-3735-87F4-F174EF8EABF0> /usr/lib/liblangid.dylib 0x7fffa9a53000 - 0x7fffa9a6cffb liblzma.5.dylib (10) <44BD0279-99DD-36B5-8A6E-C11432E2098D> /usr/lib/liblzma.5.dylib 0x7fffa9a6d000 - 0x7fffa9a83ff7 libmarisa.dylib (5) <9030D214-5D0F-30CB-AC03-902C63909362> /usr/lib/libmarisa.dylib 0x7fffa9a84000 - 0x7fffa9d2cff7 libmecabra.dylib (744.8) <D429FCC9-42A4-38B3-8784-44024BC859EF> /usr/lib/libmecabra.dylib 0x7fffa9d2d000 - 0x7fffa9d5effb libncurses.5.4.dylib (51.30.1) <B03B1BD2-7080-3856-BB02-7E8238320C3B> /usr/lib/libncurses.5.4.dylib 0x7fffa9d5f000 - 0x7fffa9dd9ff3 libnetwork.dylib (856.60.1) <191E99F5-4723-3180-8013-02AF2F9AE4B8> /usr/lib/libnetwork.dylib 0x7fffa9dda000 - 0x7fffaa1ac047 libobjc.A.dylib (709.1) <70614861-0340-32E2-85ED-FE65759CDFFA> /usr/lib/libobjc.A.dylib 0x7fffaa1af000 - 0x7fffaa1b3fff libpam.2.dylib (21.30.1) <71EB0D88-DE84-3C8D-A2C5-58AA282BC5BC> /usr/lib/libpam.2.dylib 0x7fffaa1b4000 - 0x7fffaa1e5fff libpcap.A.dylib (67.60.2) <B2D36AD8-D5C8-3875-AC81-4787A15E44C2> /usr/lib/libpcap.A.dylib 0x7fffaa202000 - 0x7fffaa21effb libresolv.9.dylib (64) <A244AE4C-00B0-396C-98FF-97FE4DB3DA30> /usr/lib/libresolv.9.dylib 0x7fffaa26e000 - 0x7fffaa3bcff7 libsqlite3.dylib (254.8) <1ECF7DF7-7A07-3B4B-A63B-F4EFF6BC7ACF> /usr/lib/libsqlite3.dylib 0x7fffaa505000 - 0x7fffaa512ff7 libxar.1.dylib (417.1) <78B14DC5-5256-3820-8259-117C5046BB9F> /usr/lib/libxar.1.dylib 0x7fffaa513000 - 0x7fffaa602ff3 libxml2.2.dylib (30.24) <D84C6B99-6D4C-3651-8086-387D631CBA37> /usr/lib/libxml2.2.dylib 0x7fffaa603000 - 0x7fffaa62cfff libxslt.1.dylib (15.9.3) <F57ED43F-7912-3C99-8500-AB0EEE9FA178> /usr/lib/libxslt.1.dylib 0x7fffaa62d000 - 0x7fffaa63eff3 libz.1.dylib (67) <46E3FFA2-4328-327A-8D34-A03E20BFFB8E> /usr/lib/libz.1.dylib 0x7fffaa64d000 - 0x7fffaa651ff7 libcache.dylib (79) <093A4DAB-8385-3D47-A350-E20CB7CCF7BF> /usr/lib/system/libcache.dylib 0x7fffaa652000 - 0x7fffaa65cfff libcommonCrypto.dylib (60092.50.5) <4C8A7FE1-C190-3015-A744-66F8220EAF6A> /usr/lib/system/libcommonCrypto.dylib 0x7fffaa65d000 - 0x7fffaa664fff libcompiler_rt.dylib (62) <55D47421-772A-32AB-B529-1A46C2F43B4D> /usr/lib/system/libcompiler_rt.dylib 0x7fffaa665000 - 0x7fffaa66dfff libcopyfile.dylib (138) <819BEA3C-DF11-3E3D-A1A1-5A51C5BF1961> /usr/lib/system/libcopyfile.dylib 0x7fffaa66e000 - 0x7fffaa6f1fdb libcorecrypto.dylib (442.50.22) <E36CE660-855A-3166-8B9C-645C514B2C52> /usr/lib/system/libcorecrypto.dylib 0x7fffaa6f2000 - 0x7fffaa723fff libdispatch.dylib (703.50.38) <54B02414-5908-3EF0-B4D2-230B7FEB1CF7> /usr/lib/system/libdispatch.dylib 0x7fffaa724000 - 0x7fffaa729ffb libdyld.dylib (434) <4A0E66C1-4596-38E6-898E-BD2660478D3D> /usr/lib/system/libdyld.dylib 0x7fffaa72a000 - 0x7fffaa72affb libkeymgr.dylib (28) <7AA011A9-DC21-3488-BF73-3B5B14D1FDD6> /usr/lib/system/libkeymgr.dylib 0x7fffaa72b000 - 0x7fffaa737fff libkxld.dylib (3789.73.50) <E2CCB6DE-F92B-33CE-81A8-DDC42E62B62D> /usr/lib/system/libkxld.dylib 0x7fffaa738000 - 0x7fffaa738fff liblaunch.dylib (972.70.5) <1F770D9B-3892-3BBB-9471-68DDDDB0F69A> /usr/lib/system/liblaunch.dylib 0x7fffaa739000 - 0x7fffaa73eff3 libmacho.dylib (898) <17D5D855-F6C3-3B04-B680-E9BF02EF8AED> /usr/lib/system/libmacho.dylib 0x7fffaa73f000 - 0x7fffaa741ff3 libquarantine.dylib (85.50.1) <12448CC2-378E-35F3-BE33-9DC395A5B970> /usr/lib/system/libquarantine.dylib 0x7fffaa742000 - 0x7fffaa743ffb libremovefile.dylib (45) <38D4CB9C-10CD-30D3-8B7B-A515EC75FE85> /usr/lib/system/libremovefile.dylib 0x7fffaa744000 - 0x7fffaa75cff7 libsystem_asl.dylib (349.50.5) <096E4228-3B7C-30A6-8B13-EC909A64499A> /usr/lib/system/libsystem_asl.dylib 0x7fffaa75d000 - 0x7fffaa75dff7 libsystem_blocks.dylib (67) <10DC5404-73AB-35B3-A277-A8AFECB476EB> /usr/lib/system/libsystem_blocks.dylib 0x7fffaa75e000 - 0x7fffaa7ebfef libsystem_c.dylib (1158.50.2) <E5AE5244-7D0C-36AC-8BB6-C7AE7EA52A4B> /usr/lib/system/libsystem_c.dylib 0x7fffaa7ec000 - 0x7fffaa7efffb libsystem_configuration.dylib (888.60.3) <094DBBF4-276A-3A11-8AF3-72743CC338E6> /usr/lib/system/libsystem_configuration.dylib 0x7fffaa7f0000 - 0x7fffaa7f3fff libsystem_coreservices.dylib (41.4) <7D26DE79-B424-3450-85E1-F7FAB32714AB> /usr/lib/system/libsystem_coreservices.dylib 0x7fffaa7f4000 - 0x7fffaa80cfff libsystem_coretls.dylib (121.50.4) <EC6FCF07-DCFB-3A03-9CC9-6DD3709974C6> /usr/lib/system/libsystem_coretls.dylib 0x7fffaa80d000 - 0x7fffaa813fff libsystem_dnssd.dylib (765.50.11) <B87F96B8-2694-3DB3-9923-1B4E2245C8BF> /usr/lib/system/libsystem_dnssd.dylib 0x7fffaa814000 - 0x7fffaa83dff7 libsystem_info.dylib (503.50.4) <611DB84C-BF70-3F92-8702-B9F28A900920> /usr/lib/system/libsystem_info.dylib 0x7fffaa83e000 - 0x7fffaa860ff7 libsystem_kernel.dylib (3789.73.50) <932ACBB6-9962-3839-AEE3-D8AA6BF1DD02> /usr/lib/system/libsystem_kernel.dylib 0x7fffaa861000 - 0x7fffaa8a8fe7 libsystem_m.dylib (3121.6) <86D499B5-BBDC-3D3B-8A4E-97AE8E6672A4> /usr/lib/system/libsystem_m.dylib 0x7fffaa8a9000 - 0x7fffaa8c7ff7 libsystem_malloc.dylib (116.50.9) <82647590-DAEF-3499-8BF3-F1E3048861FE> /usr/lib/system/libsystem_malloc.dylib 0x7fffaa8c8000 - 0x7fffaa921ffb libsystem_network.dylib (856.60.1) <369D0221-56CA-3C3E-9EDE-94B41CAE77B7> /usr/lib/system/libsystem_network.dylib 0x7fffaa922000 - 0x7fffaa92bff3 libsystem_networkextension.dylib (563.60.2) <B021F2B3-8A75-3633-ABB0-FC012B8E9B0C> /usr/lib/system/libsystem_networkextension.dylib 0x7fffaa92c000 - 0x7fffaa935ff3 libsystem_notify.dylib (165.20.1) <B8160190-A069-3B3A-BDF6-2AA408221FAE> /usr/lib/system/libsystem_notify.dylib 0x7fffaa936000 - 0x7fffaa93efe7 libsystem_platform.dylib (126.50.8) <897462FD-B318-321B-A554-E61982630F7E> /usr/lib/system/libsystem_platform.dylib 0x7fffaa93f000 - 0x7fffaa949ff7 libsystem_pthread.dylib (218.60.3) <B8FB5E20-3295-39E2-B5EB-B464D1D4B104> /usr/lib/system/libsystem_pthread.dylib 0x7fffaa94a000 - 0x7fffaa94dff7 libsystem_sandbox.dylib (592.70.2) <19320A42-2E3B-361B-BBDA-2F5F2E87B100> /usr/lib/system/libsystem_sandbox.dylib 0x7fffaa94e000 - 0x7fffaa94fff3 libsystem_secinit.dylib (24.50.4) <F78B847B-3565-3E4B-98A6-F7AD40392E2D> /usr/lib/system/libsystem_secinit.dylib 0x7fffaa950000 - 0x7fffaa957ffb libsystem_symptoms.dylib (532.50.48) <1C822669-BF39-3639-A00B-B9170A63F342> /usr/lib/system/libsystem_symptoms.dylib 0x7fffaa958000 - 0x7fffaa96bff7 libsystem_trace.dylib (518.70.1) <AC63A7FE-50D9-3A30-96E6-F6B7FF16E465> /usr/lib/system/libsystem_trace.dylib 0x7fffaa96c000 - 0x7fffaa971ffb libunwind.dylib (35.3) <3D50D8A8-C460-334D-A519-2DA841102C6B> /usr/lib/system/libunwind.dylib 0x7fffaa972000 - 0x7fffaa99bff7 libxpc.dylib (972.70.5) <255AA6A1-26AA-33F6-BC11-3DCE12A0BC0F> /usr/lib/system/libxpc.dylib External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by all processes on this machine: task_for_pid: 400705 thread_create: 0 thread_set_state: 1176 VM Region Summary: ReadOnly portion of Libraries: Total=252.8M resident=0K(0%) swapped_out_or_unallocated=252.8M(100%) Writable regions: Total=89.6M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=89.6M(100%) VIRTUAL REGION REGION TYPE SIZE COUNT (non-coalesced) =========== ======= ======= Accelerate framework 128K 2 Activity Tracing 256K 2 CG image 264K 3 CoreUI image file 124K 2 Dispatch continuations 8192K 2 Image IO 76K 4 Kernel Alloc Once 8K 2 MALLOC 51.5M 32 MALLOC guard page 48K 9 Memory Tag 242 12K 2 STACK GUARD 54.5M 7 Stack 12.1M 8 VM_ALLOCATE 292K 7 __DATA 25.1M 215 __IMAGE 528K 2 __LINKEDIT 116.0M 16 __TEXT 136.8M 217 __UNICODE 556K 2 mapped file 57.8M 12 shared memory 16.3M 13 =========== ======= ======= TOTAL 480.3M 539 Model: MacBookPro12,1, BootROM 186.0.0.0.0, 2 processors, Intel Core i5, 2,7 GHz, 8 GB, SMC 2.28f7 Graphics: Intel Iris Graphics 6100, Intel Iris Graphics 6100, Built-In Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1867 MHz, 0x80CE, 0x4B3445364533303445452D45474346000000 Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1867 MHz, 0x80CE, 0x4B3445364533303445452D45474346000000 AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x133), Broadcom BCM43xx 1.0 (7.21.171.134.1a2) Bluetooth: Version 5.0.5f7, 3 services, 17 devices, 1 incoming serial ports Network Service: Wi-Fi, AirPort, en0 Serial ATA Device: APPLE SSD SM0256G, 251 GB USB Device: USB 3.0 Bus USB Device: Bluetooth USB Host Controller Thunderbolt Bus: MacBook Pro, Apple Inc., 27.1 ^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: Tabs 2019-08-31 20:45 Tabs Juri Linkov 2019-09-01 8:12 ` Tabs martin rudalics 2019-09-01 8:59 ` Tabs (on macos) Jean-Christophe Helary @ 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) 6 siblings, 1 reply; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-09-01 9:28 ` Tabs Alan Mackenzie @ 2019-09-01 19:18 ` Juri Linkov 0 siblings, 0 replies; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-08-31 20:45 Tabs Juri Linkov ` (2 preceding siblings ...) 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) 6 siblings, 1 reply; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-09-02 21:06 ` Tabs Stefan Monnier @ 2019-09-03 19:56 ` Juri Linkov 0 siblings, 0 replies; 219+ 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] 219+ 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; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-09-03 2:30 ` Tabs Eli Zaretskii @ 2019-09-03 19:58 ` Juri Linkov 0 siblings, 0 replies; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-09-05 22:24 ` Tabs Ergus @ 2019-09-07 20:14 ` Juri Linkov 0 siblings, 0 replies; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-09-02 19:39 ` Tabs Juri Linkov @ 2019-09-02 21:03 ` Stefan Monnier 0 siblings, 0 replies; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-08-31 20:45 Tabs Juri Linkov ` (3 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 6 siblings, 1 reply; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-09-03 12:22 ` Tabs Robert Pluim @ 2019-09-03 20:21 ` Juri Linkov 0 siblings, 0 replies; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-08-31 20:45 Tabs Juri Linkov ` (4 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 6 siblings, 1 reply; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ messages in thread
* RE: Tabs 2019-09-17 20:37 ` Tabs Juri Linkov @ 2019-09-17 22:53 ` Drew Adams 0 siblings, 0 replies; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-09-28 19:52 ` Tabs Juri Linkov @ 2019-10-20 22:38 ` Juri Linkov 0 siblings, 0 replies; 219+ 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] 219+ 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; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-08-31 20:45 Tabs Juri Linkov ` (5 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 6 siblings, 1 reply; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-10-10 11:53 ` Tabs Eli Zaretskii @ 2019-10-10 14:58 ` martin rudalics 0 siblings, 0 replies; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-10-11 8:18 ` Tabs martin rudalics @ 2019-10-11 9:16 ` Eli Zaretskii 0 siblings, 0 replies; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-10-11 7:08 ` Tabs Eli Zaretskii @ 2019-10-13 20:57 ` Juri Linkov 0 siblings, 0 replies; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-10-14 18:29 ` Tabs Eli Zaretskii @ 2019-10-15 9:47 ` martin rudalics 0 siblings, 0 replies; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-10-15 17:45 ` Tabs Juri Linkov @ 2019-10-16 9:16 ` martin rudalics 0 siblings, 0 replies; 219+ 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] 219+ 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; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-10-14 19:00 ` Tabs Juri Linkov @ 2019-10-15 9:47 ` martin rudalics 0 siblings, 0 replies; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-10-13 21:33 ` Tabs Juri Linkov @ 2019-10-14 8:24 ` Eli Zaretskii 0 siblings, 0 replies; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-10-06 18:38 ` Tabs Michael Heerdegen @ 2019-10-06 19:03 ` Eli Zaretskii 0 siblings, 0 replies; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-11-13 22:10 ` Tabs Juri Linkov @ 2019-11-14 9:20 ` martin rudalics 0 siblings, 0 replies; 219+ 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] 219+ messages in thread
[parent not found: <<87a7bpysm8.fsf@mail.linkov.net>]
[parent not found: <<d0768d60-979b-8635-b2b5-474742827552@gmx.at>]
[parent not found: <<87o903dc2j.fsf@mail.linkov.net>]
[parent not found: <<CADwFkmmgvyMzc_RZwz-AD6=cpUGfxdx5VZAv2eau4T9dAkTKQg@mail.gmail.com>]
[parent not found: <<CADtN0WKCHd9fA-tCaGckHFQ59+6ns72NdGrvAdKHss0GLYFZ6g@mail.gmail.com>]
[parent not found: <<87tv9ubirx.fsf@mail.linkov.net>]
[parent not found: <<courier.000000005D6DF86C.00005323@protected.rcdrun.com>]
* RE: Tabs [not found] ` <<courier.000000005D6DF86C.00005323@protected.rcdrun.com> @ 2019-09-03 15:24 ` Drew Adams 0 siblings, 0 replies; 219+ 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] 219+ messages in thread
* Re: Tabs
@ 2019-09-03 9:20 Angelo Graziosi
0 siblings, 0 replies; 219+ 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] 219+ messages in thread
* Re: Tabs @ 2019-09-02 13:31 Angelo Graziosi 2019-09-02 19:46 ` Tabs Juri Linkov 0 siblings, 1 reply; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-10-15 21:38 ` Tabs Angelo Graziosi @ 2019-10-16 6:53 ` Eli Zaretskii 0 siblings, 0 replies; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ messages in thread
* Re: Tabs 2019-10-16 22:17 ` Tabs Juri Linkov @ 2019-10-17 7:17 ` Eli Zaretskii 0 siblings, 0 replies; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ 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; 219+ 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] 219+ messages in thread
* Tabs @ 2003-08-15 22:35 Paul 2003-08-15 23:23 ` Tabs Marcus Frings 0 siblings, 1 reply; 219+ 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] 219+ messages in thread
* Re: Tabs 2003-08-15 22:35 Tabs Paul @ 2003-08-15 23:23 ` Marcus Frings 0 siblings, 0 replies; 219+ 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] 219+ messages in thread
end of thread, other threads:[~2019-11-14 9:20 UTC | newest] Thread overview: 219+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 8:59 ` Tabs (on macos) Jean-Christophe Helary 2019-09-01 20:11 ` Juri Linkov 2019-09-16 13:41 ` Stefan Kangas 2019-09-16 20:33 ` Juri Linkov 2019-09-17 9:11 ` Stefan Kangas 2019-09-17 9:29 ` Stefan Kangas 2019-09-17 20:28 ` Juri Linkov 2019-09-17 22:38 ` Stefan Kangas 2019-09-20 18:26 ` Alan Third 2019-09-17 23:29 ` Stefan Kangas 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 [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 -- strict thread matches above, loose matches on Subject: below -- 2019-09-03 9:20 Tabs Angelo Graziosi 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 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.