bug#38624: 27.0.50; [wish] tab navigation via keyboard should mimic buffer navigation

bug#38624: 27.0.50; [wish] tab navigation via keyboard should mimic buffer navigation

[Gregor Zattler]

Dear emacs developers, Juri,

this wish list bug is about the tab bar user interface, I'd like to
navigate tabs via keyboard, probably without showing the tab bar:

Navigating tabs with "C-X t o" is error prone since it provides no
feedback which tab is selected (different tabs may show identical window
configurations at a specific point of time).  Perhaps it should show the
name of the selected tab in the echo area?  Or the name of the
tab could be shown in the mode line?

I'd prefer to navigate tabs like buffers via names and completion.
This would be like switch-to-buffer, how about "C-X t t" as the default
key binding?  This would happen in the echo area, therefore be less
visual intrusive and keep the current window configuration visible
till I choose the next one, while tab-list blanks the whole frame till I
choose the next one from this list.

M-x tab-list creates a temporary tab, which looks like a buffer in a
window, but is not shown for instance as a buffer in ibuffer.  Other
than ibuffer or list-buffers which split the window and therefore
provide some visual context, tab-list destroys this context.

The names of the tabs are somehow centred vertically and horizontally,
which irritates me.

I would prefer tab-list to create a buffer which mimics list-buffers or
better ibuffer.  This could be bound to "C-X t C-t".  Then I would have
the choice to have a dedicated tab which shows this buffer or switch to
it in a tab.  Perhaps it should be possible or even default to bury this
tab list before switching to the next tab, in order to restore the
windows configuration in the tab current when calling tab-list.

Then for instance in ibuffer I can kill a line with C-K and yank it in
another buffer.  This is not possible with the tab-list.  It only marks
the tab on this line for deletion (which is ok) but does not copy it to
the kill ring.


Thanks for providing tabs in emacs, Gregor




In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.11)
 of 2019-12-15 built on len
Repository revision: 0ca32d1270bd5d494e365f3525fa65ac423f6658
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11902000
System Description: Debian GNU/Linux 9 (stretch)

Recent messages:
nil
Auto-saving...done
Auto-saving...done
next-line: End of buffer [10 times]
scroll-down-command: Beginning of buffer
previous-line: Beginning of buffer [13 times]

Auto-saving...done
C-x t TAB is undefined

Quit [2 times]
Configured using:
 'configure -C --prefix=/usr/local/stow/emacs-snapshot
 --with-file-notification=inotify --without-toolkit-scroll-bars
 --with-x-toolkit=gtk3 'CFLAGS=-g -O2
 -fdebug-prefix-map=/home/grfz/src/emacs=. -fstack-protector-strong
 -Wformat -Werror=format-security -Wall -fno-pie' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2 ' 'LDFLAGS=-Wl,-z,relro -no-pie''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF XFT ZLIB
GTK3 X11 XDBE XIM MODULES THREADS PDUMPER GMP

Important settings:
  value of $LC_ALL:
  value of $LC_COLLATE: de_DE.utf8
  value of $LC_CTYPE: de_DE.utf8
  value of $LC_MESSAGES: POSIX
  value of $LC_MONETARY: de_DE.utf8
  value of $LC_NUMERIC: de_DE.utf8
  value of $LC_TIME: de_DE.utf8
  value of $LANG: de_DE.utf8
  locale-coding-system: utf-8-unix

bug#38624: 27.0.50; [wish] tab navigation via keyboard should mimic buffer navigation

[Juri Linkov]

> this wish list bug is about the tab bar user interface, I'd like to
> navigate tabs via keyboard, probably without showing the tab bar:

Thanks for the feedback.  Tabs were designed to be usable even without
the tab bar, but this could be improved further indeed.

> Navigating tabs with "C-X t o" is error prone since it provides no
> feedback which tab is selected (different tabs may show identical window
> configurations at a specific point of time).  Perhaps it should show the
> name of the selected tab in the echo area?  Or the name of the
> tab could be shown in the mode line?

Most commands (new tab and close tab) already display the message,
but not when a tab is selected.  Thanks for noticing.  This is now
improved to show the name of the selected tab in the echo area.

> I'd prefer to navigate tabs like buffers via names and completion.
> This would be like switch-to-buffer, how about "C-X t t" as the default
> key binding?  This would happen in the echo area, therefore be less
> visual intrusive and keep the current window configuration visible
> till I choose the next one, while tab-list blanks the whole frame till I
> choose the next one from this list.

There is already the command like switch-to-buffer to select a tab by name
with completion.  The command name is 'tab-bar-select-tab-by-name'
(alias of 'tab-bar-switch-to-tab').  So you propose to bind it
to the key 'C-x t t'?  This key is the most convenient to type,
so it should be used for the most frequently used tab command.
Do you think 'tab-bar-switch-to-tab' would be the most frequently
used command?

> M-x tab-list creates a temporary tab, which looks like a buffer in a
> window, but is not shown for instance as a buffer in ibuffer.  Other
> than ibuffer or list-buffers which split the window and therefore
> provide some visual context, tab-list destroys this context.

Actually, tab-list was designed to not destroy the window configuration.
Unlike ibuffer or list-buffers that split the window, tab-list can't do
the same.  If tab-list will split the window, then after selecting
another tab in the list and later going back to the same tab, will
still display the window with tab-list, and the same window will be
presented in every tab that would be annoying.  Thus tab-list
takes care to not break user's window configurations.

> The names of the tabs are somehow centred vertically and horizontally,
> which irritates me.

They are centered to resemble the window list displayed by window managers
in the center of the screen when switching windows.  If you don't like this,
maybe there could be an option to display the list in the top left corner
of the frame?

> I would prefer tab-list to create a buffer which mimics list-buffers or
> better ibuffer.  This could be bound to "C-X t C-t".  Then I would have
> the choice to have a dedicated tab which shows this buffer or switch to
> it in a tab.  Perhaps it should be possible or even default to bury this
> tab list before switching to the next tab, in order to restore the
> windows configuration in the tab current when calling tab-list.

I don't understand how would use this dedicated tab to switch to it
from another tab.  Or do you want to use tab-list for other purposes,
not for selecting a tab from the list?

> Then for instance in ibuffer I can kill a line with C-K and yank it in
> another buffer.  This is not possible with the tab-list.  It only marks
> the tab on this line for deletion (which is ok) but does not copy it to
> the kill ring.

tab-list was modeled after list-buffers where C-k marks the buffer
for deletion.

There are so many features in ibuffer, many of them don't exist in
list-buffers, so I expect people will create packages that would
provide equivalents of many of them for tabs.

bug#38624: 27.0.50; [wish] tab navigation via keyboard should mimic buffer navigation

[Gregor Zattler]

Hi Juri,
* Juri Linkov <juri@linkov.net> [2019-12-16; 01:06]:
> Most commands (new tab and close tab) already display the message,
> but not when a tab is selected.  Thanks for noticing.  This is now
> improved to show the name of the selected tab in the echo area.

great, thanks!

>> I'd prefer to navigate tabs like buffers via names and completion.
>> This would be like switch-to-buffer, how about "C-X t t" as the default
>> key binding?  This would happen in the echo area, therefore be less
>> visual intrusive and keep the current window configuration visible
>> till I choose the next one, while tab-list blanks the whole frame till I
>> choose the next one from this list.
>
> There is already the command like switch-to-buffer to select a tab by name
> with completion.  The command name is 'tab-bar-select-tab-by-name'
> (alias of 'tab-bar-switch-to-tab').

I didn't know, this is good.

> So you propose to bind it
> to the key 'C-x t t'?  This key is the most convenient to type,
> so it should be used for the most frequently used tab command.
> Do you think 'tab-bar-switch-to-tab' would be the most frequently
> used command?

I do not have used tabs much, but would assume the most frequent
action would switching tabs.  I modeled this key stroke after
switch-to-buffer.  And the other one (see below) after buffer-list.

>> M-x tab-list creates a temporary tab, which looks like a buffer in a
>> window, but is not shown for instance as a buffer in ibuffer.  Other
>> than ibuffer or list-buffers which split the window and therefore
>> provide some visual context, tab-list destroys this context.
>
> Actually, tab-list was designed to not destroy the window configuration.
> Unlike ibuffer or list-buffers that split the window, tab-list can't do
> the same.  If tab-list will split the window, then after selecting
> another tab in the list and later going back to the same tab, will
> still display the window with tab-list, and the same window will be
> presented in every tab that would be annoying.  Thus tab-list
> takes care to not break user's window configurations.

Perhaps this window could be buried before switching tabs (see below).

>> The names of the tabs are somehow centred vertically and horizontally,
>> which irritates me.
>
> They are centered to resemble the window list displayed by window managers
> in the center of the screen when switching windows.  If you don't like this,
> maybe there could be an option to display the list in the top left corner
> of the frame?

This is obviously bike shedding, but I would prefer if it looked
similar to buffer-list or ibuffer.  So yes beinning in the top
left corner, perhaps with ab bit of margin but not much.

>> I would prefer tab-list to create a buffer which mimics list-buffers or
>> better ibuffer.  This could be bound to "C-X t C-t".  Then I would have
>> the choice to have a dedicated tab which shows this buffer or switch to
>> it in a tab.  Perhaps it should be possible or even default to bury this
>> tab list before switching to the next tab, in order to restore the
>> windows configuration in the tab current when calling tab-list.
>
> I don't understand how would use this dedicated tab to switch to it
> from another tab.

This would only be possible if the tab bar is shown.  Then one
could click on the tab for the tab list and go further from
there.  But probably nobody will use so many tabs?  Sorry, forget
this one...

> Or do you want to use tab-list for other purposes,
> not for selecting a tab from the list?

I assumed that tab list shows a buffer for managing tabs.
Create, delete, perhaps regroup them.  And perhaps users would
like to have a dedicated tab (leftmost?) for that.  I personally
will use this feater via keyboard and therefore it is not
important for me to have a dedicated tab list tab.

>> Then for instance in ibuffer I can kill a line with C-K and yank it in
>> another buffer.  This is not possible with the tab-list.  It only marks
>> the tab on this line for deletion (which is ok) but does not copy it to
>> the kill ring.
>
> tab-list was modeled after list-buffers where C-k marks the buffer
> for deletion.

Oh, I see, I compared it to ibuffer.

> There are so many features in ibuffer, many of them don't exist in
> list-buffers, so I expect people will create packages that would
> provide equivalents of many of them for tabs.

Thanks for your explanation.  And thanks for tab-bar-mode.


Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-

bug#38624: 27.0.50; [wish] tab navigation via keyboard should mimic buffer navigation

[Juri Linkov]

>> So you propose to bind it
>> to the key 'C-x t t'?  This key is the most convenient to type,
>> so it should be used for the most frequently used tab command.
>> Do you think 'tab-bar-switch-to-tab' would be the most frequently
>> used command?
>
> I do not have used tabs much, but would assume the most frequent
> action would switching tabs.  I modeled this key stroke after
> switch-to-buffer.  And the other one (see below) after buffer-list.

The key sequence for switching tabs doesn't need to be the easiest
to type, because after running it, the user still needs to type
the tab name to switch to, that requires more key strokes anyway.

>> Actually, tab-list was designed to not destroy the window configuration.
>> Unlike ibuffer or list-buffers that split the window, tab-list can't do
>> the same.  If tab-list will split the window, then after selecting
>> another tab in the list and later going back to the same tab, will
>> still display the window with tab-list, and the same window will be
>> presented in every tab that would be annoying.  Thus tab-list
>> takes care to not break user's window configurations.
>
> Perhaps this window could be buried before switching tabs (see below).

Maybe using quit-window before switching tabs, although this might
cause other problems.

Another problem is what to do when the user uses the tab list to delete
the current window configuration (i.e. where the tab list is shown),
this might have unexpected effect.

Neither there is no "*Buffer List*" buffer in the list of buffers
displayed by 'list-buffers', nor there is no "*Ibuffer*" buffer in
the list of buffers displayed by 'ibuffer'.  That's because they
don't allow killing the same buffer where the buffer list is shown.
Should the tab list allow deleting the tab where the tab list is shown?

>> Or do you want to use tab-list for other purposes,
>> not for selecting a tab from the list?
>
> I assumed that tab list shows a buffer for managing tabs.
> Create, delete, perhaps regroup them.  And perhaps users would
> like to have a dedicated tab (leftmost?) for that.  I personally
> will use this feater via keyboard and therefore it is not
> important for me to have a dedicated tab list tab.

Thanks for your explanation, now it's clear what you expected from this,
so you want an ibuffer-like buffer for managing tabs.

Currently tab-bar.el contains commands for switching tabs,
not for managing tabs like ibuffer manages buffers.

Since current commands are designed to work like a so-called
"task switcher" that is used in window managers to switch windows,
tab-list was a misnomer.  To reduce confusion I will rename
tab-list to tab-switcher in tab-bar.el.

Then later will create a new ELPA package tab-list.el
that could be developed and used even after Emacs 27 is released,
so its development won't delay the pretest of Emacs 27.

I expect many ibuffer-like features will be implemented in this package,
so it will have the same size as currently the whole tab-bar.el has.

The tab-list.el package could display the tab list using outlines.
For example:

   - Frame 1
    - Tab 1.1
      - Buffer 1.1.1   Size Mode Filename
      - Buffer 1.1.2   Size Mode Filename
    - Tab 1.2
      - Buffer 1.2.1   Size Mode Filename
      - Buffer 1.2.2   Size Mode Filename
      - Buffer 1.2.3   Size Mode Filename
D  - Frame 2
D   - Tab 2.1
      - Buffer 2.1.1   Size Mode Filename
D     - Buffer 2.1.2   Size Mode Filename
    - Tab 2.2
 *%   - Buffer 2.2.1   Size Mode Filename
 *%   - Buffer 2.2.2   Size Mode Filename
>*%   - Buffer 2.2.3   Size Mode Filename

where typing

RET on the frame line will select that frame;
RET on the tab line will switch to that tab;
RET on the buffer line will switch to that tab
    and select window with that buffer;

D x on the frame line will delete that frame;
D x on the tab line will close that tab;
D x on the buffer line will kill that buffer;

C-k or M-w will put the tab into the kill-ring;
C-y would yank the killed tab to another frame
    (when point is moved to another frame line)

Possibilities are endless...

bug#38624: 27.0.50; [wish] tab navigation via keyboard should mimic buffer navigation

[Gregor Zattler]

Hi Juri,
* Juri Linkov <juri@linkov.net> [2019-12-16; 23:46]:
>>> So you propose to bind it
>>> to the key 'C-x t t'?  This key is the most convenient to type,
>>> so it should be used for the most frequently used tab command.
>>> Do you think 'tab-bar-switch-to-tab' would be the most frequently
>>> used command?
>>
>> I do not have used tabs much, but would assume the most frequent
>> action would switching tabs.  I modeled this key stroke after
>> switch-to-buffer.  And the other one (see below) after buffer-list.
>
> The key sequence for switching tabs doesn't need to be the easiest
> to type, because after running it, the user still needs to type
> the tab name to switch to, that requires more key strokes anyway.

I would assume to use tab switching much more often than creation
or deletion.  Since one has to create a window configuration with
many key strokes before using it, it seems natural to use them for
a relative long time, hence the support in desktop session
saving.
And while one needs to type the name, this will be easier to type
and to remember since the name will presumably a simple word
without the need for modifier keys (e.g. "mail").
Perhaps switching by index is better -- for this I have to figure
out how to use desktop-save-mode along with notmuch (for
email).

>>> Actually, tab-list was designed to not destroy the window configuration.
>>> Unlike ibuffer or list-buffers that split the window, tab-list can't do
>>> the same.  If tab-list will split the window, then after selecting
>>> another tab in the list and later going back to the same tab, will
>>> still display the window with tab-list, and the same window will be
>>> presented in every tab that would be annoying.  Thus tab-list
>>> takes care to not break user's window configurations.
>>
>> Perhaps this window could be buried before switching tabs (see below).
>
> Maybe using quit-window before switching tabs, although this might
> cause other problems.
>
> Another problem is what to do when the user uses the tab list to delete
> the current window configuration (i.e. where the tab list is shown),
> this might have unexpected effect.

For me that would be the logical consequence from closing the
window configuration.

> Neither there is no "*Buffer List*" buffer in the list of buffers
> displayed by 'list-buffers', nor there is no "*Ibuffer*" buffer in
> the list of buffers displayed by 'ibuffer'.

You're right and I never noticed this.

> That's because they
> don't allow killing the same buffer where the buffer list is shown.
> Should the tab list allow deleting the tab where the tab list is shown?

Yup.

>>> Or do you want to use tab-list for other purposes,
>>> not for selecting a tab from the list?
>>
>> I assumed that tab list shows a buffer for managing tabs.
>> Create, delete, perhaps regroup them.  And perhaps users would
>> like to have a dedicated tab (leftmost?) for that.  I personally
>> will use this feater via keyboard and therefore it is not
>> important for me to have a dedicated tab list tab.
>
> Thanks for your explanation, now it's clear what you expected from this,
> so you want an ibuffer-like buffer for managing tabs.
>
> Currently tab-bar.el contains commands for switching tabs,
> not for managing tabs like ibuffer manages buffers.
>
> Since current commands are designed to work like a so-called
> "task switcher" that is used in window managers to switch windows,
> tab-list was a misnomer.  To reduce confusion I will rename
> tab-list to tab-switcher in tab-bar.el.
>
> Then later will create a new ELPA package tab-list.el
> that could be developed and used even after Emacs 27 is released,
> so its development won't delay the pretest of Emacs 27.
>
> I expect many ibuffer-like features will be implemented in this package,
> so it will have the same size as currently the whole tab-bar.el has.
>
> The tab-list.el package could display the tab list using outlines.
> For example:
>
>    - Frame 1
>     - Tab 1.1
>       - Buffer 1.1.1   Size Mode Filename
>       - Buffer 1.1.2   Size Mode Filename
>     - Tab 1.2
>       - Buffer 1.2.1   Size Mode Filename
>       - Buffer 1.2.2   Size Mode Filename
>       - Buffer 1.2.3   Size Mode Filename
> D  - Frame 2
> D   - Tab 2.1
>       - Buffer 2.1.1   Size Mode Filename
> D     - Buffer 2.1.2   Size Mode Filename
>     - Tab 2.2
>  *%   - Buffer 2.2.1   Size Mode Filename
>  *%   - Buffer 2.2.2   Size Mode Filename
>>*%   - Buffer 2.2.3   Size Mode Filename
>
> where typing
>
> RET on the frame line will select that frame;
> RET on the tab line will switch to that tab;
> RET on the buffer line will switch to that tab
>     and select window with that buffer;

the last one seems especially interesting to me.

> D x on the frame line will delete that frame;
> D x on the tab line will close that tab;
> D x on the buffer line will kill that buffer;
>
> C-k or M-w will put the tab into the kill-ring;
> C-y would yank the killed tab to another frame
>     (when point is moved to another frame line)

wow, sounds great.

For now I play with desktop-save-mode

Thanks for your answer, Gregor
--
 -... --- .-. . -.. ..--.. ...-.-

bug#38624: 27.0.50; [wish] tab navigation via keyboard should mimic buffer navigation

[Juri Linkov]

>> The key sequence for switching tabs doesn't need to be the easiest
>> to type, because after running it, the user still needs to type
>> the tab name to switch to, that requires more key strokes anyway.
>
> I would assume to use tab switching much more often than creation
> or deletion.  Since one has to create a window configuration with
> many key strokes before using it, it seems natural to use them for
> a relative long time, hence the support in desktop session
> saving.

Then I will bind tab switching by name to the most easy to type
key sequence 'C-x t RET tab-name RET' because reading the tab name
needs to be finished by RET too (like 'C-x 8 RET char-name RET').

> Perhaps switching by index is better -- for this I have to figure
> out how to use desktop-save-mode along with notmuch (for
> email).

Please try the already implemented switching by index
using customization of 'tab-bar-select-tab-modifiers'.

bug#38624: 27.0.50; [wish] tab navigation via keyboard should mimic buffer navigation

[Juri Linkov]

>> I would assume to use tab switching much more often than creation
>> or deletion.  Since one has to create a window configuration with
>> many key strokes before using it, it seems natural to use them for
>> a relative long time, hence the support in desktop session
>> saving.
>
> Then I will bind tab switching by name to the most easy to type
> key sequence 'C-x t RET tab-name RET' because reading the tab name
> needs to be finished by RET too (like 'C-x 8 RET char-name RET').

This is implemented now so that 'C-x t RET' provides default values
with names of tabs sorted by recency: 'C-x t RET RET' will switch to
the most recent tab, 'C-x t RET M-n M-n RET' to the second recent, etc.

bug#38624: 27.0.50; [wish] tab navigation via keyboard should mimic buffer navigation

[Gregor Zattler]

Hi Juri,
* Juri Linkov <juri@linkov.net> [2019-12-20; 01:21]:
>> Then I will bind tab switching by name to the most easy to type
>> key sequence 'C-x t RET tab-name RET' because reading the tab name
>> needs to be finished by RET too (like 'C-x 8 RET char-name RET').
>
> This is implemented now so that 'C-x t RET' provides default values
> with names of tabs sorted by recency: 'C-x t RET RET' will switch to
> the most recent tab, 'C-x t RET M-n M-n RET' to the second recent, etc.

Nice! Works automagically with helm which is also nice.

It irritated me though that the current tab is not a member of
the list.

Therefore with only one tab the list is empty.  If one then hits
RET on this empty list, there is an error message:
"funcall-interactively: Wrong type argument: number-or-marker-p,
nil".

I now see that an unconfigured emacs also does not show the
buffer from one called switch-to-buffer.  helm-mini which I
actually use, shows the the buffer you worked in when callin
helm-mini as a possible last target of the listed buffers.  This
seems more natural to me.




Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-

bug#38624: 27.0.50; [wish] tab navigation via keyboard should mimic buffer navigation

[Juri Linkov]

>> This is implemented now so that 'C-x t RET' provides default values
>> with names of tabs sorted by recency: 'C-x t RET RET' will switch to
>> the most recent tab, 'C-x t RET M-n M-n RET' to the second recent, etc.
>
> Nice! Works automagically with helm which is also nice.
>
> It irritated me though that the current tab is not a member of
> the list.

I wonder why would you want to switch to the current tab?

> Therefore with only one tab the list is empty.  If one then hits
> RET on this empty list, there is an error message:
> "funcall-interactively: Wrong type argument: number-or-marker-p,
> nil".

Thanks for noticing, this is fixed now.

> I now see that an unconfigured emacs also does not show the
> buffer from one called switch-to-buffer.  helm-mini which I
> actually use, shows the the buffer you worked in when callin
> helm-mini as a possible last target of the listed buffers.  This
> seems more natural to me.

Indeed switch-to-buffer does this for a reason - it would be
confusing for users to see the current buffer/tab in the
list of buffers/tabs to switch, e.g. when the user accidentally
selects the current buffer/tab from the list and nothing happens.

bug#38624: 27.0.50; [wish] tab navigation via keyboard should mimic buffer navigation

[Gregor Zattler]

Hi Juri,
* Juri Linkov <juri@linkov.net> [2019-12-22; 01:24]:
>> It irritated me though that the current tab is not a member of
>> the list.
>
> I wonder why would you want to switch to the current tab?

I did not *want* to switch to the current tab as in deliberately
calling tab-bar-select-tab-by-name with the intention to switch
to the current tab.  My test case was with one or two tabs and
the list of tabs was very short, shorter than expected.

>> Therefore with only one tab the list is empty.  If one then hits
>> RET on this empty list, there is an error message:
>> "funcall-interactively: Wrong type argument: number-or-marker-p,
>> nil".
>
> Thanks for noticing, this is fixed now.
>
>> I now see that an unconfigured emacs also does not show the
>> buffer from one called switch-to-buffer.  helm-mini which I
>> actually use, shows the the buffer you worked in when callin
>> helm-mini as a possible last target of the listed buffers.  This
>> seems more natural to me.
>
> Indeed switch-to-buffer does this for a reason - it would be
> confusing for users to see the current buffer/tab in the
> list of buffers/tabs to switch, e.g. when the user accidentally
> selects the current buffer/tab from the list and nothing happens.

I see.  It makes sense to shorten the list of targets to the
minimum.  To me it seems more natural to have a full list.  But I
agree that there is no loss in functionality if the current tab
is not member of the list.

Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-