* Tabs
@ 2019-08-31 20:45 Juri Linkov
2019-09-01 8:12 ` Tabs martin rudalics
` (6 more replies)
0 siblings, 7 replies; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ messages in thread
* Re: Tabs
2019-09-01 9:28 ` Tabs Alan Mackenzie
@ 2019-09-01 19:18 ` Juri Linkov
0 siblings, 0 replies; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ messages in thread
* Re: Tabs
@ 2019-09-02 13:31 Angelo Graziosi
2019-09-02 19:46 ` Tabs Juri Linkov
0 siblings, 1 reply; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ messages in thread
* Re: Tabs
2019-09-02 19:39 ` Tabs Juri Linkov
@ 2019-09-02 21:03 ` Stefan Monnier
0 siblings, 0 replies; 211+ 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] 211+ 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; 211+ 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] 211+ messages in thread
* Re: Tabs
2019-09-02 19:29 ` Tabs Juri Linkov
@ 2019-09-03 2:27 ` Eli Zaretskii
0 siblings, 0 replies; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ messages in thread
* Re: Tabs
@ 2019-09-03 9:20 Angelo Graziosi
0 siblings, 0 replies; 211+ 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] 211+ 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; 211+ 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] 211+ messages in thread
* RE: Tabs
[not found] ` <<courier.000000005D6DF86C.00005323@protected.rcdrun.com>
@ 2019-09-03 15:24 ` Drew Adams
0 siblings, 0 replies; 211+ 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] 211+ 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; 211+ 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] 211+ messages in thread
* Re: Tabs
2019-09-03 5:45 ` Tabs Yuri Khan
@ 2019-09-03 19:45 ` Juri Linkov
0 siblings, 0 replies; 211+ 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] 211+ 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; 211+ 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] 211+ messages in thread
* Re: Tabs
2019-09-02 21:06 ` Tabs Stefan Monnier
@ 2019-09-03 19:56 ` Juri Linkov
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: Tabs
2019-09-03 2:30 ` Tabs Eli Zaretskii
@ 2019-09-03 19:58 ` Juri Linkov
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: Tabs
2019-09-03 19:40 ` Tabs Juri Linkov
@ 2019-09-03 20:14 ` Jean Louis
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: Tabs
2019-09-03 12:22 ` Tabs Robert Pluim
@ 2019-09-03 20:21 ` Juri Linkov
0 siblings, 0 replies; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ messages in thread
* Re: Tabs
2019-09-05 22:24 ` Tabs Ergus
@ 2019-09-07 20:14 ` Juri Linkov
0 siblings, 0 replies; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ messages in thread
* Re: Tabs
2019-09-15 16:44 ` Tabs Stefan Kangas
@ 2019-09-15 21:17 ` Juri Linkov
0 siblings, 0 replies; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ messages in thread
* RE: Tabs
2019-09-17 20:37 ` Tabs Juri Linkov
@ 2019-09-17 22:53 ` Drew Adams
0 siblings, 0 replies; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ messages in thread
* Re: Tabs
2019-10-06 18:38 ` Tabs Michael Heerdegen
@ 2019-10-06 19:03 ` Eli Zaretskii
0 siblings, 0 replies; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ messages in thread
* Re: Tabs
2019-10-10 11:53 ` Tabs Eli Zaretskii
@ 2019-10-10 14:58 ` martin rudalics
0 siblings, 0 replies; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ messages in thread
* Re: Tabs
2019-10-11 8:18 ` Tabs martin rudalics
@ 2019-10-11 9:16 ` Eli Zaretskii
0 siblings, 0 replies; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ messages in thread
* Re: Tabs
2019-10-11 7:08 ` Tabs Eli Zaretskii
@ 2019-10-13 20:57 ` Juri Linkov
0 siblings, 0 replies; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ messages in thread
* Re: Tabs
2019-10-13 21:33 ` Tabs Juri Linkov
@ 2019-10-14 8:24 ` Eli Zaretskii
0 siblings, 0 replies; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ messages in thread
* Re: Tabs
2019-10-14 18:29 ` Tabs Eli Zaretskii
@ 2019-10-15 9:47 ` martin rudalics
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: Tabs
2019-10-14 19:00 ` Tabs Juri Linkov
@ 2019-10-15 9:47 ` martin rudalics
0 siblings, 0 replies; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ messages in thread
* Re: Tabs
2019-10-15 21:38 ` Tabs Angelo Graziosi
@ 2019-10-16 6:53 ` Eli Zaretskii
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
* Re: Tabs
2019-10-15 17:45 ` Tabs Juri Linkov
@ 2019-10-16 9:16 ` martin rudalics
0 siblings, 0 replies; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ messages in thread
* Re: Tabs
2019-10-16 22:17 ` Tabs Juri Linkov
@ 2019-10-17 7:17 ` Eli Zaretskii
0 siblings, 0 replies; 211+ 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] 211+ 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; 211+ 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] 211+ messages in thread
* Re: Tabs
2019-09-28 19:52 ` Tabs Juri Linkov
@ 2019-10-20 22:38 ` Juri Linkov
0 siblings, 0 replies; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ 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; 211+ 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] 211+ messages in thread
* Re: Tabs
2019-11-13 22:10 ` Tabs Juri Linkov
@ 2019-11-14 9:20 ` martin rudalics
0 siblings, 0 replies; 211+ 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] 211+ messages in thread
end of thread, other threads:[~2019-11-14 9:20 UTC | newest]
Thread overview: 211+ 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
-- strict thread matches above, loose matches on Subject: below --
2019-09-02 13:31 Tabs Angelo Graziosi
2019-09-02 19:46 ` Tabs Juri Linkov
2019-09-03 8:49 ` Tabs Angelo Graziosi
2019-09-03 19:48 ` Tabs Juri Linkov
2019-09-04 8:22 ` Tabs Angelo Graziosi
2019-09-04 19:05 ` Tabs Juri Linkov
2019-09-04 22:41 ` Tabs Angelo Graziosi
2019-09-05 21:40 ` Tabs Angelo Graziosi
2019-09-06 20:16 ` Tabs Angelo Graziosi
2019-09-07 20:28 ` Tabs Juri Linkov
2019-09-08 20:19 ` Tabs Juri Linkov
2019-09-16 7:56 ` Tabs Angelo Graziosi
2019-09-16 8:45 ` Tabs Angelo Graziosi
2019-09-16 20:43 ` Tabs Juri Linkov
2019-10-13 14:49 ` Tabs Angelo Graziosi
2019-10-13 15:07 ` Tabs Eli Zaretskii
2019-10-13 21:09 ` Tabs Angelo Graziosi
2019-10-14 8:23 ` Tabs Eli Zaretskii
2019-10-15 21:38 ` Tabs Angelo Graziosi
2019-10-16 6:53 ` Tabs Eli Zaretskii
2019-10-13 22:08 ` Tabs Juri Linkov
2019-10-14 6:37 ` Tabs Eli Zaretskii
2019-10-15 7:55 ` Tabs Eli Zaretskii
2019-10-15 19:44 ` Tabs Juri Linkov
2019-10-16 6:23 ` Tabs Eli Zaretskii
2019-10-16 22:17 ` Tabs Juri Linkov
2019-10-17 7:17 ` Tabs Eli Zaretskii
2019-10-13 22:01 ` Tabs Juri Linkov
2019-09-03 9:20 Tabs Angelo Graziosi
[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
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).