Re: Separate area at the top for a serious tab bar

[martin rudalics]

> In NetBeans, you can split the editor vertically and have one tab
> bar over each half. Emacs' tabbar.el uses the "ruler" area, which is
> (or was?) a special area on top of each buffer.

Let's say on top of each window showing the buffer.

> This way, each Emacs
> buffer (or "window") has a tab bar at its top. If I split the frame
> vertically with split-window-below, I get to see 2 tab bars.

Right.

>>From the documentation, I guess I cannot have a "side window"
> automatically placed on top of each buffer (or "window"), because
> side windows only apply to entire frames. Is that right?

Right.

> I have seen that you can nest windows, which are then called
> "internal windows".

Emacs windows are "nested" by default.  That is, splitting a window
makes a new internal window unless such a window exists already and
can be reused.

> Would a tab bar based on that be hard to manage?
> I guess that the tab bar would then be another Window as far as
> Emacs is concerned, so windmove-up would then take me to the tabbar
> over its buffer window, which I do not really want.

In this (and in any related case) set the 'no-other-window' parameter
of the window that you do not want to select.  'window-in-direction'
which should be called by 'windmove-up' respects that.

> Buffer windows
> might also get confused if they suddenly move down in the window
> hierarchy in order to make room for a tool bar on top. Any tips on
> how I could approach a new tab bar implementation?

Do I understand correctly that you want a tabbar for each window?  In
that case I would suggest making an atomic window (section 28.20
Atomic Windows of the Elisp manual).  For how to accomplish that I
attach my old win-tabs.el.  (I plan to post a newer version of this
together with one for frame-tabs.el on GNU ELPA - for the moment
please live with some of its behavioral glitches.)

martin

win-tabs.el
Description: application/emacs-lisp