Tabs

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

Tabs

Juri Linkov-2
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 (55K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Tabs

martin rudalics
 > 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

tabs.diff (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Tabs (on macos)

Jean-Christophe Helary-4
In reply to this post by Juri Linkov-2
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 <[hidden email]> 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>

Reply | Threaded
Open this post in threaded view
|

Re: Tabs

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

Reply | Threaded
Open this post in threaded view
|

Re: Tabs

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



Reply | Threaded
Open this post in threaded view
|

Re: Tabs

Eli Zaretskii
In reply to this post by martin rudalics
> From: martin rudalics <[hidden email]>
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Tabs

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

Reply | Threaded
Open this post in threaded view
|

Re: Tabs

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

Reply | Threaded
Open this post in threaded view
|

Re: Tabs

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

Reply | Threaded
Open this post in threaded view
|

Re: Tabs (on macos)

Juri Linkov-2
In reply to this post by Jean-Christophe Helary-4
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Tabs

Stefan Kangas
In reply to this post by Juri Linkov-2
Hi Juri,

Juri Linkov <[hidden email]> 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

tabs-screenshot.png (23K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Tabs

Eli Zaretskii
In reply to this post by Juri Linkov-2
> From: Juri Linkov <[hidden email]>
> Date: Sun, 01 Sep 2019 22:57:24 +0300
> Cc: [hidden email]
>
> > 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.

Reply | Threaded
Open this post in threaded view
|

Re: Tabs

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


Reply | Threaded
Open this post in threaded view
|

Re: Tabs

Elias Mårtenson
In reply to this post by Stefan Kangas
On Mon, 2 Sep 2019 at 08:41, Stefan Kangas <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Tabs

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

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

Reply | Threaded
Open this post in threaded view
|

Re: Tabs

Stefan Monnier
In reply to this post by Juri Linkov-2
> '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


Reply | Threaded
Open this post in threaded view
|

Re: Tabs

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

tabs-img.tar.gz (43K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Tabs

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

Reply | Threaded
Open this post in threaded view
|

Re: Tabs

Juri Linkov-2
In reply to this post by Elias Mårtenson
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Tabs

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

1234 ... 11