Re: Tabs

[Stefan Kangas]

Juri Linkov <address@hidden> 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