RE: Tab bar

[Drew Adams]

> > It makes sense.  My only doubt is whether we could find room
> > in the keys and buttons for these two options.
> 
> Users who want to use tabs will probably use them instead of 
> frames (in my experience, there is little overlap between users
> who want everything in one frame with tabs to select between them,
> and users who want a separate frame for everything),

I probably use separate frames as much as anyone, and that doesn't hold for me.
I use a tab bar also. 

I can't characterize my use well, but I guess I use it to cut down on the number
of visible frames or to group related buffers. To me, the overlap is more with
buffer-menu or the Buffers menu than with frames. 

With the wrinkle that tab bars for me are effectively[*] per frame, so they also
provide buffer groups per frame. And tabbar.el, at least, groups the buffers in
a tab bar further into sets based on their type (e.g. mode). So a tab bar, while
doing something similar to what a buffer menu or a set of iconified frames does,
is different, and offers its own benefits.

[*] Since I typically (but not always) have one window per frame, tabbar.el's
tab-bar-per-window is effectively tab-bar-per-frame, for me.

I use all of these: separate frames, iconified (actually thumbnail) frames, and
tab bars. And I sometimes use multiple windows in a frame. You could use some of
these systematically as replacements for others, but I somehow find a way to use
them together that suits me.

The point is that we should avoid assumptions based on generalizations such as
"users who want everything in one frame" and "users who want a separate frame
for everything". I, at least, am in neither of those extreme camps. Better to
remove such "everything" suppositions from the UI design, and provide also for
users who are not at such spectrum extremes. (You can use both C-x b and C-x
C-b, even though someone could argue that one is enough and one key binding
should suffice.)

> so sharing
> keybindings with C-x 5 may be an acceptable solution if we cannot
> find free keys. Something like: if the current window or its
> containing frame is already tabbed, or if the 
> user or mode has expressed a preference for a tabbed UI, then 
> C-x 5 C-f creates a new tab, and C-u C-x 5 C-f creates a new frame. 
> Otherwise the behaviour of C-x 5 bindings are reversed.

I don't have much to say now about the possible key bindings, and I'm not sure
we should start with that. Wait and see how users (or at least developers) use
the features first. You might be right that a general preference, plus `C-u' to
temporarily reverse the preference, would be a good way to handle this, but I
don't think that needs to be decided up front.

One thing that would be useful, I think, would be providing ways (e.g. keys or
mouse clicks) to change the representation. You might first put some buffers in
their own frames, but later want to group them using a tab bar, or vice versa.
Likewise, for a buffer's own tab vs a shared tab. Likewise for movement of
buffers (or whatever) among different tab bars or different tab-bar sets (a la
tabbar.el). For example, be able to easily:

. Break a buffer (or whatever) out of one tab and into its own window, frame or
another tab. This is analogous to `mouse-tear-off-window'.

. The opposite: merge the buffers of two tabs into one tab. Push a buffer into
an existing tab, removing it from other display locations (other frame, other
tab).

And, whatever we do in the way of adding tabs etc., we will need to also deal
with the removal of their elements (e.g. buffers). I'm thinking of `q' as in
`quit-window'. We should keep things simple for this, and not repeat the fiasco
of the thousand-and-one View-mode quitting dances. Killing a buffer, for
instance, should simply remove it from all tabs - it should not replace it with
some other buffer (as happens today for Emacs windows).

Finally, as is often the case with Emacs, although we can plan use cases for
certain features, we cannot really foresee how they might be used together in
novel and useful ways. The more we can keep the implementation of a new feature
such as tab bars in Lisp (vs C), the more users will be able to discover and
invent useful UI patterns that take advantage of and extend the feature. Emacs
has that potent advantage. Adding tab bars should open doors to new, creative UI
patterns and features - vs simply hard-coding tab behavior copied from web
browsers.