Re: Gtk tabs in emacs, new branch.

Re: Gtk tabs in emacs, new branch.

[A. Soare]

> It is too early to tell.  The implementation and design is still 
> evolving.  Implementations other than for Gtk+ makes sense in any case.
> 
> 	Jan D.


Before the implementation that I have in mind now, I have tried more versions, and I gave up.

I do not want to add widgets to an implementation based on another idea , than that of a lisp function for all kinds of events: a lisp function at the creation, a function when closing, switching, etc.

So I do not want to work on an already - implemented version of tabs, as time as that implementation does not share this idea.

It does not matter, I can do other tasks for emacs, if tabs will be implemented by someone else.


Alin
---
Wenn ich Kultur höre, nehme ich meine Pistole.



____________________________________________________

 Voila People a retrouvé les photos que les stars aimeraient oublier sur http://people.voila.fr/people/mediatheque/dossiers/ces-stars-pour-qui-le-temps-a-bien-fait-les-choses.html

Re: Gtk tabs in emacs, new branch.

[Jan D.]

A. Soare wrote:

> 
> I do not want to add widgets to an implementation based on another
> idea , than that of a lisp function for all kinds of events: a lisp
> function at the creation, a function when closing, switching, etc.

It isn't any "idea" as such, it is practicallity and user experience. 
For example, I tried having switching in elisp, but it is too slow 
(causes flicker) and there are race conditions between when the widget 
does the switching and when Emacs thinks the switch is done.

There is nothing in the current implementation that excludes lisp 
functions for switching, creation, e.t.c, but it doesn't give any 
advantages, just complications.

Also, creation may be by drag and drop from other frames.  Due to the 
way Gtk+ implements this, and how Emacs lisp may interact with GUI 
callbacks, doing that in lisp isn't possible.

Having an idea may be good, but sometimes reality requires other ways.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

> It isn't any "idea" as such, it is practicallity and user experience. For
> example, I tried having switching in elisp, but it is too slow (causes
> flicker) and there are race conditions between when the widget does the
> switching and when Emacs thinks the switch is done.

> There is nothing in the current implementation that excludes lisp
> functions for switching, creation, e.t.c, but it doesn't give any
> advantages, just complications.

Tabs may seem like a good idea to switch between different
window-configurations, but there can actually be other uses for it.
And even for that use, there can be different choices in terms of which
tabs to show, ...
All that needs to be written in Lisp.


        Stefan

Re: Gtk tabs in emacs, new branch.

[Juri Linkov]

> Tabs may seem like a good idea to switch between different
> window-configurations, but there can actually be other uses for it.
> And even for that use, there can be different choices in terms of which
> tabs to show, ...
> All that needs to be written in Lisp.

In the `x-tabs' branch, creating and switching tabs in the tab-bar is
implemented in Lisp in tab-bar.el where tabs can be used for anything.

The most useful application of tabs for switching window-configurations
is implemented in the separate file tab.el.

I think the `gtk-tabs' branch should do something like that.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Juri Linkov skrev 2010-04-10 03.36:
>> Tabs may seem like a good idea to switch between different
>> window-configurations, but there can actually be other uses for it.
>> And even for that use, there can be different choices in terms of which
>> tabs to show, ...
>> All that needs to be written in Lisp.
>
> In the `x-tabs' branch, creating and switching tabs in the tab-bar is
> implemented in Lisp in tab-bar.el where tabs can be used for anything.
>
> The most useful application of tabs for switching window-configurations
> is implemented in the separate file tab.el.
>
> I think the `gtk-tabs' branch should do something like that.
>

Something like what?  Switching window configurations or used for anything?

Having tabs in Gtk+ is mostly to have the look and feel of the current user 
selected UI-theme, but also to behave like tabs in other applications.

Your implementation is more like a tool bar and probably more general (arrows 
in a Gtk-tab would look funny for example).  But as with the native tool bar, 
the look and feel clashes with the selected theme.

Maybe you shouldn't call it tab-bar at all, but something like action-bar.  It 
is buttons you can use for different actions.  That is not what tabs does in 
current GUI-applications.


	Jan D.

Re: Gtk tabs in emacs, new branch.

[Juri Linkov]

>> I think the `gtk-tabs' branch should do something like that.
>
> Something like what?  Switching window configurations or used for anything?

I see two separate tasks here:

1. Using Gtk-tabs at the top the the frame to switch window configurations.
This is like tabs in web browsers and "perspectives" in Eclipse.

2. Using Gtk-tabs in subwindows to bind mode-specific actions to tabs.
This is like tabs above a subwindow in Eclipse that would allow
Emacs packages to create tabs above the window along with the header line.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Gtk tabs in emacs, new branch.

[Tobias C. Rittweiler]

Juri Linkov <juri@jurta.org> writes:

> I see two separate tasks here:
>
> 1. Using Gtk-tabs at the top the the frame to switch window configurations.
> This is like tabs in web browsers and "perspectives" in Eclipse.
>
> 2. Using Gtk-tabs in subwindows to bind mode-specific actions to tabs.
> This is like tabs above a subwindow in Eclipse that would allow
> Emacs packages to create tabs above the window along with the header line.

I've been following the discussion only cursorly, so please excuse any
ignorance on my part, but let me chime in with a real-life use case for
the 2nd variant:

In Common Lisp you can enter the debugger on a per thread basis. So at
the moment, every time an error is signaled in a thread, a new buffer
displaying a new debugger instance pops up. In case of many threads
interacting with each other, it can easily arise that an error in one
thread leads to other threads erroring out too after some small
delay. At the moment, input focus is always stolen after each delay
because a new buffer pops up, and you're essentially forced to wait
until the system reached an equilibrium.

Now there may be existing ways to improve that situation, but I think
mode-specific tabs would fit really well: for each new error in a
thread, a new tab will be pushed onto the existing tab list of the
debugger window.

  -T.

Re: Gtk tabs in emacs, new branch.

[David De La Harpe Golden]

Tobias C. Rittweiler wrote:

> I've been following the discussion only cursorly, so please excuse any
> ignorance on my part, but let me chime in with a real-life use case for
> the 2nd variant:
>

> In Common Lisp you can enter the debugger on a per thread basis. So at
> the moment, every time an error is signaled in a thread, a new buffer
> displaying a new debugger instance pops up

> Now there may be existing ways to improve that situation, but I think
> mode-specific tabs would fit really well: for each new error in a
> thread, a new tab will be pushed onto the existing tab list of the
> debugger window.
>


I don't think that in paricular is a strong a use case for juri's 2. 
relative to tabs-for-3rd-axis-for-window-splits as such  (If you haven't 
been following the thread closely admittedly the distinction may be 
unclear):

Each new debugger instance buffer could be opened in a new window, a 
window that's just put in a tab split with the other debugger instance 
windows (which might need some window group management, yes).

Re: Gtk tabs in emacs, new branch.

[David De La Harpe Golden]

Juri Linkov wrote:
>>> I think the `gtk-tabs' branch should do something like that.
>> Something like what?  Switching window configurations or used for anything?
> 
> I see two separate tasks here:
> 
> 1. Using Gtk-tabs at the top the the frame to switch window configurations.
> This is like tabs in web browsers and "perspectives" in Eclipse.
> 
> 2. Using Gtk-tabs in subwindows to bind mode-specific actions to tabs.
> This is like tabs above a subwindow in Eclipse that would allow
> Emacs packages to create tabs above the window along with the header line.
> 


Mode specific actions to tabs?

I do get a certain impression that people who propose 
non-switch-pane-of-content uses for tabs are really looking for just 
more toolbars - rows of buttons. NOT tabs, which have specific ui 
affordances towards being "for" managing stacked panes of content, and 
often the same panes that may also be tiled (like emacs).

And emacs has panes of content - windows...

Cnsider the GIMP's tab docks - You can have a layers window, channels 
window and paths window (not the gimp terminology, they actually call 
each window a "tab") docked into a tab group or a  brushes window, 
layers window and palette window.  Or whatever.  And rearrange them as 
you see fit.

[What's more, in contrast to ancient and quirky motif notebooks which 
used tabs like the index cards in a rolodex, not necessarily attached to 
every pane of content in the stack, in a splendid example of overly 
literal real-world analogy, modern guis have pretty much settled on that 
being 1:1]


Having said that, it would be possible to have both - my interwindow 
tabs as an interface for managing the window split 3rd axis, and further 
intrawindow tabs associated with a single window like a modeline, that
could either be mode-specific and presumably handled with callbacks to 
the mode code, or for what I strongly suspect people given such a 
callback api would end up wheel-reinventing repeatedly: a kind of 
narrowing the mode could initiate, with sections of the whole buffer 
narrowed to the different tabs.

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

> Mode specific actions to tabs?
> I do get a certain impression that people who propose
> non-switch-pane-of-content uses for tabs are really looking for just more
> toolbars - rows of buttons.

Indeed.  The current tool-bar has some serious limitations for tabs:
- the appearance isn't right.
- no text.
- can't have two "tool bars".

If we could have more flexible tool-bars (more control over the
appearance and content, more control over the possible key-bindings,
...) and if we could have more of them and placed differently
(e.g. anywhere in the window tree), then that would subsume the need for
tabs and the neds for extra header-lines.


        Stefan

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Stefan Monnier skrev:
>> Mode specific actions to tabs?
>> I do get a certain impression that people who propose
>> non-switch-pane-of-content uses for tabs are really looking for just more
>> toolbars - rows of buttons.
> 
> Indeed.  The current tool-bar has some serious limitations for tabs:
> - the appearance isn't right.
> - no text.

This is just a case of "nobody needed that yet".  It isn't hard to add.

> - can't have two "tool bars".
> 

Ditto for this.  However, a tool bar per window might be hard if we are 
talking native tool bars.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Juri Linkov]

>> - no text.
>
> This is just a case of "nobody needed that yet".  It isn't hard to add.

Gedit has text under tool-bar icons.  Some icons are not self-evident,
so text helps to understand what they do.  An option for icon/text/icon+text
would be nice for the Emacs tool-bar.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

>>> - no text.
>> This is just a case of "nobody needed that yet".  It isn't hard to add.
> Gedit has text under tool-bar icons.  Some icons are not self-evident,
> so text helps to understand what they do.  An option for icon/text/icon+text
> would be nice for the Emacs tool-bar.

Indeed.  But for uses like tabs, the icons might not be an option.


        Stefan

Re: Gtk tabs in emacs, new branch.

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 856 bytes --]

>> Gedit has text under tool-bar icons.  Some icons are not self-evident,
>> so text helps to understand what they do.  An option for icon/text/icon+text
>> would be nice for the Emacs tool-bar.
>
> Indeed.  But for uses like tabs, the icons might not be an option.

For the per-frame tab-bar, yes.

But for interior per-window tab-bars I am completely lost now
since there is too wide range of opinions how general they should be
and what they should do.

If a tab is just a little rectangle on the screen associated
with an action, then the tab-bar is indistinguishable from the
tool-bar, so we might need only tool-bars inserted into the window-tree.

This screenshot illustrates how interior per-window tool-bars and
tab-bars could look where the Info tab-bar displays Info-breadcrumbs
and the lower tab-bar switches into compilation like in Eclipse:


[-- Attachment #2: tab-bars.png --]
[-- Type: image/png, Size: 47180 bytes --]

[-- Attachment #3: Type: text/plain, Size: 45 bytes --]


-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

> If a tab is just a little rectangle on the screen associated
> with an action, then the tab-bar is indistinguishable from the
> tool-bar, so we might need only tool-bars inserted into the window-tree.

Pretty much, yes.  Actually, maybe a better option is for a tabbar to be
*part* of a toolbar.


        Stefan

Header windows (was: Gtk tabs in emacs, new branch.)

[Juri Linkov]

>> If a tab is just a little rectangle on the screen associated
>> with an action, then the tab-bar is indistinguishable from the
>> tool-bar, so we might need only tool-bars inserted into the window-tree.
>
> Pretty much, yes.  Actually, maybe a better option is for a tabbar to be
> *part* of a toolbar.

We already have a mechanism suitable for creating per-window tool bars
and tab bars.  And the package tabbar.el that switches buffers proves
that the header line serves the purpose of the tab bar pretty well.

The header line can display a per-window tool-bar or tab-bar when
`header-line-format' is set to a propertized string that contains icons
with the `display' and `keymap' properties.

The only problem with the header line is the limitation of only one
instance per window.  Since the task of allowing multiple header-lines
is necessary to do anyway, it would be better to start with it.
But it seems this limitation is hard-coded and not easy to get rid of.

Maybe, a better option is to create header windows (i.e. a 1-line window
without the mode-line)?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Gtk tabs in emacs, new branch.

[Richard Stallman]

    > If a tab is just a little rectangle on the screen associated
    > with an action, then the tab-bar is indistinguishable from the
    > tool-bar, so we might need only tool-bars inserted into the window-tree.

    Pretty much, yes.  Actually, maybe a better option is for a tabbar to be
    *part* of a toolbar.

Logically that would be equivalent, but in GUI terms it would be
disappointing.  The visual appearance of tabs is very different from
the visual appearance of tool bar items.

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

>     Pretty much, yes.  Actually, maybe a better option is for a tabbar to be
>     *part* of a toolbar.
> Logically that would be equivalent, but in GUI terms it would be
> disappointing.  The visual appearance of tabs is very different from
> the visual appearance of tool bar items.

You misunderstood: when I said "tabbar" I really meant a bar with tabs
using their usual appearance.  Just that it should be possible to place
it with buttons on either side within the same screen area where the
toolbar is displayed.



        Stefan

Re: Gtk tabs in emacs, new branch.

[Stephen J. Turnbull]

Stefan Monnier writes:

 > Indeed.  But for uses like tabs, the icons might not be an option.

Why not?  Or do you mean to say that in many cases the expected icon
would not be informative?

Eg, I have Firefox set up to "Open all [my moderated mailing lists] in
tabs".  Most of them are for XEmacs, so each tab has the list name
(informative string), the XEmacs favicon (uninformative icon), and a
close box (uninformative widget).  Obviously, just the favicon
wouldn't be very useful!

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

> Obviously, just the favicon wouldn't be very useful!

My point exactly,


        Stefan

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Juri Linkov skrev 2010-04-13 01.47:
>>> - no text.
>>
>> This is just a case of "nobody needed that yet".  It isn't hard to add.
>
> Gedit has text under tool-bar icons.  Some icons are not self-evident,
> so text helps to understand what they do.  An option for icon/text/icon+text
> would be nice for the Emacs tool-bar.
>

For the GUI-part it is just a matter of not turning off text, like we do now. 
  But there are no short good strings available, the big part is adding those 
strings to all available tool bar items.  The help text or even the name is 
frequently too long.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

> For the GUI-part it is just a matter of not turning off text, like we do
> now.

That's a very Gtk-centric point of view.  The Lucid version begs to
differ,


        Stefan

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Stefan Monnier skrev 2010-04-13 14.30:
>> For the GUI-part it is just a matter of not turning off text, like we do
>> now.
>
> That's a very Gtk-centric point of view.  The Lucid version begs to
> differ,
>

Yes, a bit more work there, but not terribly diffcult.

	Jan D.

Text in Gtk tool bar. (Was: Gtk tabs in emacs, new branch.)

[Jan Djärv]

Stefan Monnier skrev:
>> For the GUI-part it is just a matter of not turning off text, like we do
>> now.
> 
> That's a very Gtk-centric point of view.  The Lucid version begs to
> differ,
> 

Actually there is no lucid toolbar, it is just native code and redisplay.  You 
get it even without using lucid.  Actually, a lucid tool bar replacement would 
be a good thing, but then lucid would be a requirement.

Anyway, I checked in the possibilty to have text in the tool bar.  Just for 
Gtk+ for now, I'm working on the native one.

See variable tool-bar-style for styles.  The default is taken from Xsettings 
(i.e. Gnome setting).

The code tries to generate a text for tool bar items based on key and caption. 
  This sometimes fails, so the property :label can be set on tool bar items. 
I've done this for a few items I saw at once, I'm sure plenty remain.

	Jan D.

Re: Text in Gtk tool bar. (Was: Gtk tabs in emacs, new branch.)

[Juri Linkov]

> Anyway, I checked in the possibilty to have text in the tool bar.  Just for
> Gtk+ for now, I'm working on the native one.
>
> See variable tool-bar-style for styles.  The default is taken from
> Xsettings (i.e. Gnome setting).
>
> The code tries to generate a text for tool bar items based on key and
> caption. This sometimes fails, so the property :label can be set on tool
> bar items. I've done this for a few items I saw at once, I'm sure
> plenty remain.

Do you have an idea how to implement the style `both'
(with text under image) on a non-toolkit build?

The remaining options `text' and `both-horiz' would be easy to do.
Actually, `both-horiz' is what the tab-bar uses: it shows the close icon
to the right of the tab label.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Text in Gtk tool bar. (Was: Gtk tabs in emacs, new branch.)

[Jan D.]

Juri Linkov wrote:
>> Anyway, I checked in the possibilty to have text in the tool bar.  Just for
>> Gtk+ for now, I'm working on the native one.
>>
>> See variable tool-bar-style for styles.  The default is taken from
>> Xsettings (i.e. Gnome setting).
>>
>> The code tries to generate a text for tool bar items based on key and
>> caption. This sometimes fails, so the property :label can be set on tool
>> bar items. I've done this for a few items I saw at once, I'm sure
>> plenty remain.
> 
> Do you have an idea how to implement the style `both'
> (with text under image) on a non-toolkit build?

Do you mean on the glyph (a.ka. redisplay) level or by the actual 
drawing done by for example X?  I don't think this can be done simply at 
the lisp level.  The overflow for the tool bar, and highlightning needs 
to handle text and image as one.  How do you deal with that in your 
tabs?  The tool bar display code is kind of hardwired in C anyway.

> 
> The remaining options `text' and `both-horiz' would be easy to do.
> Actually, `both-horiz' is what the tab-bar uses: it shows the close icon
> to the right of the tab label.

That is the RtoL version, both-horiz for Gtk+ has the icon to the left 
of the text, i.e. opposite of what a tab bar has.

	Jan D.

Re: Text in Gtk tool bar. (Was: Gtk tabs in emacs, new branch.)

[Juri Linkov]

>> Do you have an idea how to implement the style `both'
>> (with text under image) on a non-toolkit build?
>
> Do you mean on the glyph (a.ka. redisplay) level or by the actual drawing
> done by for example X?  I don't think this can be done simply at the lisp
> level.  The overflow for the tool bar, and highlightning needs to handle
> text and image as one.  How do you deal with that in your tabs?

Currently text and image are separate.  I'll try to use your new property
:label for the tab name.

>> The remaining options `text' and `both-horiz' would be easy to do.
>> Actually, `both-horiz' is what the tab-bar uses: it shows the close icon
>> to the right of the tab label.
>
> That is the RtoL version, both-horiz for Gtk+ has the icon to the left of
> the text, i.e. opposite of what a tab bar has.

Maybe then add a new style `text-image-horiz' (for icon to the right of
the label) to keep the tool-bar implementation closer to the tab-bar
implementation.  This style is not necessary to add to defcustom.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Text in Gtk tool bar. (Was: Gtk tabs in emacs, new branch.)

[Jan Djärv]

Juri Linkov skrev:

>>> The remaining options `text' and `both-horiz' would be easy to do.
>>> Actually, `both-horiz' is what the tab-bar uses: it shows the close icon
>>> to the right of the tab label.
>> That is the RtoL version, both-horiz for Gtk+ has the icon to the left of
>> the text, i.e. opposite of what a tab bar has.
> 
> Maybe then add a new style `text-image-horiz' (for icon to the right of
> the label) to keep the tool-bar implementation closer to the tab-bar
> implementation.  This style is not necessary to add to defcustom.
> 

The problem is that the Gtk+ tool bar can't do text-image-horiz, not even for 
a RtoL locale.

	Jan D.

RE: Gtk tabs in emacs, new branch.

[Drew Adams]

> I do get a certain impression that people who propose 
> non-switch-pane-of-content uses for tabs are really looking for just 
> more toolbars - rows of buttons. NOT tabs, which have specific ui 
> affordances towards being "for" managing stacked panes of 
> content, and often the same panes that may also be tiled (like emacs).

That tabs can be naturally used for managing stacked panes of content does not
mean that they should only be used for that. I see no contradiction between tabs
as "buttons" and tabs as selectors for stacked panes.

The former is more general, that's all. However, I would not like to see the
current Emacs tool-bar and its buttons as the model for Emacs tabs. We can do a
lot better. (See my other mail on this today.)

I agree with what Stefan said:

SM> Indeed.  The current tool-bar has some serious limitations
SM> for tabs:
SM> - the appearance isn't right.
SM> - no text.
SM> - can't have two "tool bars".
SM> 
SM> If we could have more flexible tool-bars (more control over the
SM> appearance and content, more control over the possible key-bindings,
SM> ...) and if we could have more of them and placed differently
SM> (e.g. anywhere in the window tree), then that would subsume 
SM> the need for tabs and the neds for extra header-lines.

> And emacs has panes of content - windows...

Well, "pane" kinda implies "window", so it's hard to argue with that. But Emacs
has lots of _sets_ of content (visible or not), and letting a tab select for
such a set of content is part of what I would like to see. I do not want to see
Emacs tabs being only about window selection (whether individual windows or
window configs).

Re: Gtk tabs in emacs, new branch.

[Juri Linkov]

> And emacs has panes of content - windows...

Let's clear this up: content is in buffers, panes of content are windows.

There are two ways to switch content in the window according to the
tab-bar click:

1. Update content of the buffer in the selected window.
   In this case, the same buffer gets erased and new content
   inserted into it with the same mode.

2. Switch the buffer in the selected window where the tab-bar
   belongs to the buffer's window.  This has one constraint: all related
   buffers should be in the mode that provides the same tab-bar.

> Cnsider the GIMP's tab docks - You can have a layers window, channels
> window and paths window (not the gimp terminology, they actually call each
> window a "tab") docked into a tab group or a  brushes window, layers window
> and palette window.  Or whatever.  And rearrange them as you see fit.

I don't think it's right to call these things "windows".  A "window" in Emacs
is the physical area of the screen in which a buffer is displayed.  So they
are rather a layers buffer, channels buffer and paths buffer.

Another variant is to call them "window-subtrees", i.e. as part of the
window-tree in window configurations.  This makes sense too: a layers
window-subtree, channels window-subtree and paths window-subtree.

This variant supposes there is a way to create a special window that
holds the tab-bar, prepare its window-subtrees and assign them to the
tab-bar's actions.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Gtk tabs in emacs, new branch.

[Stephen J. Turnbull]

Juri Linkov writes:

 > > Cnsider the GIMP's tab docks - You can have a layers window, channels
 > > window and paths window (not the gimp terminology, they actually call each
 > > window a "tab") docked into a tab group or a  brushes window, layers window
 > > and palette window.  Or whatever.  And rearrange them as you see fit.
 > 
 > I don't think it's right to call these things "windows".

That depends on the implementation.  Almost certainly, though, each of
these is actually a GUI widget, which is more or less equivalent in
Emacs terms to a window dedicated to a buffer.

 > A "window" in Emacs is the physical area of the screen in which a
 > buffer is displayed.

That's a restriction of Emacs, not of the concept of window, though.
Emacs is effectively a tiling window manager (within each frame).

 > So they are rather a layers buffer, channels buffer and paths
 > buffer.

This on the other hand is definitely not the case.  The GIMP's tabs
are indeed tightly bound to screen regions, whatever you want to call
them.  They are not conceptually independent of the screen, as Emacs
buffers are.

 > Another variant is to call them "window-subtrees",

The use of the word "call", suggesting that the underlying
implementation is the same, is misleading.  As you and others have
pointed out, in Emacs there are at least four different ways to
implement the usual tab behavior: (1) one Emacs window, clear and
rewrite the content of the associated buffer (eg, the echo area/
minibuffer); (2) one window, move point in the associated buffer
(bookmarks); (3) one window, switch associated buffers; and (4)
multiple windows, delete a window and restore another in its place.
(Here I use "Emacs window" in its general sense of a window tree,
which may be split horizontally or vertically.)

So far the only interesting argument I've seen against a general
callback implementation supporting any and all of the above, as well
as others my marginal imagination is insufficient to contain, is Jan's
claim that it results in flashing and a race condition.

In XEmacs, which implements its tab control widget with a generic
callback into Lisp, I admit that I do see flashing in builds with
Lucid toolkit and a homegrown tab control widget (based on Edward
Falk's free widget set available on the 'net, but heavily modified;
don't blame Ed!)  However I claim that this is a bug in our redisplay;
if you have a sufficiently slow X connection, you can see the tabs (in
fact the whole window) being redrawn multiple times as the result of a
single tab press.

In the ten years that we've had the tab control, I can't recall a bug
that was diagnosed as a race condition in the tab control.  So maybe
that's a problem for GTK builds, but GTK getting in the way of the
app's design is nothing new.

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Stephen J. Turnbull skrev:

> So far the only interesting argument I've seen against a general
> callback implementation supporting any and all of the above, as well
> as others my marginal imagination is insufficient to contain, is Jan's
> claim that it results in flashing and a race condition.
> 

There is flashing just by restoring window configurations as well, we really 
should have double buffering here.  I've introduced the purposed zero sized 
subwidgets to tabs so the tabs don't switch content at once.  This reduces 
flashing, but just to the same level as restoring window configurations.


> In the ten years that we've had the tab control, I can't recall a bug
> that was diagnosed as a race condition in the tab control.  So maybe
> that's a problem for GTK builds, but GTK getting in the way of the
> app's design is nothing new.

The race condition has more to do with Emacs event design (i.e. content change 
=> Gtk callback => elisp event => elisp function => switch windows => 
redisplay).  I removed that by saving and restoring window configurations in 
the Gtk callback and cut out the whole elisp part.  The zero sized subwidgets 
will fix that also, as content change no longer happens.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Tue, 13 Apr 2010 11:42:00 +0900
> Cc: Jan =?iso-8859-1?Q?Dj=E4rv?= <jan.h.d@swipnet.se>, "Emacs Dev
> 	\[emacs-devel\]" <emacs-devel@gnu.org>,
> 	David De La Harpe Golden <david@harpegolden.net>
> 
>  > A "window" in Emacs is the physical area of the screen in which a
>  > buffer is displayed.
> 
> That's a restriction of Emacs, not of the concept of window, though.
> Emacs is effectively a tiling window manager (within each frame).

Actually, there is no such restriction.  For example, the tool bar, in
its Emacs implementation, is just a specialized window.

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Eli Zaretskii skrev:
>> From: "Stephen J. Turnbull" <stephen@xemacs.org>
>> Date: Tue, 13 Apr 2010 11:42:00 +0900
>> Cc: Jan =?iso-8859-1?Q?Dj=E4rv?= <jan.h.d@swipnet.se>, "Emacs Dev
>> 	\[emacs-devel\]" <emacs-devel@gnu.org>,
>> 	David De La Harpe Golden <david@harpegolden.net>
>>
>>  > A "window" in Emacs is the physical area of the screen in which a
>>  > buffer is displayed.
>>
>> That's a restriction of Emacs, not of the concept of window, though.
>> Emacs is effectively a tiling window manager (within each frame).
> 
> Actually, there is no such restriction.  For example, the tool bar, in
> its Emacs implementation, is just a specialized window.

Not for the Gtk tool bar.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Eli Zaretskii]

> Date: Tue, 13 Apr 2010 20:15:07 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: "Stephen J. Turnbull" <stephen@xemacs.org>, juri@jurta.org, 
>  emacs-devel@gnu.org, david@harpegolden.net
> 
> >>  > A "window" in Emacs is the physical area of the screen in which a
> >>  > buffer is displayed.
> >>
> >> That's a restriction of Emacs, not of the concept of window, though.
> >> Emacs is effectively a tiling window manager (within each frame).
> > 
> > Actually, there is no such restriction.  For example, the tool bar, in
> > its Emacs implementation, is just a specialized window.
> 
> Not for the Gtk tool bar.

That doesn't matter.  My point is that a "window" in Emacs is not just
for displaying a buffer.  The fact that the Gtk build does not use
this feature does not diminish the feature in any way.

Re: Gtk tabs in emacs, new branch.

[Lennart Borgman]

On Sat, Apr 10, 2010 at 3:22 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>
> Tabs may seem like a good idea to switch between different
> window-configurations,


Switching between named window configuration seems like a good idea -
but is tabs actually needed for that?

Re: Gtk tabs in emacs, new branch.

[Juri Linkov]

>> Tabs may seem like a good idea to switch between different
>> window-configurations,
>
> Switching between named window configuration seems like a good idea -
> but is tabs actually needed for that?

Of course, you can use tabs without the tab-bar.  With tab.el from the
`x-tabs' branch, you will be able to work with tabs like with buffers
using the command `list-tabs' that like `list-buffers' displays a list
of tabs that will allow to switch between them.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Lennart Borgman skrev 2010-04-10 03.47:
> On Sat, Apr 10, 2010 at 3:22 AM, Stefan Monnier
> <monnier@iro.umontreal.ca>  wrote:
>>
>> Tabs may seem like a good idea to switch between different
>> window-configurations,
>
>
> Switching between named window configuration seems like a good idea -
> but is tabs actually needed for that?

Needed, no.  The best GUI for it?  Probably.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Lennart Borgman]

On Sat, Apr 10, 2010 at 8:15 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>
>
> Lennart Borgman skrev 2010-04-10 03.47:
>>
>> On Sat, Apr 10, 2010 at 3:22 AM, Stefan Monnier
>> <monnier@iro.umontreal.ca>  wrote:
>>>
>>> Tabs may seem like a good idea to switch between different
>>> window-configurations,
>>
>>
>> Switching between named window configuration seems like a good idea -
>> but is tabs actually needed for that?
>
> Needed, no.  The best GUI for it?  Probably.


So there are two parts of this:

- Implementing tabs.
- Better handling of window configurations, probably including naming,
save and restore etc.

Could we please move the second part to the main developing branch so
we can take advantage of that part as soon as possible?

Re: Gtk tabs in emacs, new branch.

[joakim]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Sat, Apr 10, 2010 at 8:15 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>>
>>
>> Lennart Borgman skrev 2010-04-10 03.47:
>>>
>>> On Sat, Apr 10, 2010 at 3:22 AM, Stefan Monnier
>>> <monnier@iro.umontreal.ca>  wrote:
>>>>
>>>> Tabs may seem like a good idea to switch between different
>>>> window-configurations,
>>>
>>>
>>> Switching between named window configuration seems like a good idea -
>>> but is tabs actually needed for that?
>>
>> Needed, no.  The best GUI for it?  Probably.
>
>
> So there are two parts of this:
>
> - Implementing tabs.
> - Better handling of window configurations, probably including naming,
> save and restore etc.

Dont we have this already in "winner" or "winring" or some of the
existing window configuration packages?

IMHO tabs should just be buttons that generate events that by default
are bound to activating a particular window configuration.

Then again, window configurations could be further enhanced by
finishing one of the "window group" proposals discussed some time
ago on this list, but that nots necesary for tabs.


> Could we please move the second part to the main developing branch so
> we can take advantage of that part as soon as possible?



>
-- 
Joakim Verona

Re: Gtk tabs in emacs, new branch.

[Lennart Borgman]

2010/4/10  <joakim@verona.se>:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> On Sat, Apr 10, 2010 at 8:15 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>>>
>>>
>>> Lennart Borgman skrev 2010-04-10 03.47:
>>>>
>>>> On Sat, Apr 10, 2010 at 3:22 AM, Stefan Monnier
>>>> <monnier@iro.umontreal.ca>  wrote:
>>>>>
>>>>> Tabs may seem like a good idea to switch between different
>>>>> window-configurations,
>>>>
>>>>
>>>> Switching between named window configuration seems like a good idea -
>>>> but is tabs actually needed for that?
>>>
>>> Needed, no.  The best GUI for it?  Probably.
>>
>>
>> So there are two parts of this:
>>
>> - Implementing tabs.
>> - Better handling of window configurations, probably including naming,
>> save and restore etc.
>
> Dont we have this already in "winner" or "winring" or some of the
> existing window configuration packages?


I don't thijnk so. I have not used winring.el, but it looks like it
can name window configurations. However it is not a part of Emacs.

None of them can save and restore window configurations from file
which I think is essential. I am thinking about adding that to
winsav.el. Most of it is already there, but I do not remember how far
we got with a printed representation of window configurations. Anyone
remember?


> Then again, window configurations could be further enhanced by
> finishing one of the "window group" proposals discussed some time
> ago on this list, but that nots necesary for tabs.


I think it is more essential than tabs. It can be used without tabs
and it enhances tabs.


>> Could we please move the second part to the main developing branch so
>> we can take advantage of that part as soon as possible?

Re: Gtk tabs in emacs, new branch.

[joakim]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> 2010/4/10  <joakim@verona.se>:
>> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>
>>> On Sat, Apr 10, 2010 at 8:15 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>>>>
>>>>
>>>> Lennart Borgman skrev 2010-04-10 03.47:
>>>>>
>>>>> On Sat, Apr 10, 2010 at 3:22 AM, Stefan Monnier
>>>>> <monnier@iro.umontreal.ca>  wrote:
>>>>>>
>>>>>> Tabs may seem like a good idea to switch between different
>>>>>> window-configurations,
>>>>>
>>>>>
>>>>> Switching between named window configuration seems like a good idea -
>>>>> but is tabs actually needed for that?
>>>>
>>>> Needed, no.  The best GUI for it?  Probably.
>>>
>>>
>>> So there are two parts of this:
>>>
>>> - Implementing tabs.
>>> - Better handling of window configurations, probably including naming,
>>> save and restore etc.
>>
>> Dont we have this already in "winner" or "winring" or some of the
>> existing window configuration packages?
>
>
> I don't thijnk so. I have not used winring.el, but it looks like it
> can name window configurations. However it is not a part of Emacs.
>
> None of them can save and restore window configurations from file
> which I think is essential. I am thinking about adding that to
> winsav.el. Most of it is already there, but I do not remember how far
> we got with a printed representation of window configurations. Anyone
> remember?
>

That sounds cool! There was a read representation added for hash tables
recenlty, will that help?

>> Then again, window configurations could be further enhanced by
>> finishing one of the "window group" proposals discussed some time
>> ago on this list, but that nots necesary for tabs.
>
>
> I think it is more essential than tabs. It can be used without tabs
> and it enhances tabs.

Yes, but development is stalled. Maybe I should try to revive my
proposal to the point of a bzr branch, maybe then others can bring their
proposals forward.

>
>>> Could we please move the second part to the main developing branch so
>>> we can take advantage of that part as soon as possible?
-- 
Joakim Verona

Re: Gtk tabs in emacs, new branch.

[Štěpán Němec]

Lennart Borgman <lennart.borgman@gmail.com> writes:
> None of them can save and restore window configurations from file
> which I think is essential. I am thinking about adding that to
> winsav.el. Most of it is already there, but I do not remember how far
> we got with a printed representation of window configurations. Anyone
> remember?

The recent thread discussing that starts here:
http://article.gmane.org/gmane.emacs.devel/121656


  Štěpán

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

> None of them can save and restore window configurations from file
> which I think is essential. I am thinking about adding that to
> winsav.el. Most of it is already there, but I do not remember how far
> we got with a printed representation of window configurations. Anyone
> remember?

I agree that adding commands to manage window-configurations would be
good, and that we'll need additional low-level functionality to make it
work well (e.g. so you can restore a window-configuration in
a different frame, and/or a different session).

I'll be happy to integrate such a thing in Emacs,


        Stefan

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

joakim@verona.se skrev 2010-04-10 11.46:

> Dont we have this already in "winner" or "winring" or some of the
> existing window configuration packages?

They can't save or restore configurations from file.  Winring seems more 
advanced, it uses C-x 7 as a prefix as do gtk-tabs.

>
> IMHO tabs should just be buttons that generate events that by default
> are bound to activating a particular window configuration.
>

As I said before, that causes flicker, race conditions and prohibits Gtk tab 
drag and drop.  Talk is easy, show us the implementation.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[joakim]

Jan Djärv <jan.h.d@swipnet.se> writes:

> joakim@verona.se skrev 2010-04-10 11.46:
>
>> Dont we have this already in "winner" or "winring" or some of the
>> existing window configuration packages?
>
> They can't save or restore configurations from file.  Winring seems
> more advanced, it uses C-x 7 as a prefix as do gtk-tabs.
>
>>
>> IMHO tabs should just be buttons that generate events that by default
>> are bound to activating a particular window configuration.
>>
>
> As I said before, that causes flicker, race conditions and prohibits
> Gtk tab drag and drop.  Talk is easy, show us the implementation.

Of course, sorry if it seemed like I implied any demands on your
implementation. My personal interest is really only in convenient
handling of window configurations, not in a tab gui as such. 


>
> 	Jan D.
-- 
Joakim Verona

Re: Gtk tabs in emacs, new branch.

[Juri Linkov]

>> So there are two parts of this:
>> - Implementing tabs.
>> - Better handling of window configurations, probably including naming,
>> save and restore etc.
>
> Dont we have this already in "winner" or "winring" or some of the
> existing window configuration packages?

The problem with existing packages is that they can't be used
without some modifications.

> IMHO tabs should just be buttons that generate events that by default
> are bound to activating a particular window configuration.

Don't forget that the other way round events (from window configurations
to tabs) should be possible too, e.g. changes in window configurations
should update the current tab's name, etc.

> Then again, window configurations could be further enhanced by
> finishing one of the "window group" proposals discussed some time
> ago on this list, but that nots necesary for tabs.

This is a separate feature. There are different names for it:
"window groups", "framelettes", "internal frames".  It basically means
an ability to insert special windows into the window tree.
There additional special windows could be:

  1. a grouping parent window for its subwindows
     (this can be done by adding a `parent' attribute to normal windows)
  2. an inner mode-specific tool-bar subwindow
  3. an inner mode-specific tab-bar subwindow

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Lennart Borgman skrev 2010-04-10 11.14:
> On Sat, Apr 10, 2010 at 8:15 AM, Jan Djärv<jan.h.d@swipnet.se>  wrote:
>>
>>
>> Lennart Borgman skrev 2010-04-10 03.47:
>>>
>>> On Sat, Apr 10, 2010 at 3:22 AM, Stefan Monnier
>>> <monnier@iro.umontreal.ca>    wrote:
>>>>
>>>> Tabs may seem like a good idea to switch between different
>>>> window-configurations,
>>>
>>>
>>> Switching between named window configuration seems like a good idea -
>>> but is tabs actually needed for that?
>>
>> Needed, no.  The best GUI for it?  Probably.
>
>
> So there are two parts of this:
>
> - Implementing tabs.
> - Better handling of window configurations, probably including naming,
> save and restore etc.
>
> Could we please move the second part to the main developing branch so
> we can take advantage of that part as soon as possible?

There is nothing that prevents you from starting implementing that in the 
trunk AFAIK.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Stefan Monnier skrev 2010-04-10 03.22:
>> It isn't any "idea" as such, it is practicallity and user experience. For
>> example, I tried having switching in elisp, but it is too slow (causes
>> flicker) and there are race conditions between when the widget does the
>> switching and when Emacs thinks the switch is done.
>
>> There is nothing in the current implementation that excludes lisp
>> functions for switching, creation, e.t.c, but it doesn't give any
>> advantages, just complications.
>
> Tabs may seem like a good idea to switch between different
> window-configurations, but there can actually be other uses for it.
> And even for that use, there can be different choices in terms of which
> tabs to show, ...
> All that needs to be written in Lisp.

I'm not a big fan for making things general just for the sake of making things 
general so we maybe in the future can add something we don't know what it is now.

Are there any concrete examples of other uses?  I still think window 
configurations are the "natural" thing, as this is how tabs are used in web 
browsers, other editors, IDE:s and so on.  That doesn't mean that tabs must be 
exclusively about window configurations.  The implementation can easily be 
made to do tabs also for "other" lisp-based uses.  But implementation for the 
primary use case (window configurations) should not have to suffer because of 
other uses.

But I still haven't seen any example of other uses, so I haven't made gtk-tabs 
for that.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

> I'm not a big fan for making things general just for the sake of making
> things general so we maybe in the future can add something we don't know
> what it is now.

It's not just making them more general.  It's making them work in the
"right/natural" way.  In Emacs this usually means among other things
that clicks on it should generate Elisp events caught via a keymap and
that the list of tabs should be specified by Elisp code.

> Are there any concrete examples of other uses?

I can imagine switching the buffer of one of the windows (in an ECB-style
frame, for example).  In mpc.el I could imagine using it to switch
between various selections.

> I still think window configurations are the "natural" thing, as this
> is how tabs are used in web browsers, other editors, IDE:s and so on.

No one is arguing against that.

> But implementation for the primary use case (window configurations)
> should not have to suffer because of other uses.

I still don't understand what kind of suffering you're referring to.
If you could describe more concretely (e.g. what kind of undesirable
user-behavior could happen in which case and why).


        Stefan

Re: Gtk tabs in emacs, new branch.

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> It's not just making them more general.  It's making them work in the
> "right/natural" way.  In Emacs this usually means among other things
> that clicks on it should generate Elisp events caught via a keymap and
> that the list of tabs should be specified by Elisp code.

If clicking on a tab is to act via keybindings, maybe the neatest way to
handle this is to allow keys to be bound to window configurations, with
the meaning of "impose this window configuration".  Then the Lisp side
of the tab feature would act by storing window configurations in a
keymap.

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

>> It's not just making them more general.  It's making them work in the
>> "right/natural" way.  In Emacs this usually means among other things
>> that clicks on it should generate Elisp events caught via a keymap and
>> that the list of tabs should be specified by Elisp code.
> If clicking on a tab is to act via keybindings, maybe the neatest way to
> handle this is to allow keys to be bound to window configurations, with
> the meaning of "impose this window configuration".

I don't think we need any such new feature.  It's easy to use a binding
like

   (define-key map <foo>
     `(lambda () (interactive) (restore-window-configuration ,bar)))


-- Stefan

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Stefan Monnier skrev:

> 
>> Are there any concrete examples of other uses?
> 
> I can imagine switching the buffer of one of the windows (in an ECB-style
> frame, for example).

Isn't that a window configuration?  I don't get it.

> In mpc.el I could imagine using it to switch
> between various selections.

I don't know what mpc.el is, so the statements has no meaning.


> 
>> But implementation for the primary use case (window configurations)
>> should not have to suffer because of other uses.
> 
> I still don't understand what kind of suffering you're referring to.
> If you could describe more concretely (e.g. what kind of undesirable
> user-behavior could happen in which case and why).

The most obvious thing is flickering.  When the user clicks on the tab Gtk+ 
switches tab, there is nothing you can do about that.  Depending on what was 
drawn in that widget previously, something else is shown than what was shown 
in the old wiindows before.  Then a callback is made.  From here we can 
generate a Lisp event.  Then the event goes to some elisp defun  Then the 
window confiuration is extracted and applied.  Then redisplay happens.  This 
takes time and looks bad, unless you have a fast machine.

You guys seem to think that tabs are just extra buttons to be pressed.  In 
Gtk+ they are not.  When you press on a tab an whole new Gtk widget (with 
associated X window) covering the whole frame is switched in.  So the old 
contents is not shown.  Doing window configuration switch as fast as we can 
helps, but it still isn't good.  Workable, but not good.

Add saving of the old configuration to this and more time passes before a 
redsplay.

Then there is the race condition.  Say we restore window configurations in 
elisp.  But from the time Gtk+ does the switch until the new window 
configuration is in place, the old one is in Emacs idea of what is on the 
screen, but as I said earlier, it isn't what is really on screen.  So 
redisplay may happen, based on the old configuration, making the flicker even 
more annoying.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[David De La Harpe Golden]

Jan Djärv wrote:


> You guys seem to think that tabs are just extra buttons to be pressed.  
> In Gtk+ they are not.  When you press on a tab an whole new Gtk widget 
> (with associated X window) covering the whole frame is switched in.  So 
> the old contents is not shown. 

This I think is why I liked the idea of whole-emacs-frames being "in" 
gtk tab notebooks rather than vice-versa.  So what are the tab notebooks 
"in" from the emacs perspective? It doesn't matter, some sort of 
transient thingy created and destructed on demand - doesn't really need 
to be visible to the emacs lisp side, since the x11-level window manager 
plus the outer gtk notebook layer is acting as the "window manager" 
level layer to emacs frames.



OTOH - can one fudge a gtk notebook with funny dimensions and catch
the tab change event? i.e. rather than putting the old contents "truly" 
in the tab notebook

  _______________
|   \___\_______|
|+-------------+|
||             ||
||             ||
|+-------------+|
|_______________|

fake it with a zero-sized content of each tab, and just put the contents 
next to it?

  _______________
|___\___\_______|
+---------------+
|               |
|               |
+---------------+

There might be fugliness problems, of course.

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

David De La Harpe Golden skrev 2010-04-10 18.40:

> OTOH - can one fudge a gtk notebook with funny dimensions and catch
> the tab change event? i.e. rather than putting the old contents "truly"
> in the tab notebook
>
> _______________
> | \___\_______|
> |+-------------+|
> || ||
> || ||
> |+-------------+|
> |_______________|
>
> fake it with a zero-sized content of each tab, and just put the contents
> next to it?
>
> _______________
> |___\___\_______|
> +---------------+
> | |
> | |
> +---------------+
>
> There might be fugliness problems, of course.
>

I don't know if you could do it, but I suspect it can't be zero sized, and 
then you have widget placements to handle.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Davis Herring]

> You guys seem to think that tabs are just extra buttons to be pressed.  In
> Gtk+ they are not.  When you press on a tab an whole new Gtk widget (with
> associated X window) covering the whole frame is switched in.  So the old
> contents is not shown.  Doing window configuration switch as fast as we
> can helps, but it still isn't good.  Workable, but not good.

This isn't necessary, is it?  I'm sure that GTK+ tabs can govern (switch)
an area that isn't a top-most window.  Then, if we want to, we can just
make the "content" part of that area have 0 size (so that the user-visible
line of tabs is in fact the whole area they control) and merely react to
the tab switch events however we want.

This might cause the tab-switch-redraw to be slower than it would be if
GTK+ merely blits in some double-buffered image it remembered from the
last time that tab was foremost, but I've never noticed that things like
C-x 1 were slow enough to be a bother (except over very slow remote X11
connections), so this shouldn't be either.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Davis Herring skrev 2010-04-10 18.42:
>> You guys seem to think that tabs are just extra buttons to be pressed.  In
>> Gtk+ they are not.  When you press on a tab an whole new Gtk widget (with
>> associated X window) covering the whole frame is switched in.  So the old
>> contents is not shown.  Doing window configuration switch as fast as we
>> can helps, but it still isn't good.  Workable, but not good.
>
> This isn't necessary, is it?

What is "this"?

> I'm sure that GTK+ tabs can govern (switch)
> an area that isn't a top-most window.

Well, yes, that is what it is doing.  It isn't a top-most window.

> Then, if we want to, we can just
> make the "content" part of that area have 0 size (so that the user-visible
> line of tabs is in fact the whole area they control) and merely react to
> the tab switch events however we want.

I haven't tried it.  However, stuff like putting tabs at the bottom would then 
not work well.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Davis Herring]

>> This isn't necessary, is it?
>
> What is "this"?

Sorry -- I meant the window covering the whole frame and associated problems.

My whole message was practically identical to David's anyway (except for
the comprehensibility), so we need not worry about it.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Davis Herring skrev:
>>> This isn't necessary, is it?
>> What is "this"?
> 
> Sorry -- I meant the window covering the whole frame and associated problems.
> 

I just tested it, you can have zero sized widgets in the tab.  But there are 
borders the Gtk+ widget expects to draw around its children.  This now comes 
at the top, A minor issue.  I'll see if I can simplify my implementation with 
this approach.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[David De La Harpe Golden]

Jan Djärv wrote:
> 
> I just tested it, you can have zero sized widgets in the tab.  But there 
> are borders the Gtk+ widget expects to draw around its children.  This 
> now comes at the top, A minor issue.  I'll see if I can simplify my 
> implementation with this approach.
> 
>     Jan D.

Should make interior tabs easier to implement too. hmm.

So, I was wondering just how firefox tabs did their thing given the 
quirks of a naive gtk notebook instance.  People here are quite likely 
already aware of this:

Mozilla XUL's "native gtk" theme engine doesn't really use the
notebook widget directly at all for its "tabbox" (or other gtk widgets 
directly for most anything else...)!

It apparently makes an examplar singleton instance of each widget then 
borrows their (GtkStyle) style  members to pass to 
gtk_(paint|draw|style)_* functions to handle drawing lookalikes more 
flexibly itself.

You can see the idea in the mozilla sources:
http://mxr.mozilla.org/seamonkey/source/widget/src/gtk2/gtk2drawing.c

http://www.gtk.org/api/2.6/gtk/GtkStyle.html

This apparently includes scrollbars - maybe a way around gtk's scrollbar
quirks...

Though recasting "gtk" emacs to use the approach throughout might be 
...a lot of work...

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

David De La Harpe Golden skrev:
> Jan Djärv wrote:
>>
>> I just tested it, you can have zero sized widgets in the tab.  But 
>> there are borders the Gtk+ widget expects to draw around its 
>> children.  This now comes at the top, A minor issue.  I'll see if I 
>> can simplify my implementation with this approach.
>>
>>     Jan D.
> 
> Should make interior tabs easier to implement too. hmm.
> 
> So, I was wondering just how firefox tabs did their thing given the 
> quirks of a naive gtk notebook instance.  People here are quite likely 
> already aware of this:
> 
> Mozilla XUL's "native gtk" theme engine doesn't really use the
> notebook widget directly at all for its "tabbox" (or other gtk widgets 
> directly for most anything else...)!
> 
> It apparently makes an examplar singleton instance of each widget then 
> borrows their (GtkStyle) style  members to pass to 
> gtk_(paint|draw|style)_* functions to handle drawing lookalikes more 
> flexibly itself.
> 
> You can see the idea in the mozilla sources:
> http://mxr.mozilla.org/seamonkey/source/widget/src/gtk2/gtk2drawing.c

It is a clever hack, but I don't fancy drawing tabs "manually", handling 
drag&drop, memory allocations and so on.  It is a big job.

> 
> http://www.gtk.org/api/2.6/gtk/GtkStyle.html

Actually 2.6 is quite old, we even require 2.10 for Emacs.  2.20 is current.

> 
> This apparently includes scrollbars - maybe a way around gtk's scrollbar
> quirks...
> 
> Though recasting "gtk" emacs to use the approach throughout might be 
> ...a lot of work...

And kind of meaningless to use a toolkit in the first place.  The widgets are 
supposed to simplify things after all.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[David De La Harpe Golden]

Jan Djärv wrote:

> Actually 2.6 is quite old, we even require 2.10 for Emacs.  2.20 is 
> current.
>

Hah. Yeah, apparently current gtk documentation is on gnome.org not 
gtk.org and I restricted a web search to gtk.org. Premature optimization...

(for completeness 
http://library.gnome.org/devel/gtk/unstable/GtkStyle.html )

>>
>> This apparently includes scrollbars - maybe a way around gtk's scrollbar
>> quirks...
>>
>> Though recasting "gtk" emacs to use the approach throughout might be 
>> ...a lot of work...
> 
> And kind of meaningless to use a toolkit in the first place.

Well, you do still get the pretty/coherent style...

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

> And kind of meaningless to use a toolkit in the first place.  The widgets
> are supposed to simplify things after all.

Apparently the Gnome/Gtk guys aren't out to make life of application
writers easier.  They're instead dedicated to making things easy/uniform
for the end user, which imposes severe constraints on the applications,
especially ones like Emacs which haven't been designed around Gtk's ideas.


        Stefan

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Stefan Monnier skrev:

> Apparently the Gnome/Gtk guys aren't out to make life of application
> writers easier.  They're instead dedicated to making things easy/uniform
> for the end user, which imposes severe constraints on the applications,
> especially ones like Emacs which haven't been designed around Gtk's ideas.
> 

They do wan't Gtk+/Gnome applications to behave and look uniform, I think that 
is a good thing for a desktop environment.

On the other hand, the GUI design in Emacs is awkward at best and doesn't fit 
well with *any* toolkit out there.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

>> Apparently the Gnome/Gtk guys aren't out to make life of application
>> writers easier.  They're instead dedicated to making things easy/uniform
>> for the end user, which imposes severe constraints on the applications,
>> especially ones like Emacs which haven't been designed around Gtk's ideas.
> They do wan't Gtk+/Gnome applications to behave and look uniform, I think
> that is a good thing for a desktop environment.
> On the other hand, the GUI design in Emacs is awkward at best and doesn't
> fit well with *any* toolkit out there.

But the Gtk guys go to extra trouble to make sure that apps like Emacs
can't conveniently use Gtk to get what they want, without this effort
making it any easier for other apps to get a consistent look&feel.
[ I'm obviously thinking of scrollbars here. ]


        Stefan

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

>>> Are there any concrete examples of other uses?
>> I can imagine switching the buffer of one of the windows (in an ECB-style
>> frame, for example).
> Isn't that a window configuration?  I don't get it.

Not quite: e,g. you can create a new tab for "toto.c", switch to toto.h,
then resize some windows, then select the "toto.c" tab and it will
switch the buffer to toto.c without reverting the window sizes.

>> In mpc.el I could imagine using it to switch
>> between various selections.
> I don't know what mpc.el is, so the statements has no meaning.

It's emacs/lisp/mpc.el (new in Emacs-23.2), a front end (client) for the
Music Player Daemon.  So think of it as switch between different
selections in Rhythmbox's browser.

>>> But implementation for the primary use case (window configurations)
>>> should not have to suffer because of other uses.
>> I still don't understand what kind of suffering you're referring to.
>> If you could describe more concretely (e.g. what kind of undesirable
>> user-behavior could happen in which case and why).

> The most obvious thing is flickering.  When the user clicks on the tab Gtk+
> switches tab, there is nothing you can do about that.

I think we need to define "tab" here.  For me a "tab" is a little
rectangle on the screen with a label.  The actions on this tab are
usually linked to switching the content of an X window that's
drawn underneath.
From what you write I get the impression that your notion of a "tab"
includes not just the tab itself but also the window underneath.

> Depending on what was drawn in that widget previously, something else
> is shown than what was shown in the old wiindows before.

If I understand correctly, that means that Gtk tabs have a built-in
semantics of "switch the window underneath the tabbar".
That's obviously too restrictive for the kinds of use cases I suggest,
so we'd have to hack around it, e.g. by creating a dummy 0-pixel high
X-window where Gtk can "switch tabs" at its heart content without
bothering us.


        Stefan

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Stefan Monnier skrev:
>>>> Are there any concrete examples of other uses?
>>> I can imagine switching the buffer of one of the windows (in an ECB-style
>>> frame, for example).
>> Isn't that a window configuration?  I don't get it.
> 
> Not quite: e,g. you can create a new tab for "toto.c", switch to toto.h,
> then resize some windows, then select the "toto.c" tab and it will
> switch the buffer to toto.c without reverting the window sizes.
> 

Ok, that might be useful.

>>> In mpc.el I could imagine using it to switch
>>> between various selections.
>> I don't know what mpc.el is, so the statements has no meaning.
> 
> It's emacs/lisp/mpc.el (new in Emacs-23.2), a front end (client) for the
> Music Player Daemon.  So think of it as switch between different
> selections in Rhythmbox's browser.

Well, I don't use Rhythmbox either, so ... :-)

> 
>>>> But implementation for the primary use case (window configurations)
>>>> should not have to suffer because of other uses.
>>> I still don't understand what kind of suffering you're referring to.
>>> If you could describe more concretely (e.g. what kind of undesirable
>>> user-behavior could happen in which case and why).
> 
>> The most obvious thing is flickering.  When the user clicks on the tab Gtk+
>> switches tab, there is nothing you can do about that.
> 
> I think we need to define "tab" here.  For me a "tab" is a little
> rectangle on the screen with a label.  The actions on this tab are
> usually linked to switching the content of an X window that's
> drawn underneath.
>>From what you write I get the impression that your notion of a "tab"
> includes not just the tab itself but also the window underneath.

It is not my notion, it is Gtk+.

> 
>> Depending on what was drawn in that widget previously, something else
>> is shown than what was shown in the old wiindows before.
> 
> If I understand correctly, that means that Gtk tabs have a built-in
> semantics of "switch the window underneath the tabbar".
> That's obviously too restrictive for the kinds of use cases I suggest,
> so we'd have to hack around it, e.g. by creating a dummy 0-pixel high
> X-window where Gtk can "switch tabs" at its heart content without
> bothering us.

I'm looking into that now.  There is that damned border though...

	Jan D.

Re: Gtk tabs in emacs, new branch.

[David De La Harpe Golden]

Jan Djärv wrote:
> Stefan Monnier skrev:
>>>>> Are there any concrete examples of other uses?
>>>> I can imagine switching the buffer of one of the windows (in an 
>>>> ECB-style
>>>> frame, for example).
>>> Isn't that a window configuration?  I don't get it.
>>
>> Not quite: e,g. you can create a new tab for "toto.c", switch to toto.h,
>> then resize some windows, then select the "toto.c" tab and it will
>> switch the buffer to toto.c without reverting the window sizes.
>>
> 
> Ok, that might be useful.
> 

Hmm. Well, switching a "single window"* between buffers toto.c and 
toto.h might be something I'd rather use (yes, presently hypothetical) 
interior split-tab tabs, attached directly to the window in question.

This is not unusual - Note how eclipse has tab bars on multiple panes, 
and switching the main editor pane between files is done with the tab 
bar most directly attached to it:

http://www.eclipse.org/screenshots/images/FortranIde-RedFlag_Linux.png

(* actually in the implementation I envisage it'd be switching /between 
two emacs windows/ formed from a "split" on the "tab" axis, but at this 
level of the discussion that's a detail).

My reservations about window-configurations-as-thing-tab-switches also
turn out to apply:

See, thinking about it, switching window configurations as a whole could 
IMO be more like switching "perspectives" in eclipse (window 
configurations do currently encapsulate the buffer being shown in each 
window, and assuming split-tabbed existed would also record tab 
arrangement).

So a "debug" window configuration may have (possibly tabbed) windows 
open on buffers with your source, compilation outputs, a gdb window 
etc., while a "edit java" window configuration has windows with your 
source, a directory tree browser, doc and completion windows etc.

Now, a tab bar is probably still a vaguely reasonable UI for switching 
between a small number of perspectives, though not actually the UI 
eclipse uses (see the "Debug" button in the upper right of Fig.1 
screenshot here:

http://www.ibm.com/developerworks/library/os-ecbug/#N10089
)

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Stefan Monnier skrev 2010-04-10 17.19:
>In Emacs this usually means among other things
> that clicks on it should generate Elisp events caught via a keymap and
> that the list of tabs should be specified by Elisp code.

Are you suggesting we add and remove tabs dynamically to a keymap as they get 
created?  I'm not sure I follow.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

>> In Emacs this usually means among other things
>> that clicks on it should generate Elisp events caught via a keymap and
>> that the list of tabs should be specified by Elisp code.
> Are you suggesting we add and remove tabs dynamically to a keymap as they
> get created?  I'm not sure I follow.

Not necessarily, no (tho that's what we do for tool-bars), just that
when the user clicks on a tab, the action performed should be looked up
in a keymap.


        Stefan

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Stefan Monnier skrev 2010-04-12 21.18:
>>> In Emacs this usually means among other things
>>> that clicks on it should generate Elisp events caught via a keymap and
>>> that the list of tabs should be specified by Elisp code.
>> Are you suggesting we add and remove tabs dynamically to a keymap as they
>> get created?  I'm not sure I follow.
>
> Not necessarily, no (tho that's what we do for tool-bars), just that
> when the user clicks on a tab, the action performed should be looked up
> in a keymap.
>

I still don't get it.  If the user creates three tabs, where are the keymap 
entries for those if we don't create them?  Or do you mean a default entry 
that catches those tabs that haven't got an action set explicitly?


	Jan D.

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

>>>> In Emacs this usually means among other things
>>>> that clicks on it should generate Elisp events caught via a keymap and
>>>> that the list of tabs should be specified by Elisp code.
>>> Are you suggesting we add and remove tabs dynamically to a keymap as they
>>> get created?  I'm not sure I follow.
>> Not necessarily, no (tho that's what we do for tool-bars), just that
>> when the user clicks on a tab, the action performed should be looked up
>> in a keymap.
> I still don't get it.  If the user creates three tabs, where are the keymap
> entries for those if we don't create them?  Or do you mean a default entry
> that catches those tabs that haven't got an action set explicitly?

If we don't create one entry per tab, then we presumably would have
a single entry for all tabs, and the bound command would figure out
which tab was clicked by looking at the triggering event.

But again, I do not specifically care either way at this point.


        Stefan

Re: Gtk tabs in emacs, new branch.

[René Kyllingstad]

On Sat, Apr 10, 2010 at 5:19 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> Are there any concrete examples of other uses?
>
> I can imagine switching the buffer of one of the windows (in an ECB-style
> frame, for example).

Let's call that window the editor window.  This means having the tabs as
part of the frame instead of as part of the editor window.  The appeal is
clear: it affords more space for the tabs for an ECB-style frame.

However, it breaks the expectation that the tab changes the display of the
attached pane.

Eclipse provides a ECB style frame, but uses tabs-per-pane rather than tabs
at the frame level. This allows one to later add tabs to the individual
windows in ECB, and it makes the interface consistent wrt tabs.

In Eclipse this is put to good use, most of the ECB-style windows have tabs
on them.  It would be great if an Eclipse-like setup could be achieved in
Emacs.  This would mean:

  - a window-set-tabs function taking a list of (icon, text, tooltip, buffer).
    clicking on the tab displays the buffer.

That would take care of the non-editor windows. There are other features
needed (other-window shouldn't switch to the non-editor windows,
switch-buffer shouldn't suggest the buffers in the non-editor windows,
persistence of window configurations), but it would be useful by itself.

For the editor windows another mechanism is needed to create the tabs, as
the list of tabs should be some subset of the open buffers.

A related item: many Eclipse panes have tool-bars as well as tabs.  If
there is space for both the list of open tabs and the tool-bar on one line,
they are displayed with the tabs to the left, tool-bar buttons to the
right, otherwise they are broken up into two lines with the tabs above the
tool-bar.  The tool-bar is related to the current tab (displayed
buffer), so switching
tabs may remove the tool-bar or change its content.


-- René

Re: Gtk tabs in emacs, new branch.

[David De La Harpe Golden]

Jan Djärv wrote:


> Are there any concrete examples of other uses?  I still think window 
> configurations are the "natural" thing, as this is how tabs are used in 
> web browsers, other editors, IDE:s and so on.  That doesn't mean that 
> tabs must be exclusively about window configurations.

I'm still not sure about this.   At least the Gtk+ notebook model still 
suggests to me that the most natural thing to put in some toplevel 
outermost tabs for gtk purposes might be the emacs frames themselves.

I also still like my idea of tabs being a sort of third "depth" axis 
emacs windows are split on. Then such (interior*) tabs would be /an 
aspect of/ window configuration, not something that switches /between/ 
window configurations.

e.g. changing frame from window configuration
A to window configuration B involve rearranging the horizontal, 
vertical, and tab type window splits:

A:                              B:

  ________________________        ________________________
|              |         |      |                        |
|              |         |      |______   _______________|
|______________|         |      |__/__/__/__/____________|
|              |         |      |      |        |        |
|___   ________|         |      |   ___|________|________|
|__/__/__/_____|_________|      |__/__/__________________|


A: horizontally-split into 2 then LHS vertically-split into 2. Lower 
left then "tab-split" into 3 tabs.

B: vertically-split into 2.  Upper then "tab-split" into 4 tabs.  Lower 
tab-split into 2 tabs.  First tab then vertically-split into 3.

I suppose it doesn't preclude the outermost set of tabs switching 
between window configurations. Or frames. Or even outer tabs containing 
frames, second level switching window configurations of frames, and 
further interior tabs being split-window type. Sigh.

Anyway, talk is cheap - you have working code and I still don't, despite 
previously mentioning this months ago now, I haven't really been working 
on it.

>  The 
> implementation can easily be made to do tabs also for "other" lisp-based 
> uses.  

I'd also point out again there's a completely different sort of tab to 
consider - an emacs widget that is a tab notebook, that embeds _in_ a 
buffer like other emacs widgets for customisation.

That's little to do with your sort of tabs apart from my concern there's 
some possibility some non-window-configuration-switching use cases some 
people might be envisaging for tabs might be better served by a 
tabbed/notebook presentation composite emacs widget.

Re: Gtk tabs in emacs, new branch.

[Stephen J. Turnbull]

Jan Djärv writes:

 > I'm not a big fan for making things general just for the sake of
 > making things general so we maybe in the future can add something
 > we don't know what it is now.
 > 
 > Are there any concrete examples of other uses?

Because the tab metaphor involves switching a well-defined area of
screen from one use to another (I don't subscribe to the "just a
contiguous row of buttons" interpretation), one can trivially subsume
all uses into "window configuration management".  But the
implementation of changing what's seen onscreen might involve far more
than swapping one GUI widget in in place of another, and it might not
involve swapping GUI widgets at all (where for this purpose I consider
Emacs windows as widgets).

In use now?  Probably not, because of the very limited imaginations of
tab developers (or if you prefer, because of the very limited
imaginations that tab developers attribute to their users).

But easy to implement given a flexible tab framework?  Lots of them.
How about varying font-lock to highlight different aspects of a buffer
using "layers" of font-lock specs controlled by tabs?  Many others
that you might classify as "window configuration management", but
other users might not.  I have in mind switching "projects", which
might involve piles of behind the scenes machinery such as restoring
undisplayed buffers in the background, querying status of VCS, etc.

RE: Gtk tabs in emacs, new branch.

[Drew Adams]

> Because the tab metaphor involves switching a well-defined area of
> screen from one use to another..., one can trivially subsume
> all uses into "window configuration management".  But the
> implementation of changing what's seen onscreen might involve far more
> than swapping one GUI widget in in place of another, and it might not
> involve swapping GUI widgets at all (where for this purpose I consider
> Emacs windows as widgets).
> 
> In use now?  Probably not, because of the very limited imaginations of
> tab developers (or if you prefer, because of the very limited
> imaginations that tab developers attribute to their users).
> 
> But easy to implement given a flexible tab framework?  Lots of them.
> How about varying font-lock to highlight different aspects of a buffer
> using "layers" of font-lock specs controlled by tabs?  Many others
> that you might classify as "window configuration management", but
> other users might not.  I have in mind switching "projects", which
> might involve piles of behind the scenes machinery such as restoring
> undisplayed buffers in the background, querying status of VCS, etc.

`Amen' to "flexible tab framework". And Stephen gives good examples of
exploiting such generality. My message is in the same vein.

I don't really want to get into this thread much - don't have much to offer,
especially regarding implementation. I'd just suggest the following about what
tabs should be able to _do_, that is, what you should be able to do with them.

I have nothing particular to say now about the questions of where tabs are
(frame, window, subwindows, whatever), how the user interacts with them
(clicking, sorting, whatever), how they should be implemented, etc.

A different and at least equally important question is what happens when a tab
is selected/clicked: what actions are carried out? what does the tab actually do
or control? Emacs gives us the opportunity to do something much more general wrt
tabs than might exist elsewhere.

Other things being equal, we should not forego generality wrt what a tab
selection can do. We should not, for example, decide that tabs should only
switch among window configs or only among buffers or desktops or projects or...
At the least, we should allow a tab to invoke an arbitrary function. That means
at least providing a hook, a handler, or equivalent.

One model that can help guide the design is to allow (but of course not require)
a tab to be associated with an Emacs bookmark. Not just with the buffer
resulting from invoking a bookmark, but with the bookmark itself - that is, with
a particular entry in `bookmark-alist'. Again, I'm not at all suggesting that we
_limit_ tabs to bookmarks but that we allow tabs to access or map to existing
bookmarks. Thinking about bookmarks can help guide the discussion about what
tabs can/should do.

A bookmark is essentially a (persistent) named collection of info. That info
typically includes a destination, which is typically a file location and a
position within the file. But although that is typical, a bookmark need not be
associated with any destination.

A bookmark can record state of any kind (persistently), and invoking a bookmark
can restore that state, without necessarily "going to" any destination. The
state restored might be entirely invisible, for example.

Stephen's example of switching among projects, thus restoring project state, is
something that you can do using bookmarks. In my library bookmark+.el[*] for
example, there are Desktop bookmarks, Dired bookmarks that restore markings and
hidden-subdirs state, del.icio.us-style tags, and other ways to represent and
switch among things such as "projects". And more and better such could easily be
imagined. (I'm looking forward to restoring window configs once we have their
serialization.)

But jumping to a bookmark need not even restore anything. "Jumping" can do
anything you want it to. A bookmark can include a handler, which is pretty much
an arbitrary function that is invoked during "jumping". Users can easily define
their own types of bookmarks (e.g. with their own handlers). Bookmark+ offers
several examples of additional kinds of bookmarks and out-of-the-ordinary
bookmark handling, to give you an idea.

The bookmarking and bookmark-jumping mechanisms are very general and are
available for any possible kind of bookmark - which means pretty much any
(persistent) named collection of info.

Being able to have a tab represent (map to) a bookmark would be very useful,
IMO. By "represent" I mean just that a tab could have as its name a bookmark
name, and clicking (selecting) the tab would invoke ("jump" to) the bookmark.
IOW, the tab would just be a shortcut for a jump call, the same way that an
entry in the *Bookmark List* buffer (`C-x r l') is such a shortcut.

Look at it also from another point of view. In bookmark+ (for example), you can
hide or show (in the *Bookmark List*) the bookmarks that satisfy certain
properties. You can mark bookmarks and then perform operations on them (as in
Dired or Buffer Menu). You can sort the bookmarks that are visible. And so on.

I'd like to be able to do the same kinds of things with tabs: hide tabs based on
certain criteria, mark tabs, act on the marked tabs (or on all tabs), sort the
tabs in a given tab bar, etc. And that includes opening/showing a set of tabs
that satisfy some property (whether or not they were shown previously and then
hidden). For example, be able to hit a key to open/add (or close/hide) all tabs
belonging to a given project.

Whatever choices are made for implementing tabs in Emacs, I'd hope that they
could trivially be made to accommodate this suggestion (using bookmarks) - among
other uses. I mention the example of bookmarks to underline what Stephen T. and
others have said wrt letting tabs be general and not forcing them to map only to
certain things such as window configurations. Bookmarks serve as a good example,
as food for thought.

And the fact that bookmarks already offer so many possibilities of switching and
restoring state points out an important point: We need not build such
functionality into the tabs (design) themselves. We should just _allow_ tabs to
leverage other features of Emacs that provide such functionality.

It would be a mistake to try to decide the behavior of tabs - what they _do_ in
some narrow way. We should define the GUI behavior (user interaction) and design
ways to invoke Emacs functions or objects such as bookmarks, but we should not
otherwise define what tabs actually do when you click them, beyond invoking some
arbitrary (Emacs-Lisp) thingy.

In general, I suggest that we look to things like bookmarks for examples of the
kinds of things we might want to be able to do with tabs. That will help us
avoid limiting the design of Emacs tabs unnecessarily. When looking for models
on which to base our design, we should think of other thingies in Emacs (such as
bookmarks), and not just think of other uses of tabs in existing applications.

Yes, we do want to be able to do with Emacs tabs _at least_ the kinds of things
you can do with Eclipse tabs or Firefox tabs. But let's not limit our design
thinking to what you can do with tabs in other apps.

Dunno whether I was clear, and apologies for rambling a bit. The point is to
keep what tabs _do_ very general, regardless of how they're implemented or what
the user/GUI interaction will be like. And thinking of what bookmarks can do is
not a bad model for such generality. Being able to use existing bookmarks via
tabs would be one example of exploiting the generality that I hope tabs will
have.

[* http://www.emacswiki.org/emacs/BookmarkPlus]

Re: Gtk tabs in emacs, new branch.

[Juri Linkov]

> A bookmark is essentially a (persistent) named collection of info.
> That info typically includes a destination, which is typically a file
> location and a position within the file. But although that is
> typical, a bookmark need not be associated with any destination.

Let's compare how this is implemented in web browsers.  Typing C-b in
Firefox opens a left-side pane that indeed looks like a vertical tab bar.
But it has completely different semantics than the real tab bar.
Clicking on a bookmark opens a web page in a new tab.  Clicking on a tab
selects a web page in the existing tab.  So bookmarks are not a good example
what the tab bar could be used for.  I think in Emacs the most suitable
widget for that is the speed bar.

Of course, we could allow any action for tabs by design, but using them
for bookmarks is a bad idea.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: Gtk tabs in emacs, new branch.

[Drew Adams]

> > A bookmark is essentially a (persistent) named collection of info.
> > That info typically includes a destination, which is 
> > typically a file location and a position within the file. But
> > although that is typical, a bookmark need not be associated with
> > any destination.
> 
> Let's compare how this is implemented in web browsers.  Typing C-b in
> Firefox opens a left-side pane that indeed looks like a 
> vertical tab bar. But it has completely different semantics than the
> real tab bar.

I don't care about "real" tab bars or "real" Firefox bookmarks. I care about
what tabs will be in Emcs.

> Clicking on a bookmark opens a web page in a new tab.  
> Clicking on a tab selects a web page in the existing tab.

So what?

> So bookmarks are not a good example what the tab bar could
> be used for.

That doesn't follow at all. Anyway, please read what I wrote.

I said that I would like to be able to use tabs for the _kinds of things_ I use
Emacs bookmarks for - whether or not bookmarks are used as an intermediary. And
I gave examples of such diverse uses, which go far beyond the usual use of Emacs
bookmarks, not to mention even further beyond what one can use Firefox bookmarks
for.

I suggested thinking about such things in the interest of keeping the
model/design for Emacs tags open, general, flexible. The idea was to foster
thinking about what tabs can do and argue for keeping their use completely
flexible and general - that is, undefined.

In particular, I suggested separating a concern for implementation and
user-interaction design (GUI) from what tabs actually _do_, that is, what you
can do with them. 

I do not want Emacs design to hard-couple user-tab interaction (the GUI) with
any particular action to be effected by a tab. I want the possibilities for the
thingies that are selected or invoked by choosing a tab to remain open and
bindable at runtime (in Lisp). I want those thingies to be anything at all: a
window configuration, a desktop, a "project", a buffer, a mail, a process
invocation, or whatever.

I want a tab to be able to invoke any function whatever.

Define the GUI, fine (and I said that I probably have next to nothing to say
about that), but please let the mapping of tab<->thingie
selected/activated/invoked be open, not predefined.

As one instance of exploiting such hoped-for openness, I would like to be able
to attach/map-to/invoke a arbitrary Lisp function. Stefan spoke of commands -
via a keymap. As another instance, I suggested being able to attach an Emacs
bookmark. (No, not a Firefox bookmark, but a chunk of Emacs-Lisp that can
represent saved state and a handler function.)

So there were two different uses/mentions of bookmarks in what I wrote: (1)
bookmarks (in bookmark+) as a model or illustration of generality, to point out
some of the many different kinds of things one might like to do by clicking a
tab, and (2) invocation of existing Emacs bookmarks as one concrete example of
attaching a thingie to a tab - that is, bookmarks as one type of attachable
thingie.

The more important point is #1, by far: tabs should be able to do pretty much
anything.

If you don't in fact design them in such a way that I can directly map bookmarks
to tabs (#2), that's not a big deal. As long as I can hook/map a tab to an
arbitrary function, I can invoke a bookmark anyway (or anything else).

So perhaps reread my mail, concentrating on #1: bookmark uses as examples of
things one might want a tab to do. And forget about #2 if it adds confusion to
the discussion.

I'm OK with a hook, a handler, a keymap,...whatever (we can get to preferences
among those later). The point is simply *not* to hard-design tabs as *only*
selectors of window configs (or of any other specific thing). Do not predefine
what tabs do.

I wrote my mail in response to Jan's proposed implementation that I understand
(perhaps incorrectly) to hard-couple tabs to window configs. I do not want Emacs
tabs to be like that. I want them to be open.

> I think in Emacs the most suitable widget for that is the speed bar.
> 
> Of course, we could allow any action for tabs by design, but 
> using them for bookmarks is a bad idea.

Allow any action by design, yes. That was precisely the point.

I used different kinds of bookmarks (in bookmark+) as examples of different
kinds of things one might want to use tabs for. They were illustrations of why
tabs can be and should be more than simply window-selectors. Apparently, the
bookmark model as illustration was not clear.

Just please make sure we can attach an arbitrary function to a tab and I'll be a
happy camper, no doubt. A keymap, such as Stefan proposed, would be OK. A
function might be better. Allowing either would be good. Allowing a function,
keymap, or bookmark would be grand, but it's not necessary.

What I do not want to see is tabs being dedicated to *only* switching among X's,
where X is any single thing such as window configs, prohibiting the use of tabs
for Y's, where a Y is not an X.

Please do not predefine what tabs can do. Capice?

RE: Gtk tabs in emacs, new branch.

[Stephen J. Turnbull]

Drew Adams writes:

 > I want a tab to be able to invoke any function whatever.

While perhaps sufficient generality may require that ability, remember
that tabs as a metaphor are *not* just a contiguous row of buttons.
They are ordered, and they "do the same thing" (but to different
objects).  (There is an analogy to the difference between "a set of
check boxes" and "an array of radio buttons", where the radio buttons
aren't constrained to do the same thing, but rather to be mutually
exclusive.)

So I would refine "any function whatever" so that each tab control
should have a *single* callback function, which takes maybe three
arguments: the individual tab object itself (perhaps represented as an
integer but better a symbol, I think, because then you could put
properties on it), a per-tab user-defined datum (any Lisp object the
application wants to hang on the individual tab), and perhaps another
user-defined datum for the whole tab control.  (If you do need the
generality of function-per-tab, you could always have the tab-control-
wide function dispatch to per-tab functions stored in the per-tab user
datum.  This would *remind* you that all tabs in a group "should" do
the same thing, but it wouldn't *enforce* it.)

Either the per-tab datum or the whole-tab datum or both could be
subsumed by properties on the tab object, I guess.

WDYT?

RE: Gtk tabs in emacs, new branch.

[Drew Adams]

>  > I want a tab to be able to invoke any function whatever.
> 
> While perhaps sufficient generality may require that ability, remember
> that tabs as a metaphor are *not* just a contiguous row of buttons.
> They are ordered,

Yes.

> and they "do the same thing" (but to different objects).

How so?

> So I would refine "any function whatever" so that each tab control
> should have a *single* callback function, which takes maybe three
> arguments: the individual tab object itself (perhaps represented as an
> integer but better a symbol, I think, because then you could put
> properties on it), a per-tab user-defined datum (any Lisp object the
> application wants to hang on the individual tab), and perhaps another
> user-defined datum for the whole tab control.  (If you do need the
> generality of function-per-tab, you could always have the tab-control-
> wide function dispatch to per-tab functions stored in the per-tab user
> datum.  This would *remind* you that all tabs in a group "should" do
> the same thing, but it wouldn't *enforce* it.)
> 
> Either the per-tab datum or the whole-tab datum or both could be
> subsumed by properties on the tab object, I guess.
> 
> WDYT?

I'm not sure I understand all you wrote. I'm quite ignorant about much of this,
especially the how-to. My only ideas about this so far pertain to what tabs
might do and what kind of info might therefore be associated with them.

It's not clear to me, for example, what you mean by tabs (necessarily) doing the
same thing to different objects. It's also not clear why there should be a
single callback function, or what you mean by "the individual tab object" (what
is it for?) or "the whole tab control". What's the difference between the tab
and the whole tab?

Perhaps an example to illustrate, or define the terms a bit?

You click a given tab, and something happens. The tab has a name. The GUI/tab
control looks up the name to find the corresponding something-to-happen and then
effects it. Perhaps this is what you mean by "dispatch to per-tab functions
stored in the per-tab user datum" - dunno.

Yes, there is then some question about where to display things, if something
gets displayed as part of the something-to-happen. For example, if the action
involves visiting a buffer then you'd probably want that buffer to appear in a
window associated with the tab. 

I've said nothing about this display part of things. It is questions about
display that distinguish tabs from tool-bar buttons, no doubt. Yes, there is a
natural association between a tab and a window. That doesn't mean that every tab
need display exactly one window. But yes, clicking a tab typically results in
the window below it showing something that is associated with the tab.

Apart from the GUI aspects (including the display question), I see a tab bar as
an ordered sequence of named (Lisp) thingies that you can select (e.g. by
clicking). I therefore think of an alist, where the keys are the tab names and
the values are arbitrary Lisp objects.

That brings to mind an Emacs menu, where menu items are essentially alist
entries (item-name/key and command/value). Perhaps that's what Stefan had in
mind when he spoke of keymaps - dunno.

To me, it also brings to mind Emacs bookmarks, which is one reason I mentioned
them. A bookmark is just a cons (NAME . VALUE), where NAME is a string. It's
true that VALUE has an expected form to some extent for bookmarks, but really it
can be quite general. Predefined bookmark entries (in VALUE) such as `filename'
and `position' need not be mandatory. One important thing that VALUE can include
is a handler, which determines what happens when the bookmark is invoked.

Unlike the case for menus, the structure of the VALUE part of a bookmark is
quite flexible and open (e.g. to user definition), and the associated action
(handler) need not be an Emacs command (`interactive'). A default handler
applies, if none is present explicitly. To me, the bookmark model is quite
general and corresponds conceptually to a tab: a named Lisp value that can
represent some action to be performed when the tab is selected.

How a tab gets selected and what gets displayed (and how) are questions that I
haven't tried to address.

I mentioned that I would also like to be able to perform certain operations on
the tabs of a given tab bar that are similar to operations that I perform on a
list of bookmarks: (1) sort the tabs in various ways, based on both NAME and
VALUE, (2) mark the tabs and then perform operations on the marked tabs, (3)
hide certain tabs (e.g. those marked), (4) show a set of tabs that might not
already have been shown and then hidden (e.g. to "open" a project that involves
multiple tabs). And so on.

And I mentioned that (bookmark+) bookmarks can be tagged (del.icio.us-style),
which would mean that tabs would be tagged, so you could easily manipulate sets
of tabs - e.g. all the tabs that correspond to a particular project or query.

IOW, individual tabs can be selected, yes, but code (hence users) should also be
able to act on sets of tabs in various ways.

I'm thinking about tabs from a user point of view. Not just a user who clicks a
tab but also a user who might write some Lisp code to associate with a given
tab, to affect what happens when it is clicked.

Suppose, for illustration, that it would be sufficient to associate a given
existing bookmark with a given tab. The displayed tab name would be the bookmark
name. When you click the tab, the bookmark handler would be invoked, and
whatever destination is involved (if any) would be displayed (e.g. in the tab's
window).

When you invoke a bookmark normally (e.g. with `bookmark-jump') the handler is
invoked, and the handler typically includes a display function (e.g.
`pop-to-buffer'). What I envision for tabs is using the handler without its
display part. That is, suppress the display part of the bookmark handler and
substitute for it whatever display behavior we will define for tabs.

The bookmark handler would need to still visit the proper buffer (if it visits a
buffer), but not display that buffer. It is the tab code that would be in charge
of display, perhaps basing its behavior on the particular display function
defined for the handler. I haven't addressed the tab-display question, and I
probably don't have much to say about it.

What I'm concerned about is having the generality of associating an arbitrary
handler with each tab. And it would be very nice if we could leverage the
existing format of bookmarks in this regard - that is, be able to handle
existing bookmarks out of the box.

RE: Gtk tabs in emacs, new branch.

[Stephen J. Turnbull]

Drew Adams writes:

 > >  > I want a tab to be able to invoke any function whatever.
 > > 
 > > While perhaps sufficient generality may require that ability, remember
 > > that tabs as a metaphor are *not* just a contiguous row of buttons.
 > > They are ordered,
 > 
 > Yes.
 > 
 > > and they "do the same thing" (but to different objects).
 > 
 > How so?
 >
 > It's not clear to me, for example, what you mean by tabs
 > (necessarily) doing the same thing to different objects.

Those are scare quotes.  I wouldn't have quoted if I was able to
*define* "do the same thing"!

Let me start with some definitions: A *tab bar* (what in my previous
post I called a "tab control") is a widget which contains several
*tabs*, and (usually) a *pane* in which some kind of content is
displayed.  (In the implementation discussed below I assume the pane
is an Emacs window, but that need not be true.)  *Tabs* are clickable
buttons, but they only appear as part of a tab bar.  Within a tab bar,
there is a distinguished *top tab*.  In cases where the tabs control a
specific pane in the display, the top tab is the one associated with
the currently visible content.  Tabs may also be ordered from left to
right (assuming a horizontal orientation to avoid overloading the word
"top").  The top tab need not be leftmost, but is always visible and
visually distinguishable (unless the user has selected a weird face).

Clicking on an individual tab will cause some action to occur, usually
reflected by a change in the appearance of the content.  It always
causes the clicked tab to become the top tab.

 > Apart from the GUI aspects (including the display question), I see
 > a tab bar as an ordered sequence of named (Lisp) thingies that you
 > can select (e.g. by clicking). I therefore think of an alist, where
 > the keys are the tab names and the values are arbitrary Lisp
 > objects.

That's very adequately represented visually by a toolbar.  Why do you
want to duplicate the functionality of toolbars in tab bars?

 > Unlike the case for menus, the structure of the VALUE part of a
 > bookmark is quite flexible and open (e.g. to user definition), and
 > the associated action (handler) need not be an Emacs command
 > (`interactive'). A default handler applies, if none is present
 > explicitly. To me, the bookmark model is quite general and
 > corresponds conceptually to a tab: a named Lisp value that can
 > represent some action to be performed when the tab is selected.

"All hope abandon ye who enter here."  That's a toolbar.  (But I
repeat myself.  "What I say three times is true."  Wait for it!)  If
toolbars have the restrictions that menus do (which are hardly
restrictive, actually; anything that can take a function symbol as a
value can implement arbitrary behavior), you can bet that tabs will
suffer the same restrictions.

 > I mentioned that I would also like to be able to perform certain
 > operations on the tabs of a given tab bar that are similar to
 > operations that I perform on a list of bookmarks: (1) sort the tabs
 > in various ways, based on both NAME and VALUE, (2) mark the tabs
 > and then perform operations on the marked tabs, (3) hide certain
 > tabs (e.g. those marked), (4) show a set of tabs that might not
 > already have been shown and then hidden (e.g. to "open" a project
 > that involves multiple tabs). And so on.
 >
 > And I mentioned that (bookmark+) bookmarks can be tagged
 > (del.icio.us-style), which would mean that tabs would be tagged, so
 > you could easily manipulate sets of tabs - e.g. all the tabs that
 > correspond to a particular project or query.
 > 
 > IOW, individual tabs can be selected, yes, but code (hence users)
 > should also be able to act on sets of tabs in various ways.

Sure.  A tab bar will surely be visible to Lisp as a sequence of some
kind, and accessed by a variable.  I don't see why any of the things
you describe above will be prevented by any particular implementation
of the action invoked by a tab.

 > What I'm concerned about is having the generality of associating an
 > arbitrary handler with each tab.

That's a toolbar.  Q.E.D.

If you really really need both the visual cues provided by a tab bar,
and an arbitrary handler for each tab, then (using your alist
representation, which is probably as good as any other) you could have

(defun my-tab-handler (tab ignored-datum)    ; all tab handlers take 2 args
  (let ((name (nth 0 tab))
        (handler (nth 1 tab))
        (tab-data (nthcdr 2 tab)))
    (message "handling tab '%s'" name)
    (apply handler tab-data)))

as the handler, and the tab bar would be represented in Lisp as
something like

("This establishment serves only 17-year-old Scottish tabs." ; name/doc
 my-tab-handler
 (random)          ; random tab-bar-wide datum, not used by my-tab-handler
 ("One name"       handler-1   various data)
 ("Another name"   handler-2   some    information)
 ;; etc etc
 )

But in most cases, having tab-specific handlers is probably a bad fit
for the tab metaphor.  Use a toolbar.  If your problem with that is
that Emacs toolbars are too restrictive, then fix the restrictions.

OTOH, a typical over-simplified buffer tab bar would be handled by

(defun buffer-tab-handler (tab tab-controlled-window)
  (with-selected-window tab-controlled-window
    (switch-to-buffer (second tab))))

(defun make-buffer-tabs (how-many controlled-window)
  (let ((buffers (buffer-list))
        (tabs '(controlled-window buffer-tab-handler "buffer tab")))
    (while (and buffers (> how-many 0))
      (setq tabs (cons (list (buffer-name (car buffers)) (car buffers))
                       tabs))
      (setq how-many (1- how-many))
      (setq buffers (cdr buffers)))
    (reverse tabs)))