Re: Tabs

[Juri Linkov]

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