Re: Tabs

[Juri Linkov]

> 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.