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

RE: Gtk tabs in emacs, new branch.

[grischka]

 > It's not clear to me, for example, what you mean by tabs (necessarily)
 > doing the same thing to different objects.

See, tabs are defined by their shape, more by their placement and
mostly by their action.  Which is to "switch content in the associated
window".  If it does not perform this action then it is not a tabs
control but just a row of buttons.

To give another example:  A scrollbar is defined mostly by its action
to "scroll content in the associated window".  Of course you could use
the scrollbar widget just as well to adjust your speaker volume, but
then it wouldn't be a scrollbar, even if it looked like one.

Aside from that it is completely unnecessary and boring to overload
widgets with alien functionality.  If for example you like to have
a row of buttons to switch color themes in the buffer, then well,
just use a row of (possibly colored) buttons.

--- grischka

Re: Gtk tabs in emacs, new branch.

[A. Soare]

I did understand what he did; I did the same 2 years ago, and gave up, because it is a rude method of implementing tabs for emacs in this manner.

I suggest you to do something like that:

opening a new tab, a function will initialize the structure of that tab.

For example, if you want a tab to represent a window-configuration, it will need an initialization function like that:

(let (new-tab (get-current-window-configuration))
     ...)

or , if you want the tab  to switch to *scratch* buffer,


(switch-to-buffer *scratch), etc

Every tab should have also a function of hide-event, in which it saves its old configuration, like

(setq new-tab (get-current-conf))

etc.


You might need a tab to represent a buffer of a compilation, or to start a compilation and switch to its buffer. In this case of use of a tab, you need no need of initializing a tab as a win-conf, etc.

It will be needed a local environment to a tab, such that the function associated to close/switch/hide be able to find the same new-tab variable, as initialized by init-function, and be hidden in other tabs, etc

I suggest you not to hurry to install the tabs as implemented by Jan D. Once installed, it might be difficult in future to switch to a nice implementation of tabs.

I have written the tabs for console, and if they are implemented as I like, I will send it when I have time.

Please, do not hurry to install such an implementation. Please improve it to accept lisp function for every gtk event, etc, before installing, and to suppose nothing about what a tab is.








____________________________________________________

 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.

[A. Soare]

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


Ok, good luck.



____________________________________________________

 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

[Angelo Graziosi]

Jan D. wrote:
> Hello.
>
>
> I've published a new branch...

I have build that, but when I start Emacs, I don't 'see' any tabs. How 
can we enable those? I have a desktop file which opens several file when 
I start Emacs, so I would expect to see them in tabs! :-)

Perhaps we need something like 'M-x tabs-mode' (by default possibly! :-))

When I use 'M-x tab-new', I see a single buffer in two tabs. After 
closing the tabs, switching buffer as usually, with mouse-1/-3 on mode 
line, Emas becomes very slow, perhaps it hangs...

Anyway, thanks a lot for this new 'era' in Emacs!

Ciao,
Angelo.

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Angelo Graziosi skrev 2010-04-01 18.52:
> Jan D. wrote:
>> Hello.
>>
>>
>> I've published a new branch...
>
> I have build that, but when I start Emacs, I don't 'see' any tabs. How
> can we enable those? I have a desktop file which opens several file when
> I start Emacs, so I would expect to see them in tabs! :-)

I don't think that is a good idea in general.  I have desktopfiles with over 
50 files.  50 tabs isn't manageable.

>
> Perhaps we need something like 'M-x tabs-mode' (by default possibly! :-))
>
> When I use 'M-x tab-new', I see a single buffer in two tabs.

Yes, it tries to do the same as C-x 5 2, i.e. show the buffer you came from.

> After
> closing the tabs, switching buffer as usually, with mouse-1/-3 on mode
> line, Emas becomes very slow, perhaps it hangs...

Hmm, I don't use the mode line to switch buffers, so I haven't seen that. 
I'll check it out.

	Jan D.

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

>> I have build that, but when I start Emacs, I don't 'see' any tabs. How
>> can we enable those? I have a desktop file which opens several file when
>> I start Emacs, so I would expect to see them in tabs! :-)
>
> I don't think that is a good idea in general.

If someone wants to do this, we could provide a variable `pop-up-tabs'
that is like `pop-up-frames'.

> I have desktopfiles with over 50 files.  50 tabs isn't manageable.

I think desktop.el should save and restore the tabs configurations,
i.e. in what tabs what buffers were displayed.

Is it currently possible to get a list of Gtk tabs and their
window configurations from Lisp?

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

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Juri Linkov skrev 2010-04-01 20.03:
>>> I have build that, but when I start Emacs, I don't 'see' any tabs. How
>>> can we enable those? I have a desktop file which opens several file when
>>> I start Emacs, so I would expect to see them in tabs! :-)
>>
>> I don't think that is a good idea in general.
>
> If someone wants to do this, we could provide a variable `pop-up-tabs'
> that is like `pop-up-frames'.

The idea has merit.
I still think we should have a limit on how many tabs that gets created 
automatically, for example by desktop.el.

>
>> I have desktopfiles with over 50 files.  50 tabs isn't manageable.
>
> I think desktop.el should save and restore the tabs configurations,
> i.e. in what tabs what buffers were displayed.
>
> Is it currently possible to get a list of Gtk tabs and their
> window configurations from Lisp?


Not presently.  I just added the bare minimum.  It is very easy to do though. 
  But in that case, tabs should be a proper lisp type, like windows.
Currently they aren't.

	Jan D.

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Jan Djärv skrev:
> 
> 
> Juri Linkov skrev 2010-04-01 20.03:
>>
>> Is it currently possible to get a list of Gtk tabs and their
>> window configurations from Lisp?
> 
> 
> Not presently.  I just added the bare minimum.  It is very easy to do 
> though. 

But for the purpose of saving stuff by desktop.el, window configrations aren't 
good.  You really can't do anything with them except restore them on the same 
running Emacs you saved them in.  The output from window-tree together with 
buffer information would be better.

And then there is frame-configuration which I haven't done anything to.

	Jan D.

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

Il 01/04/2010 19.45, Jan Djärv ha scritto:
>
>
> Angelo Graziosi skrev 2010-04-01 18.52:
>> Jan D. wrote:
>>> Hello.
>>>
>>>
>>> I've published a new branch...
>>
>> I have build that, but when I start Emacs, I don't 'see' any tabs. How
>> can we enable those? I have a desktop file which opens several file when
>> I start Emacs, so I would expect to see them in tabs! :-)
>
> I don't think that is a good idea in general. I have desktopfiles with
> over 50 files. 50 tabs isn't manageable.

Obviously (20 files in my case). Beside a minimum number, the tabs 
should be 'collapsed' with an 'arrow' pointing to the 'collapsing'.

Ciao,
Angelo.

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

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

Angelo Graziosi skrev:
> Il 01/04/2010 19.45, Jan Djärv ha scritto:
>>
>>
>> Angelo Graziosi skrev 2010-04-01 18.52:
>>> Jan D. wrote:
>>>> Hello.
>>>>
>>>>
>>>> I've published a new branch...
>>>
>>> I have build that, but when I start Emacs, I don't 'see' any tabs. How
>>> can we enable those? I have a desktop file which opens several file when
>>> I start Emacs, so I would expect to see them in tabs! :-)
>>
>> I don't think that is a good idea in general. I have desktopfiles with
>> over 50 files. 50 tabs isn't manageable.
> 
> Obviously (20 files in my case). Beside a minimum number, the tabs 
> should be 'collapsed' with an 'arrow' pointing to the 'collapsing'.
> 

I don't know exactly what you mean by collapsed, but Gtk+ adds arrows on the 
sides when the tabs are too many to fit.  Not exactly pretty, but it works.

	Jan D.


[-- Attachment #2: tabs2.png --]
[-- Type: image/png, Size: 26309 bytes --]

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

Il 02/04/2010 8.49, Jan Djärv ha scritto:

> I don't know exactly what you mean by collapsed, but Gtk+ adds arrows on
> the sides when the tabs are too many to fit.

Exactly that! :-)

Ciao,
Angelo.

Re: Gtk tabs in emacs, new branch

[Stephen J. Turnbull]

Jan Djärv writes:

 > > I have build that, but when I start Emacs, I don't 'see' any tabs. How
 > > can we enable those? I have a desktop file which opens several file when
 > > I start Emacs, so I would expect to see them in tabs! :-)
 > 
 > I don't think that is a good idea in general.  I have desktopfiles with over 
 > 50 files.  50 tabs isn't manageable.

XEmacs's tabs by default group files by mode (cc-mode, make-mode,
LaTeX-mode), and the tabs list the top N according to "buffer-list".
I *do not* think this is optimal, and wrote a proof-of-concept
"group-by-project" mode.  Nobody uses that, everybody uses the default
mode, and nobody complains (although people typically respond
enthusiastically when somebody suggests alternative uses of the tabs,
that itch has for some reason never been scratched despite
availability of proof-of-concept).

In XEmacs, buffer-list gives a frame-specific grouping, which works
well.

Bottom line: put a limit on the number of tabs, and use the first N in
buffer-list (perhaps filtered by mode).  This is good enough to start
with (Jan himself might opt to turn them off, but I bet most users
will find this mode a usability improvement).

You do need a way to turn off tabs, some people don't like them, some
app-specific frames shouldn't have them.

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Stephen J. Turnbull skrev:

> Bottom line: put a limit on the number of tabs, and use the first N in
> buffer-list (perhaps filtered by mode).  This is good enough to start
> with (Jan himself might opt to turn them off, but I bet most users
> will find this mode a usability improvement).
> 

I would use it, I use desktop files a lot, and having files in tabs when Emacs 
starts would be a bonus.  But for restoring desktop files, I'd rather have 
tabs on the N last visited files, i.e. from file-name-history.  That could be 
an option in desktop.el I guess.

> You do need a way to turn off tabs, some people don't like them, some
> app-specific frames shouldn't have them.

I didn't think of that, thanks.

	Jan D.

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Angelo Graziosi skrev:

> 
> When I use 'M-x tab-new', I see a single buffer in two tabs. After 
> closing the tabs, switching buffer as usually, with mouse-1/-3 on mode 
> line, Emas becomes very slow, perhaps it hangs...
> 

It may be timing related, I can't reproduce it.  Does it always happen?  Do 
you have a recepie for it?

	Jan D.

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

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

Il 02/04/2010 8.53, Jan Djärv ha scritto:
> Angelo Graziosi skrev:
>
>>
>> When I use 'M-x tab-new', I see a single buffer in two tabs. After
>> closing the tabs, switching buffer as usually, with mouse-1/-3 on mode
>> line, Emas becomes very slow, perhaps it hangs...
>>
>
> It may be timing related, I can't reproduce it. Does it always happen?
> Do you have a recepie for it?

At the moment, I can't reproduce too! So I haven't a clean recipe.

By the way, I want to flag that on Cygwin, the active tab shows a sort 
of 'focus' rectangle which should not be expected (see 'sp_test.f90' in 
the attached figure).

Any way, as I wrote, we need a 'M-x tabs-mode', perhaps *not* by default 
if you prefer, but that we can customize in the .emacs file.

Another thing. Clicking on the tab's 'X', should not close the file? It 
deletes only the tab, the buffer being still 'visited' by Emacs. (I do 
not remember a similar behavior with other applications using tabs.)

Ciao,
Angelo.

[-- Attachment #2: cygtest.png --]
[-- Type: image/png, Size: 29793 bytes --]

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Angelo Graziosi skrev:
> Il 02/04/2010 8.53, Jan Djärv ha scritto:
>> Angelo Graziosi skrev:
>>
>>>
>>> When I use 'M-x tab-new', I see a single buffer in two tabs. After
>>> closing the tabs, switching buffer as usually, with mouse-1/-3 on mode
>>> line, Emas becomes very slow, perhaps it hangs...
>>>
>>
>> It may be timing related, I can't reproduce it. Does it always happen?
>> Do you have a recepie for it?
> 
> At the moment, I can't reproduce too! So I haven't a clean recipe.
> 
> By the way, I want to flag that on Cygwin, the active tab shows a sort 
> of 'focus' rectangle which should not be expected (see 'sp_test.f90' in 
> the attached figure).

It is a Gtk+ thing (i.e. focus border).  I have pushed a new version that 
doesn't have it.  For other additions, see README.TABS th the root of the tree.

> 
> Any way, as I wrote, we need a 'M-x tabs-mode', perhaps *not* by default 
> if you prefer, but that we can customize in the .emacs file.

I'm not sure if it is a mode.  It is kind of outside that.
You can now disable tab creation entirely by specifying disable-tabs in frame 
parameters at frame creation.

> 
> Another thing. Clicking on the tab's 'X', should not close the file? It 
> deletes only the tab, the buffer being still 'visited' by Emacs. (I do 
> not remember a similar behavior with other applications using tabs.)

I don't think so.  After all, closing a frame doesn't close files.  The file 
may still be visible in other frames or tabs.

	Jan D.

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

Il 02/04/2010 17.10, Jan Djärv ha scritto:
> Angelo Graziosi skrev:
>> Any way, as I wrote, we need a 'M-x tabs-mode', perhaps *not* by
>> default if you prefer, but that we can customize in the .emacs file.
>
> I'm not sure if it is a mode. It is kind of outside that.
> You can now disable tab creation entirely by specifying disable-tabs in
> frame parameters at frame creation.

What I want to say is that we need a sort of option (customizable in 
.emacs or reaching it in the Options menu) that show/hide tabs, 
likewise, if you prefer, the option which show/hide the scroll bar.

Perhaps I am missing something: If I have many buffers, HOW can I see 
them in tabs? I do not want each time: M-x tab-new, mouse-3,...

We need also that restarting Emacs, desktop will be restored with all 
the tabs of previous session.

Thanks,
Angelo.

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

Still some observation...

Suppose one starts Emacs, a single frame with 38 lines (Emacs.geometry: 
80x40-0+0 in .Xdefaults, for example). Now suppose one creates some 
tabs: M-x tab-new. The lines now are 37 because one line is that of tabs 
and the frame has the same size (height). If, now, one deletes the tabs, 
the lines remain at 37 but the frame has the height shorter by one line. 
Repeating this procedure the lines become 36, 35,... and the frame 
shorter, shorter...

Is this to be the right thing? My opinion is that the frame should have 
always the same height and the line should be 38 (N) or 37 (N-1) if the 
tabs are visible.

Ciao,
Angelo.

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Angelo Graziosi skrev:
> Still some observation...
> 
> Suppose one starts Emacs, a single frame with 38 lines (Emacs.geometry: 
> 80x40-0+0 in .Xdefaults, for example). Now suppose one creates some 
> tabs: M-x tab-new. The lines now are 37 because one line is that of tabs 
> and the frame has the same size (height). If, now, one deletes the tabs, 
> the lines remain at 37 but the frame has the height shorter by one line. 
> Repeating this procedure the lines become 36, 35,... and the frame 
> shorter, shorter...
> 
> Is this to be the right thing? My opinion is that the frame should have 
> always the same height and the line should be 38 (N) or 37 (N-1) if the 
> tabs are visible.

Emacs tries to keep the frame size so an integral number of lines just fits. 
But tabs aren't (in general) exactly one or two lines high, so some resize 
will occur.  I made some fix.

I also made tab-mode a minor mode so it can be turned off by customize.

	Jan D.

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

Il 10/04/2010 14.44, Jan Djärv ha scritto:
> Angelo Graziosi skrev:
>> Still some observation...
>>
>> Suppose one starts Emacs, a single frame with 38 lines
>> (Emacs.geometry: 80x40-0+0 in .Xdefaults, for example). Now suppose
>> one creates some tabs: M-x tab-new. The lines now are 37 because one
>> line is that of tabs and the frame has the same size (height). If,
>> now, one deletes the tabs, the lines remain at 37 but the frame has
>> the height shorter by one line. Repeating this procedure the lines
>> become 36, 35,... and the frame shorter, shorter...
>>
>> Is this to be the right thing? My opinion is that the frame should
>> have always the same height and the line should be 38 (N) or 37 (N-1)
>> if the tabs are visible.
>
> Emacs tries to keep the frame size so an integral number of lines just
> fits. But tabs aren't (in general) exactly one or two lines high, so
> some resize will occur. I made some fix.
>
> I also made tab-mode a minor mode so it can be turned off by customize.

Good to hear! but I can't yet test it because bootstrapping rev. 99648 
(gtk-tabs branch) fails as follows:

[...]
make[3]: Entering directory `/tmp/emacs-gtk-tabs/build/lisp'
Compiling /tmp/emacs/src/../lisp/term/w32-win.el
Compiling /tmp/emacs/src/../lisp/emacs-lisp/easymenu.el
Wrote /tmp/emacs/lisp/term/w32-win.elc
Wrote /tmp/emacs/lisp/emacs-lisp/easymenu.elc
make[3]: Leaving directory `/tmp/emacs-gtk-tabs/build/lisp'
make[3]: Leaving directory `/tmp/emacs-gtk-tabs/build/lisp'
rm -f ../etc/DOC
../lib-src/make-docfile -d /tmp/emacs/src dosfns.o msdos.o xterm.o 
xfns.o[...]
/lisp/jka-cmpr-hook.elc ../lisp/ediff-hook.elc ../lisp/epa-hook.elc 
../lisp/widget.elc ../lisp/window.elc ../lisp/version.el
LC_ALL=C `/bin/pwd`/temacs -batch -l loadup dump
Loading loadup.el (source)...
Using load-path (/tmp/emacs/lisp)
Loading emacs-lisp/byte-run...
Loading emacs-lisp/backquote...
Loading subr...
Loading version.el (source)...
[...]
Loading tool-bar...
Loading font-setting...
Loading native-tabs.el (source)...
Attempt to autoload define-minor-mode while preparing to dump
make[2]: *** [emacs.exe] Error 255
make[2]: Leaving directory `/tmp/emacs-gtk-tabs/build/src'
make[1]: *** [src] Error 2
make[1]: Leaving directory `/tmp/emacs-gtk-tabs/build'
make: *** [bootstrap] Error 2

This happens both on GNU/Linux Kubuntu 9.10 and on Cygwin. in the same 
manner.


Ciao,
Angelo.

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Angelo Graziosi skrev:
> Loading native-tabs.el (source)...
> Attempt to autoload define-minor-mode while preparing to dump
> make[2]: *** [emacs.exe] Error 255
> make[2]: Leaving directory `/tmp/emacs-gtk-tabs/build/src'
> make[1]: *** [src] Error 2
> make[1]: Leaving directory `/tmp/emacs-gtk-tabs/build'
> make: *** [bootstrap] Error 2
> 
> This happens both on GNU/Linux Kubuntu 9.10 and on Cygwin. in the same 
> manner.

Hmm, I have pushed a new version where the autoload is removed.  The problem 
is, then C-h f tab-mode doesn't show anything.

Anybody knows why this happens?

	Jan D.

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

Il 10/04/2010 20.03, Jan Djärv ha scritto:
> Angelo Graziosi skrev:
>> This happens both on GNU/Linux Kubuntu 9.10 and on Cygwin. in the same
>> manner.
>
> Hmm, I have pushed a new version where the autoload is removed. The
> problem is, then C-h f tab-mode doesn't show anything.

I have tried also with rev. 99649, but same problem. :(

Angelo

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Did you make sure native-tabs.el is byte-compiled? Also do make clean  
and then make again.

        Jan D.

11 apr 2010 kl. 00.09 skrev Angelo Graziosi <angelo.graziosi@alice.it>:

> Il 10/04/2010 20.03, Jan Djärv ha scritto:
>> Angelo Graziosi skrev:
>>> This happens both on GNU/Linux Kubuntu 9.10 and on Cygwin. in the  
>>> same
>>> manner.
>>
>> Hmm, I have pushed a new version where the autoload is removed. The
>> problem is, then C-h f tab-mode doesn't show anything.
>
> I have tried also with rev. 99649, but same problem. :(
>
> Angelo
>
>

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

As I have flagged sometime on this list, I do ALWAYS clean build of 
Emacs, i.e. from a scratch tree not 'contaminated' by previous build. :-)

So, perhaps, that branch has other problems. For example,

$ grep native /tmp/emacs-gtk-tabs/src/Makefile.in

is empty in rev. 99648 and 99649.

The last useful build is with rev. 99645.

Ciao,
Angelo.


Il 11/04/2010 7.45, Jan Djärv ha scritto:
> Did you make sure native-tabs.el is byte-compiled? Also do make clean
> and then make again.
>
> Jan D.
>
> 11 apr 2010 kl. 00.09 skrev Angelo Graziosi <angelo.graziosi@alice.it>:
>
>> Il 10/04/2010 20.03, Jan Djärv ha scritto:
>>> Angelo Graziosi skrev:
>>>> This happens both on GNU/Linux Kubuntu 9.10 and on Cygwin. in the same
>>>> manner.
>>>
>>> Hmm, I have pushed a new version where the autoload is removed. The
>>> problem is, then C-h f tab-mode doesn't show anything.
>>
>> I have tried also with rev. 99649, but same problem. :(
>>
>> Angelo
>>
>>

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Angelo Graziosi skrev:
> As I have flagged sometime on this list, I do ALWAYS clean build of 
> Emacs, i.e. from a scratch tree not 'contaminated' by previous build. :-)
> 
> So, perhaps, that branch has other problems. For example,
> 
> $ grep native /tmp/emacs-gtk-tabs/src/Makefile.in
> 
> is empty in rev. 99648 and 99649.
> 
> The last useful build is with rev. 99645.
> 

Ah, so lisp files goes in there now, I didn't know.
I pushed a fix.

Thanks,

	Jan D.

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

Il 11/04/2010 12.52, Jan Djärv ha scritto:
> Angelo Graziosi skrev:
>> As I have flagged sometime on this list, I do ALWAYS clean build of
>> Emacs, i.e. from a scratch tree not 'contaminated' by previous build. :-)
>>
>> So, perhaps, that branch has other problems. For example,
>>
>> $ grep native /tmp/emacs-gtk-tabs/src/Makefile.in
>>
>> is empty in rev. 99648 and 99649.
>>
>> The last useful build is with rev. 99645.
>>
>
> Ah, so lisp files goes in there now, I didn't know.
> I pushed a fix.

Indeed, now it builds :-)

Observations: I see that in Options | Show/Hide Tabs are on by default 
(good!), but when I start Emacs I do not see any tabs. I still need 'M-x 
tab-new' to see some tab. I would expect that, if Tabs are on by 
default, starting Emacs shows desktop buffers in tabs, at least 
compatibly with the starting 'geometry' of Emacs.

So (sorry :( ), I still miss a short way to see desktop buffers in tabs. 
Probably, you are only thinking how to implement that...

Thanks for your efforts,
Angelo.

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Angelo Graziosi skrev:

> Indeed, now it builds :-)

Great.

> 
> Observations: I see that in Options | Show/Hide Tabs are on by default 
> (good!), but when I start Emacs I do not see any tabs. I still need 'M-x 
> tab-new' to see some tab. I would expect that, if Tabs are on by 
> default, starting Emacs shows desktop buffers in tabs, at least 
> compatibly with the starting 'geometry' of Emacs.
> 
> So (sorry :( ), I still miss a short way to see desktop buffers in tabs. 
> Probably, you are only thinking how to implement that...
> 

Yes.  A generic window configuration can be complex, and saving an reading 
that into a file isn't that easy.

	Jan D.

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

> Observations: I see that in Options | Show/Hide Tabs are on by default
> (good!), but when I start Emacs I do not see any tabs. I still need 'M-x
> tab-new' to see some tab. I would expect that, if Tabs are on by default,
> starting Emacs shows desktop buffers in tabs, at least compatibly with the
> starting 'geometry' of Emacs.

I implemented a new command line argument, so a command:

  emacs --tabs file1 file2 file3

will open each file in a new tab.  And

  emacsclient --create-tab

creates a new tab on the current Emacs frame.

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

Re: Gtk tabs in emacs, new branch

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>> Observations: I see that in Options | Show/Hide Tabs are on by default
>> (good!), but when I start Emacs I do not see any tabs. I still need 'M-x
>> tab-new' to see some tab. I would expect that, if Tabs are on by default,
>> starting Emacs shows desktop buffers in tabs, at least compatibly with the
>> starting 'geometry' of Emacs.
>
> I implemented a new command line argument, so a command:
>
>   emacs --tabs file1 file2 file3
>
> will open each file in a new tab.

That should be the default in a tab-capable Emacs when more than one
file is specified.

> And
>
>   emacsclient --create-tab
>
> creates a new tab on the current Emacs frame.

Again, I don't see a necessity for a new option.  If Emacs is configured
to open a new frame, all given files should appear in tabs of this
frame.  If not, all given files should appear in tabs in the existing
selected frame, in front of existing tabs.

-- 
David Kastrup

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

>>   emacs --tabs file1 file2 file3
>>
>> will open each file in a new tab.
>
> That should be the default in a tab-capable Emacs when more than one
> file is specified.

This seems better than splitting the window and displaying the
buffer list, as it currently does.  Tabs also have another
advantage: the startup screen is displayed in a separate tab,
so it does not interfere with editing input files.

But what if some users might prefer the old behavior?
Maybe to add a command line argument `--no-tabs'?

>>   emacsclient --create-tab
>>
>> creates a new tab on the current Emacs frame.
>
> Again, I don't see a necessity for a new option.  If Emacs is configured
> to open a new frame, all given files should appear in tabs of this
> frame.  If not, all given files should appear in tabs in the existing
> selected frame, in front of existing tabs.

Like Forefox having command line arguments `new-tab' and `new-window',
I think Emacs should allow the user to choose whether to display the
file in the selected window, a new frame or a new tab.

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

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

>> But what if some users might prefer the old behavior?
>> Maybe to add a command line argument `--no-tabs'?
>
> We could assume the user will always want the same, so we could give him
> some way to write down his preference in a file.  We could that
> "~/.emacs", for example.  WDYT?

Exactly like `pop-up-frames' defines whether `display-buffer'
should make a separate frame, a new implemented option `pop-up-tabs'
makes a separate tab when it is non-nil.  It can be defined in ~/.emacs.

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

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Juri Linkov skrev 2010-04-22 10.16:
>>> But what if some users might prefer the old behavior?
>>> Maybe to add a command line argument `--no-tabs'?
>>
>> We could assume the user will always want the same, so we could give him
>> some way to write down his preference in a file.  We could that
>> "~/.emacs", for example.  WDYT?
>
> Exactly like `pop-up-frames' defines whether `display-buffer'
> should make a separate frame, a new implemented option `pop-up-tabs'
> makes a separate tab when it is non-nil.  It can be defined in ~/.emacs.
>

What if both pop-up-tabs and pop-up-frames are set?

	Jan D.

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

>> Exactly like `pop-up-frames' defines whether `display-buffer'
>> should make a separate frame, a new implemented option `pop-up-tabs'
>> makes a separate tab when it is non-nil.  It can be defined in ~/.emacs.
>
> What if both pop-up-tabs and pop-up-frames are set?

Then pop-up-frames takes priority over pop-up-tabs and creates a new frame
(with a single tab in it).

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

Re: Gtk tabs in emacs, new branch

[Angelo Graziosi]

All is useful, but my opinion is that the main way should be something 
like 'M-x tabs-mode', so that one can visit buffers in tabs in a fast way.

Usually I start Emacs with a link on desktop...

Thanks,
Angelo.


Il 21/04/2010 10.55, Juri Linkov ha scritto:
>> Observations: I see that in Options | Show/Hide Tabs are on by default
>> (good!), but when I start Emacs I do not see any tabs. I still need 'M-x
>> tab-new' to see some tab. I would expect that, if Tabs are on by default,
>> starting Emacs shows desktop buffers in tabs, at least compatibly with the
>> starting 'geometry' of Emacs.
>
> I implemented a new command line argument, so a command:
>
>    emacs --tabs file1 file2 file3
>
> will open each file in a new tab.  And
>
>    emacsclient --create-tab
>
> creates a new tab on the current Emacs frame.
>

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

I also implemented C functions to save window configurations
in Lisp expressions that could be used later to save tabs
in the desktop file.  For example,

(current-window-configuration-to-sexp)
=>
(window-configuration
 (frame-cols . 80)
 (frame-lines . 41)
 (frame-menu-bar-lines . 1)
 (frame-tool-bar-lines . 4)
 (frame-tab-bar-lines . 4)
 (current-buffer . "*scratch*")
 (minibuf-scroll-window)
 (minibuf-selected-window)
 (saved-windows
  . (saved-window
     (current-window . t)
     (buffer . "*scratch*")
     (left-col . 0)
     (top-line . 5)
     (total-cols . 86)
     (total-lines . 35)
     (hscroll . 0)
     (min-hscroll . 0)
     (display-table)
     (orig-top-line)
     (orig-total-lines)
     (left-margin-cols)
     (right-margin-cols)
     (left-fringe-width)
     (right-fringe-width)
     (fringes-outside-margins)
     (scroll-bar-width)
     (vertical-scroll-bar-type . t)
     (dedicated)
     (resize-proportionally)
     (pointm . 236)
     (start . 1)
     (start-at-line-beg . t)
     (mark . 192)
     (next
      . (saved-window
         (buffer . " *Minibuf-0*")
         (left-col . 0)
         (top-line . 40)
         (total-cols . 86)
         (total-lines . 1)
         (hscroll . 0)
         (min-hscroll . 0)
         (display-table)
         (orig-top-line)
         (orig-total-lines)
         (left-margin-cols)
         (right-margin-cols)
         (left-fringe-width)
         (right-fringe-width)
         (fringes-outside-margins)
         (scroll-bar-width)
         (vertical-scroll-bar-type . t)
         (dedicated)
         (resize-proportionally)
         (pointm . 1)
         (start . 1)
         (start-at-line-beg))))))

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

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

This is good.  But I suspect the restore part is the more difficult work.

	Jan D.


Juri Linkov skrev 2010-04-21 17.45:
> I also implemented C functions to save window configurations
> in Lisp expressions that could be used later to save tabs
> in the desktop file.  For example,
>
> (current-window-configuration-to-sexp)
> =>
> (window-configuration
>   (frame-cols . 80)
>   (frame-lines . 41)
>   (frame-menu-bar-lines . 1)
>   (frame-tool-bar-lines . 4)
>   (frame-tab-bar-lines . 4)
>   (current-buffer . "*scratch*")
>   (minibuf-scroll-window)
>   (minibuf-selected-window)
>   (saved-windows
>    . (saved-window
>       (current-window . t)
>       (buffer . "*scratch*")
>       (left-col . 0)
>       (top-line . 5)
>       (total-cols . 86)
>       (total-lines . 35)
>       (hscroll . 0)
>       (min-hscroll . 0)
>       (display-table)
>       (orig-top-line)
>       (orig-total-lines)
>       (left-margin-cols)
>       (right-margin-cols)
>       (left-fringe-width)
>       (right-fringe-width)
>       (fringes-outside-margins)
>       (scroll-bar-width)
>       (vertical-scroll-bar-type . t)
>       (dedicated)
>       (resize-proportionally)
>       (pointm . 236)
>       (start . 1)
>       (start-at-line-beg . t)
>       (mark . 192)
>       (next
>        . (saved-window
>           (buffer . " *Minibuf-0*")
>           (left-col . 0)
>           (top-line . 40)
>           (total-cols . 86)
>           (total-lines . 1)
>           (hscroll . 0)
>           (min-hscroll . 0)
>           (display-table)
>           (orig-top-line)
>           (orig-total-lines)
>           (left-margin-cols)
>           (right-margin-cols)
>           (left-fringe-width)
>           (right-fringe-width)
>           (fringes-outside-margins)
>           (scroll-bar-width)
>           (vertical-scroll-bar-type . t)
>           (dedicated)
>           (resize-proportionally)
>           (pointm . 1)
>           (start . 1)
>           (start-at-line-beg))))))
>

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

> This is good.  But I suspect the restore part is the more difficult work.

Yes, the restore part is more difficult.  I've committed the initial workable
version of `set-window-configuration-from-sexp' to the x-tabs branch.
At least, it restores window configurations saved in another session.

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

Re: Gtk tabs in emacs, new branch

[Juanma Barranquero]

On Thu, Apr 22, 2010 at 10:14, Juri Linkov <juri@jurta.org> wrote:

> I've committed the initial workable
> version of `set-window-configuration-from-sexp' to the x-tabs branch.
> At least, it restores window configurations saved in another session.

This is generally useful, i.e., if it works it should perhaps go to the trunk.

    Juanma

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

>> I've committed the initial workable
>> version of `set-window-configuration-from-sexp' to the x-tabs branch.
>> At least, it restores window configurations saved in another session.
>
> This is generally useful, i.e., if it works it should perhaps go to the trunk.

Before moving it to the trunk, I'd like first to make sure that saving
tabs to the desktop works reliably.  For example, I realized that
functions `current-window-configuration-to-sexp' and
`set-window-configuration-from-sexp' are not suitable to save tabs
because their window configurations are kept in #<window-configuration>.

There should be another set of functions like
`(window-configuration-to-sexp #<window-configuration>)' and
`(window-configuration-from-sexp sexp)' that returns #<window-configuration>.
This means that the returned Lisp expression will contain a list of windows
(where `parent' and `prev' refer to the index of the window in this list)
instead of the window hierarchy.  Maybe this is a good thing.  E.g.

(window-configuration-to-sexp (current-window-configuration))
=>
(window-configuration
 (frame-cols . 196)
 (frame-lines . 77)
 (frame-menu-bar-lines . 1)
 (frame-tool-bar-lines . 4)
 (frame-tab-bar-lines . 0)
 (minibuf-scroll-window)
 (minibuf-selected-window)
 (saved-windows
  (window
   (left-col . 0)
   (top-line . 5)
   (total-cols . 202)
   (total-lines . 71)
   (hscroll . 0)
   (min-hscroll . 0)
   (display-table)
   (orig-top-line)
   (orig-total-lines)
   (left-margin-cols)
   (right-margin-cols)
   (left-fringe-width)
   (right-fringe-width)
   (fringes-outside-margins)
   (scroll-bar-width)
   (vertical-scroll-bar-type . t)
   (dedicated)
   (resize-proportionally))
  (window
   (parent . 0)
   (left-col . 0)
   (top-line . 5)
   (total-cols . 101)
   (total-lines . 71)
   (hscroll . 0)
   (min-hscroll . 0)
   (display-table)
   (orig-top-line)
   (orig-total-lines)
   (left-margin-cols)
   (right-margin-cols)
   (left-fringe-width)
   (right-fringe-width)
   (fringes-outside-margins)
   (scroll-bar-width)
   (vertical-scroll-bar-type . t)
   (dedicated)
   (resize-proportionally))
  (window
   (parent . 1)
   (buffer . "*scratch*")
   (left-col . 0)
   (top-line . 5)
   (total-cols . 101)
   (total-lines . 35)
   (hscroll . 0)
   (min-hscroll . 0)
   (display-table)
   (orig-top-line)
   (orig-total-lines)
   (left-margin-cols)
   (right-margin-cols)
   (left-fringe-width)
   (right-fringe-width)
   (fringes-outside-margins)
   (scroll-bar-width)
   (vertical-scroll-bar-type . t)
   (dedicated)
   (resize-proportionally))
  (window
   (parent . 1)
   (prev . 2)
   (buffer . "*Messages*")
   (left-col . 0)
   (top-line . 40)
   (total-cols . 101)
   (total-lines . 36)
   (hscroll . 0)
   (min-hscroll . 0)
   (display-table)
   (orig-top-line)
   (orig-total-lines)
   (left-margin-cols)
   (right-margin-cols)
   (left-fringe-width)
   (right-fringe-width)
   (fringes-outside-margins)
   (scroll-bar-width)
   (vertical-scroll-bar-type . t)
   (dedicated)
   (resize-proportionally))
  (window
   (parent . 0)
   (prev . 1)
   (buffer . "*info*")
   (left-col . 101)
   (top-line . 5)
   (total-cols . 101)
   (total-lines . 71)
   (hscroll . 0)
   (min-hscroll . 0)
   (display-table)
   (orig-top-line)
   (orig-total-lines)
   (left-margin-cols)
   (right-margin-cols)
   (left-fringe-width)
   (right-fringe-width)
   (fringes-outside-margins)
   (scroll-bar-width)
   (vertical-scroll-bar-type . t)
   (dedicated)
   (resize-proportionally))
  (window
   (prev . 0)
   (window . " *Minibuf-0*")
   (left-col . 0)
   (top-line . 76)
   (total-cols . 202)
   (total-lines . 1)
   (hscroll . 0)
   (min-hscroll . 0)
   (display-table)
   (orig-top-line)
   (orig-total-lines)
   (left-margin-cols)
   (right-margin-cols)
   (left-fringe-width)
   (right-fringe-width)
   (fringes-outside-margins)
   (scroll-bar-width)
   (vertical-scroll-bar-type . t)
   (dedicated)
   (resize-proportionally))))

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

RE: Gtk tabs in emacs, new branch

[Drew Adams]

> From: Juri Linkov
> I also implemented C functions to save window configurations
> in Lisp expressions that could be used later to save tabs
> in the desktop file.  For example,
> 
> (current-window-configuration-to-sexp)
> =>
> (window-configuration
>  (frame-cols . 80)
>  (frame-lines . 41)
>  (frame-menu-bar-lines . 1)
>  (frame-tool-bar-lines . 4)
>  (frame-tab-bar-lines . 4)
...

Is the intention to be able to save and restore all current window & frame
configurations?

That is what I would like to see, to be able to save and restore an Emacs state
as completely as possible wrt frames and windows.

[That would of course mean saving all frame parameters that can be restored. I
would even like to see the ability for users to hook into such a feature, so
that user-defined frame parameters could be handled also. E.g. for a
user-defined frame parameter `foo', a user could specify how it can be saved and
restored, so that frame-config saving & restoring would then DTRT wrt it.]

Lennart made a stab at saving/restoring frame and window configs, but his code
didn't work when I tested it (there were apparently some dependencies on his
EmacsW32 etc.). Perhaps you and he could put together something general. It
seems like you're both close.

I would like to see the ability to save & restore each of the following
independently, in such a way that you could use them separately or together (to
save and restore various combinations): desktops, window configs, frame configs.

IOW, we should not couple any of them in such a way that you could no longer
save only a desktop (without also saving frame configs) or only the current
frame & window configs, etc.  E.g., a saved desktop should not necessarily
include frame and window configs, but you should also be able to save all at
once.

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

> Is the intention to be able to save and restore all current window & frame
> configurations?

Yes, I've implemented the task to save and restore frame and
window configurations in the desktop file.

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

RE: Gtk tabs in emacs, new branch

[Drew Adams]

> > Is the intention to be able to save and restore all current 
> > window & frame configurations?
> 
> Yes, I've implemented the task to save and restore frame and
> window configurations in the desktop file.

Is this feature part of the 23-1-91 pretest or otherwise intended for 23.2? If
so, is it documented? If it's in the pretest I would like to try it.

Can users save such frame & window configs independently of desktops - and vice
versa? Can they save individual frame/window configs as well as all configs
together? See the rest of my previous mail.

A desktop saves some variables, buffers, etc. Users should be able to save just
frame/window state or just the vars+bufs state, as well as being able to save
everything together at once. It doesn't matter whether this new feature is in a
separate library (which might be more modular) or is in desktop.el, but
frame/window saving/restoration should be separable from the traditional use of
desktops to save/restore buffers and vars.

Also, desktop.el has a big limitation (which I would like to see removed): it
assumes only one desktop file per directory. I would not like to see such a
gross limitation extended to the saving and restoring of frame and window
configs. There is no reason for that.

Please see the rest of my previous mail. Can users hook into this to handle
user-defined frame parameters also? The feature should be open and not limited
to a predefined set of parameters.

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

>> Yes, I've implemented the task to save and restore frame and
>> window configurations in the desktop file.
>
> Is this feature part of the 23-1-91 pretest or otherwise intended for 23.2? If
> so, is it documented? If it's in the pretest I would like to try it.

This feature is part of the x-tabs branch.

> Can users save such frame & window configs independently of desktops - and vice
> versa? Can they save individual frame/window configs as well as all configs
> together?

If you want to save frame and window configurations independently of desktops,
you can easily do this using the same functions that desktop.el now uses.

> A desktop saves some variables, buffers, etc. Users should be able to save just
> frame/window state or just the vars+bufs state, as well as being able to save
> everything together at once.

There is a new variable `desktop-save-frame-configuration' that defines
whether to save frame and window configurations to the desktop.
It is nil by default.

> Also, desktop.el has a big limitation (which I would like to see removed): it
> assumes only one desktop file per directory.

It's a separate task to implement named desktops.

I imagine that named desktops should be an object above frames
in the hierarchy of screen objects:

 - desktop
  - frame
   - tab
    - window configuration
     - window

So switching desktops could be like switching frames:

  M-x select-desktop-by-name RET

will read a desktop name, delete old frames by calling `desktop-clear',
and create a new desktop by calling `desktop-read' with the selected name.

> Can users hook into this to handle user-defined frame parameters also?
> The feature should be open and not limited to a predefined set
> of parameters.

Yes, there is a new variable `desktop-frame-parameters-to-save'.

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

RE: Gtk tabs in emacs, new branch

[Drew Adams]

> > Can users save such frame & window configs independently of 
> > desktops - and vice versa? Can they save individual
> > frame/window configs as well as all configs
> > together?
> 
> If you want to save frame and window configurations 
> independently of desktops, you can easily do this using the
> same functions that desktop.el now uses.

So is that confirmation or not that one can save desktops without frame+win
configs and one can also save frame configs or window configs or both
independently of desktops (the traditional desktop info)?

And can users do that interactively out of the box, or are you saying only that
someone is free to create some user commands to do that using existing desktop
functions?

> > A desktop saves some variables, buffers, etc. Users should 
> > be able to save just frame/window state or just the
> > vars+bufs state, as well as being able to save
> > everything together at once.
> 
> There is a new variable `desktop-save-frame-configuration' 
> that defines whether to save frame and window configurations
> to the desktop. It is nil by default.

You don't also say that there is a way to save frame and window configs without
saving them to a desktop file. Or whether there is a way to save them without
also saving the other desktop info (buffers, vars etc.). 

It sounds like frame+win are optionally part of a desktop, but not the contrary
as well. That is different from them being separate things that can optionally
be combined.

I don't care much about the names - whether, for instance, "desktop" applies to
what it means now (buffers, vars, etc.) or it is changed to apply to everything,
including frames and windows. What I am concerned about is being able to easily
save & restore the different kinds of things separately.

> > Also, desktop.el has a big limitation (which I would like 
> > to see removed): it assumes only one desktop file per directory.
> 
> It's a separate task to implement named desktops.
> 
> I imagine that named desktops should be an object above frames
> in the hierarchy of screen objects:
>  - desktop - frame - tab - window configuration - window
> So switching desktops could be like switching frames:
>   M-x select-desktop-by-name RET
> will read a desktop name, delete old frames by calling 
> `desktop-clear', and create a new desktop by calling
> `desktop-read' with the selected name.

I do not really want to see desktops and frames coupled that way. Again, the
names don't matter to me much - what I want is to be able to save & restore such
different things together or separately.

I did not mention "named desktops". I asked to be able to have more than one
desktop file per directory. Currently, the desktop functions assume you can have
only one desktop file per dir.

I would like the basic desktop functions to accept an optional FILE arg that
tells them where the desktop file is. (If no such arg is passed, then they could
do as they do now: look to `desktop-dirname' to find the file.) That would
permit other code to pass a FILE arg to directly specify a desktop file to use.

I have desktop bookmarks, for instance. Because the desktop.el code does not
allow a caller to specify the file to use, my code jumps through a few extra
hoops.

Look at `desktop-change-dir' and `desktop-read'. They just change to the desktop
represented by a particular desktop file. But they assume one file per dir, so
they accept only a dir as arg. You would expect that you could explicitly pass a
desktop file to read, but you cannot.

The desktop.el code seems to be oriented toward a particular interaction between
users and its basic features. That's the problem, as I see it. It has general
features of saving and restoring a desktop to/from a file, but the functions
that perform those basic operations are cobbled by making them assume a
particular UI. That makes them less general (less useful) than they could be.

IOW, there is not enough separation between the basic desktop functions and the
UI that uses them - the UI design bleeds down into the basic functions
themselves.

We need not change the desktop UI. (But we could do that, to let users use
multiple files per dir interactively as well.) The basic desktop functions could
still assume that the desktop file they need is in the `desktop-dirname' dir by
default. All I'm suggesting is that these functions should allow an optional
parameter that provides the desktop file location. 

Other changes to the code (e.g. locking) might also be necessary to allow use of
multiple files per dir - dunno. I'm guessing that the reason behind the original
one-desktop-file-per-dir design had to do with locking (multiple users etc.). I
don't know what all might be involved in trying to remove this limitation (maybe
allow multiple lock files per dir?). For my use of desktop files for bookmarks,
I want to let users save desktop files anywhere, and I don't use the locking.

I brought up this point because you seem to be coupling persistence of frame and
window configs with desktop files - and hence extending the limitation of one
such file per dir to the new feature as well. That means users cannot have
multiple frame-config files per dir etc.

Don't get me wrong. I'm very glad you're working on this, and I don't pretend to
be an expert on desktops or the desktop.el code. I just would like things to be
modular - separable and combinable, and I would like the basic save-&-restore
functions to handle multiple state-saving files per dir.

> > Can users hook into this to handle user-defined frame 
> > parameters also? The feature should be open and not limited to
> > a predefined set of parameters.
> 
> Yes, there is a new variable `desktop-frame-parameters-to-save'.

Very good.

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

> And can users do that interactively out of the box, or are you saying
> only that someone is free to create some user commands to do that
> using existing desktop functions?

Sorry, this is too abstract and premature.  You are asking for
generalization, but there is nothing to generalize yet, because
even saving to the desktop file is not ready yet.  Please wait
until it's ready, try it and then come up with concrete propositions:
what additional functions do you need, etc.  Or help to finish the task
of saving to the desktop file.

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

RE: Gtk tabs in emacs, new branch

[Drew Adams]

> Sorry, this is too abstract and premature.  You are asking for
> generalization, but there is nothing to generalize yet, because
> even saving to the desktop file is not ready yet.  Please wait
> until it's ready, try it and then come up with concrete propositions:
> what additional functions do you need, etc.  Or help to 
> finish the task of saving to the desktop file.

I asked specific (not only abstract) questions about the _design_ of the new
feature you're proposing. You're telling me that you cannot discuss the design,
that I should just wait until the implementation is finished before raising
questions about what it should do. That's an "interesting" attitude.

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

> I asked specific (not only abstract) questions about the _design_ of
> the new feature you're proposing. You're telling me that you cannot
> discuss the design, that I should just wait until the implementation
> is finished before raising questions about what it should do.

Of course, you are welcome to discuss the design.  Currently the design
is at the stage of deciding what format is better to represent the
window configuration.  There are two options: a window tree and
a plain list of windows.  I am inclined to the second option
since when saved it would be more compact.

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

Re: Gtk tabs in emacs, new branch

[martin rudalics]

 > ... Currently the design
 > is at the stage of deciding what format is better to represent the
 > window configuration.  There are two options: a window tree and
 > a plain list of windows.  I am inclined to the second option
 > since when saved it would be more compact.

There's absolutely no need to make window configurations saved by
`current-window-configuration' (I call them CWCs here) and window
configurations saved for later reconstruction in a possibly different
session (called EWCs) save the same states of things.

CWCs are needed to restore the appearance of a frame after a short
excursion or because some error occurred.  They are heavily overused in
that respect (for example, every time you drag a window's modeline with
the mouse up or down by one line, Emacs saves and discards the current
window configuration twice) but certain aspects might be needed to keep
the appearance coherent like, for example, `hscroll' related entries.

EWCs should IMHO strip window configurations to the absolutely needed
bare minimum.  In particular `orig-top-line' and `orig-total-lines' do
more harm than good in EWCs (BTW, I've completely done away with these
in my rewrite of window.c) as all other minibuffer related information.
Also hscroll and min-hscroll should not be stored.

Whether margin, fringe and scrollbar information should be stored in
EWCs depends on whether the appropriate settings for frames and the
buffer local values are stored and orderly processed as well - otherwise
they make few sense.  I'm afraid we'd have to store/restore all of them,
although I'm also quite sure that hardly anyone could tell how their
final appearance on screen is determined.

Coordinates should probably be rather stored as fractions instead of
absolute lines and columns.  This would make it easier to (1) eventually
switch to pixel based coordinates and (2) put an EWC into an Emacs
window (that is, put an Emacs frame into an Emacs window) as some IDE
advocats mentioned earlier.

Since I suppose you're running `split-window' to restore configurations
you'd probably also want to remember whether a "split" was a vertical or
a horizontal one in EWCs.  Note that CWCs don't do this since they need
to restore the configuration from the stored "coordinates" anyway, but
the design is a bit awkward as code like

  if (EQ (p->total_cols, XWINDOW (w->parent)->total_cols))

in `set-window-configuration' shows.

That said, the *entire* coordinate information of a particular window in
an EWC would consist of (1) whether it is a horizontal or a vertical
combination and (2) the proportional space - either a float or the
fraction of "some largest integer" - occupied by the window wrt to its
parent window.  Anything else would be pure overkill.

BTW in the earlier example structure you posted here I'm missing entries
for window-point, window-start, ...  Was that intentional?

martin

Re: Gtk tabs in emacs, new branch

[Stefan Monnier]

> Loading native-tabs.el (source)...
> Attempt to autoload define-minor-mode while preparing to dump

Looks like src/Makefile forgot to byte-compile native-tabs.el before
dumping Emacs.


        Stefan

Re: Gtk tabs in emacs, new branch

[Uwe Siart]

Angelo Graziosi <angelo.graziosi@alice.it> writes:

> Clicking on the tab's 'X', should not close the file? It deletes only
> the tab, the buffer being still 'visited' by Emacs. (I do not remember
> a similar behavior with other applications using tabs.)

The behaviour of other applications is not necessarily a draft for
useful features. Emacs (luckily) has thousands of features where I do
not remember a similar behavior with other applications.

I would think of tabs as of a different kind of windows. In Emacs
closing a window and killing a buffer are distinct actions. Tabs should
behave the same.

-- 
Uwe

Re: Gtk tabs in emacs, new branch

[Daniel Colascione]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/2/10 12:19 PM, Uwe Siart wrote:
> Angelo Graziosi <angelo.graziosi@alice.it> writes:
> 
>> Clicking on the tab's 'X', should not close the file? It deletes only
>> the tab, the buffer being still 'visited' by Emacs. (I do not remember
>> a similar behavior with other applications using tabs.)
> 
> The behaviour of other applications is not necessarily a draft for
> useful features.

On the other hand, being gratuitously different will just alienate
users, especially new ones. When it comes to new users, programs aren't
judged by what they can be configured to do, but what they do by default.

> Emacs (luckily) has thousands of features where I do
> not remember a similar behavior with other applications.

Usually because Emacs predates these other applications.

> I would think of tabs as of a different kind of windows. In Emacs
> closing a window and killing a buffer are distinct actions. Tabs should
> behave the same.
> 

It seems the most natural thing to do is to kill the buffer iff the
window killed by closing a tab is the last window showing the given buffer.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)

iEYEARECAAYFAku2N/gACgkQ17c2LVA10VutbgCfTsOS+49V3Q4os2iYnEFsBaxj
IK0AoMsnz7j+iHJDTon45dws6pUNzf10
=Y1dV
-----END PGP SIGNATURE-----

Re: Gtk tabs in emacs, new branch

[Stefan Monnier]

> It seems the most natural thing to do is to kill the buffer iff the
> window killed by closing a tab is the last window showing the given buffer.

[ I mostly use one frame per buffer and indeed have such a key binding
to kill the buffer and the frame. ]
Doing it for the *Messages* buffer is a bad idea, in my experience.
In any case, this issue has nothing to do with tabs since it also
appears in many other contexts.


        Stefan

Re: Gtk tabs in emacs, new branch

[Uwe Siart]

Daniel Colascione <daniel@censorshipresearch.org> writes:

>> Emacs (luckily) has thousands of features where I do
>> not remember a similar behavior with other applications.
>
> Usually because Emacs predates these other applications.

This is a big advantage of Emacs over "these other applications".

> It seems the most natural thing to do is to kill the buffer iff the
> window killed by closing a tab is the last window showing the given
> buffer.

I disagree. Why should it be? In Emacs there can be buffers with
information that I need over and over again. But I don't want do kill
this information just because I don't need it in a window at the moment.

Your rationale is to disable Emacs because "modern applications" are
disabled and because "modern users" expect those disabilities.

-- 
Uwe

Re: Gtk tabs in emacs, new branch

[Uwe Siart]

Uwe Siart <usenet@siart.de> writes:

> I disagree. Why should it be? In Emacs there can be buffers with
> information that I need over and over again. But I don't want do kill
> this information just because I don't need it in a window at the moment.

What about making it customizable by a variable like
'close-last-tab-kills-buffer' that can be set to t or nil?

-- 
Uwe

Re: Gtk tabs in emacs, new branch

[Uwe Siart]

Angelo Graziosi <angelo.graziosi@alice.it> writes:

> Perhaps we need something like 'M-x tabs-mode' (by default possibly!
> :-))

Please don't enable such stuff by default. The user should be able to
decide by himself how many frames/windows/(tabs) he would like to open.

Also IMO tabs are not that useful as many (windows) users think because
there's only one tab visible at a time. Emacs' concept of frames and
windows (and iswitchb-mode) is much better here.

-- 
Uwe

Re: Gtk tabs in emacs, new branch

[Jan Djärv]

Uwe Siart skrev:
> Angelo Graziosi <angelo.graziosi@alice.it> writes:
> 
>> Perhaps we need something like 'M-x tabs-mode' (by default possibly!
>> :-))
> 
> Please don't enable such stuff by default. The user should be able to
> decide by himself how many frames/windows/(tabs) he would like to open.
> 
> Also IMO tabs are not that useful as many (windows) users think because
> there's only one tab visible at a time. Emacs' concept of frames and
> windows (and iswitchb-mode) is much better here.
> 

It depends.  Making many frames is no good if you don't have much screen space 
and want to view a large portion of your file.  Many windows also reduces the 
amount of text you can view at once.  Tabs have a role.  Consider the use case 
of viewing 3 or 4 log files with very long lines at once.  I currently do that 
by making Emacs fullscreen and switch buffers.  Having tabs for this would be 
a small improvement, as the tabs give the file name and makes for faster 
switching.  But I suspect long time Emacs users have developed habits that 
makes tabs less desirable.

An iswitcht-mode for tabs would probably be a good idea though.

	Jan D.

Re: Gtk tabs in emacs, new branch

[Juri Linkov]

> An iswitcht-mode for tabs would probably be a good idea though.

https://addons.mozilla.org/en-US/firefox/addon/3919

brings Emacs' iswitchb-mode to Firefox and back to Emacs :-)

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

Re: Gtk tabs in emacs, new branch

[Stephen J. Turnbull]

Uwe Siart writes:
 > Angelo Graziosi <angelo.graziosi@alice.it> writes:
 > 
 > > Perhaps we need something like 'M-x tabs-mode' (by default possibly!
 > > :-))
 > 
 > Please don't enable such stuff by default. The user should be able to
 > decide by himself how many frames/windows/(tabs) he would like to
 > open.

Opening many frames or windows is annoying to me, because I invariably
have too many open when I shut down for whatever reason. and they can
take up a lot of screen/frame real estate.  If I'm going to have tabs
for 99.9% of a session though, I'm just as happy having the tabs at
startup as long as the top tab is sane (typically defined as "the
selected tab in the selected frame at close-and-save time").  The
extra 1.5 or 2 lines of text is almost never an issue.

I think this is an even better candidate for "try as default and wait
for screams of pain" than delete-selection-mode.  People who hate it
will only have to turn it off once.  Many people who might love it
won't find out about it for years if it's not default.

BTW, at one time I had the same intuition you do.  Then XEmacs put in
tabs and enabled them by default.  What I discovered is that at
startup, the window I was working in *last* is a very good candidate
for top tab, and it's at the top of buffer-list.  What surprised me is
that the second-to-last window was typically not a good guess for the
second most important; rather it was often buried down the list at
fifth or sixth.  Tabs made it quite easy to find those precisely
because they're in-your-face.

iswitch and friends might make that advantage quite small for most
users; I don't know.  On the other hand, the actual cost is *very*
small if you're going to enable tabs anyway.

Gtk tabs in emacs, new branch.

[Jan Djärv]

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

Hello.

I've published a new branch (I hope, it is the first time I do this) that adds 
Gtk+ tabs to Emacs, it is at bzr.savannah.gnu.org/srv/bzr/emacs/gtk-tabs.

Tabs isn't visible internally, it looks like just one frame at the lisp level. 
    Window configurations are used when switching between tabs.  I think this 
may cause flicker on slower machines.  Making Emacs use Gtk+ double buffering 
here would help.  I may violate running Lisp from C restrictions here, but I 
am not sure.  Tabs most likely introduces new frame sizing errors.

The TODO file talks about tabs on each window.  To make this happen, at least 
for Gtk+, each window needs to be its own widget, instead of one widget per 
frame as we have now.  This is a bigger task.

You can drag tabs to reorder them, drop them on another frame to move it there
and drop on the root window to create a new frame.

The tabs themselves should be smaller IMHO, but the x to delete a tab makes 
them larger than the text.

Lisp code is in native-tabs.el.  Keybindings are:

       (global-set-key "\C-x7\C-f" 'find-file-new-tab)
       (global-set-key "\C-x70" 'tab-delete)
       (global-set-key "\C-x71" 'tab-delete-other)
       (global-set-key "\C-x72" 'tab-new)
       (global-set-key "\C-x7f" 'find-file-new-tab)
       (global-set-key "\C-x7o" 'tab-next)
       (global-set-key "\C-x7n" 'tab-next)
       (global-set-key "\C-x7p" 'tab-previous)))


The lisp interface is:

(find-file-new-tab (filename &optional wildcards)

Edit file FILENAME, in a new tab.

(tab-new &optional LABEL FRAME)

Create a new tab with label LABEL in frame FRAME.
If LABEL is nil, use current buffer name.
FRAME nil means use the selected frame.

Returns the key for the tab, which can be passed to `tab-delete'.

(tab-delete &optional KEY FRAME)

Remove tab KEY from frame FRAME.
KEY is what `tab-new' returned or nil, which means the current tab.
FRAME nil means use the selected frame.

(tab-delete-other &optional FRAME)

Remove all tabs from frame FRAME except the current one.
FRAME nil means use the selected frame.

(tab-set-label LABEL &optional FRAME)

Set label for the current tab in frame FRAME to LABEL.
LABEL nil means use current buffer name.
FRAME nil means use the selected frame.

(tab-next &optional FRAME)

Go to the next tab on frame FRAME.
Wrap around to the beginning if current tab is last.
FRAME nil means use the selected frame.

(tab-previous &optional FRAME)

Go to the previous tab on frame FRAME.
Wrap around to the end if current tab is first.
FRAME nil means use the selected frame.

I'm sure there are tons of bugs.  I have not compiled this tree for anything 
other than Gtk+.

	Jan D.


[-- Attachment #2: tabs.png --]
[-- Type: image/png, Size: 37832 bytes --]

Re: Gtk tabs in emacs, new branch.

[Leo]

On 2010-04-01 14:07 +0100, Jan Djärv wrote:
> I'm sure there are tons of bugs.  I have not compiled this tree for
> anything other than Gtk+.
>
> 	Jan D.

The screenshot looks very nice ;)

Leo

Re: Gtk tabs in emacs, new branch.

[Juri Linkov]

> I've published a new branch (I hope, it is the first time I do this) that
> adds Gtk+ tabs to Emacs,

Great!

> it is at bzr.savannah.gnu.org/srv/bzr/emacs/gtk-tabs.

Why the branch name is gtk-specific?

I've been thinking about merging the non-toolkit tabs,
but this branch name is too restrictive.

> The TODO file talks about tabs on each window.  To make this happen, at
> least for Gtk+, each window needs to be its own widget, instead of one
> widget per frame as we have now.  This is a bigger task.

Tabs on each window is what tabbar.el already does.  I'm not sure
if Gtk+ tabs are necessary for every window.  Maybe what's need is
to improve tabbar.el to use its own dedicated header window, because
currently it conflicts with modes that use the same single header line
(e.g. Info, proced, ruler-mode).

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

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Juri Linkov skrev 2010-04-01 20.02:
>> I've published a new branch (I hope, it is the first time I do this) that
>> adds Gtk+ tabs to Emacs,
>
> Great!
>
>> it is at bzr.savannah.gnu.org/srv/bzr/emacs/gtk-tabs.
>
> Why the branch name is gtk-specific?
>

Because it is an example of toolkit tabs, in this case very Gtk+ specific. 
Just to see how native toolkit tabs looks and behaves as opposed to for 
example tabbar.

> I've been thinking about merging the non-toolkit tabs,
> but this branch name is too restrictive.

Well, branches are easy with bzr, so just create your own :-).

>
>> The TODO file talks about tabs on each window.  To make this happen, at
>> least for Gtk+, each window needs to be its own widget, instead of one
>> widget per frame as we have now.  This is a bigger task.
>
> Tabs on each window is what tabbar.el already does.  I'm not sure
> if Gtk+ tabs are necessary for every window.  Maybe what's need is
> to improve tabbar.el to use its own dedicated header window, because
> currently it conflicts with modes that use the same single header line
> (e.g. Info, proced, ruler-mode).

I guess stuff like drag and drop for tabs don't work for tabbar?  That would 
be one difference if we where to mix the two.  I'll vote for either toolkit 
tabs or non-toolkit tabs, but not a mix.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Juri Linkov]

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

>> I've been thinking about merging the non-toolkit tabs,
>> but this branch name is too restrictive.
>
> Well, branches are easy with bzr, so just create your own :-).

I've published a new branch that implements tabs for non-toolkit X builds.
It is at bzr.savannah.gnu.org/srv/bzr/emacs/x-tabs.
The tab bar is modelled after the tool bar.  Tab functions share
some similarities with frame-, window- and buffer-related functions
(same name conventions, etc.)


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

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


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

RE: Gtk tabs in emacs, new branch.

[Drew Adams]

> >> I've been thinking about merging the non-toolkit tabs,
> >> but this branch name is too restrictive.
> >
> > Well, branches are easy with bzr, so just create your own :-).
> 
> I've published a new branch that implements tabs for 
> non-toolkit X builds.
> It is at bzr.savannah.gnu.org/srv/bzr/emacs/x-tabs.
> The tab bar is modelled after the tool bar.  Tab functions share
> some similarities with frame-, window- and buffer-related functions
> (same name conventions, etc.)

When describing such a feature, it would help to compare and contrast it with
tabbar.el, with which many people are familiar. Similarly, it would help to
compare it with tabs in other apps. 

At least at a summary level of description, to give an idea.

Re: Gtk tabs in emacs, new branch.

[Juri Linkov]

> When describing such a feature, it would help to compare and contrast
> it with tabbar.el, with which many people are familiar. Similarly, it
> would help to compare it with tabs in other apps.

I'm a big fan of the tabbed UI in different apps, mostly in web browsers
since mid-1990s.  This feature is a real efficiency booster that helps
to organize the workspace.

The most natural entity in Emacs to display in a tab would be a window
configuration.  Actually, something like this is already implemented in
Konqueror where you can split the window vertically/horizontally in a tab.
If you try it, you will understand how convenient it is.

In the screenshot I sent, you can see Back/Forward buttons that expose
in UI a useful feature existed for a long time in winner.el (currently
winner.el is not used directly since it should be modified to support tabs).
This will work like History Back/Forward buttons in web browsers.

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

Re: Gtk tabs in emacs, new branch.

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 10 Apr 2010 02:27:45 +0300, Juri Linkov <juri@jurta.org> said:

> I've published a new branch that implements tabs for non-toolkit X
> builds.  It is at bzr.savannah.gnu.org/srv/bzr/emacs/x-tabs.  The
> tab bar is modelled after the tool bar.  Tab functions share some
> similarities with frame-, window- and buffer-related functions (same
> name conventions, etc.)

The following patch will make a few things more consistent with my
2010-01-09 changes.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

=== modified file 'src/window.h'
*** src/window.h	2010-04-09 23:19:38 +0000
--- src/window.h	2010-04-10 01:34:30 +0000
***************
*** 415,425 ****
    (WINDOWP (WINDOW_XFRAME (W)->tool_bar_window) \
     && (W) == XWINDOW (WINDOW_XFRAME (W)->tool_bar_window))
  
  /* Return the frame y-position at which window W starts.
     This includes a header line, if any.  */
  
  #define WINDOW_TOP_EDGE_Y(W) \
!   (((WINDOW_MENU_BAR_P (W) || WINDOW_TOOL_BAR_P (W)) \
      ? 0 : FRAME_INTERNAL_BORDER_WIDTH (WINDOW_XFRAME (W))) \
     + WINDOW_TOP_EDGE_LINE (W) * WINDOW_FRAME_LINE_HEIGHT (W))
  
--- 415,431 ----
    (WINDOWP (WINDOW_XFRAME (W)->tool_bar_window) \
     && (W) == XWINDOW (WINDOW_XFRAME (W)->tool_bar_window))
  
+ /* 1 if W is a tab bar window.  */
+ 
+ #define WINDOW_TAB_BAR_P(W) \
+   (WINDOWP (WINDOW_XFRAME (W)->tab_bar_window) \
+    && (W) == XWINDOW (WINDOW_XFRAME (W)->tab_bar_window))
+ 
  /* Return the frame y-position at which window W starts.
     This includes a header line, if any.  */
  
  #define WINDOW_TOP_EDGE_Y(W) \
!   (((WINDOW_MENU_BAR_P (W) || WINDOW_TOOL_BAR_P (W) || WINDOW_TAB_BAR_P (W)) \
      ? 0 : FRAME_INTERNAL_BORDER_WIDTH (WINDOW_XFRAME (W))) \
     + WINDOW_TOP_EDGE_LINE (W) * WINDOW_FRAME_LINE_HEIGHT (W))
  
***************
*** 427,433 ****
     This includes a mode line, if any.  */
  
  #define WINDOW_BOTTOM_EDGE_Y(W) \
!   (((WINDOW_MENU_BAR_P (W) || WINDOW_TOOL_BAR_P (W)) \
      ? 0 : FRAME_INTERNAL_BORDER_WIDTH (WINDOW_XFRAME (W))) \
     + WINDOW_BOTTOM_EDGE_LINE (W) * WINDOW_FRAME_LINE_HEIGHT (W))
  
--- 433,439 ----
     This includes a mode line, if any.  */
  
  #define WINDOW_BOTTOM_EDGE_Y(W) \
!   (((WINDOW_MENU_BAR_P (W) || WINDOW_TOOL_BAR_P (W) || WINDOW_TAB_BAR_P (W)) \
      ? 0 : FRAME_INTERNAL_BORDER_WIDTH (WINDOW_XFRAME (W))) \
     + WINDOW_BOTTOM_EDGE_LINE (W) * WINDOW_FRAME_LINE_HEIGHT (W))
  

=== modified file 'src/xfns.c'
*** src/xfns.c	2010-04-09 23:19:38 +0000
--- src/xfns.c	2010-04-10 02:35:00 +0000
***************
*** 1540,1546 ****
      {
        int height = FRAME_INTERNAL_BORDER_WIDTH (f);
        int width = FRAME_PIXEL_WIDTH (f);
!       int y = nlines * FRAME_LINE_HEIGHT (f);
  
        /* height can be zero here. */
        if (height > 0 && width > 0)
--- 1540,1547 ----
      {
        int height = FRAME_INTERNAL_BORDER_WIDTH (f);
        int width = FRAME_PIXEL_WIDTH (f);
!       int y = (FRAME_MENU_BAR_LINES (f) + FRAME_TOOL_BAR_LINES (f)
! 	       + nlines) * FRAME_LINE_HEIGHT (f);
  
        /* height can be zero here. */
        if (height > 0 && width > 0)

=== modified file 'src/xterm.c'
*** src/xterm.c	2010-04-09 23:19:38 +0000
--- src/xterm.c	2010-04-10 02:31:59 +0000
***************
*** 751,761 ****
      {
        int y = WINDOW_TO_FRAME_PIXEL_Y (w, max (0, desired_row->y));
  
-       /* Internal border is drawn below the tab bar.  */
-       if (WINDOWP (f->tab_bar_window)
- 	  && w == XWINDOW (f->tab_bar_window))
- 	y -= width;
- 
        BLOCK_INPUT;
        x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f),
  		    0, y, width, height, False);
--- 751,756 ----

Re: Gtk tabs in emacs, new branch.

[Juri Linkov]

> The following patch will make a few things more consistent with my
> 2010-01-09 changes.

Thank you!  This branch was created before 2010-01-09, so I missed
your changes.  Now you patch is installed in the x-tabs branch.

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

Re: Gtk tabs in emacs, new branch.

[Chong Yidong]

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

> Tabs isn't visible internally, it looks like just one frame at the
> lisp level.  Window configurations are used when switching between
> tabs.  I think this may cause flicker on slower machines.  Making
> Emacs use Gtk+ double buffering here would help.  I may violate
> running Lisp from C restrictions here, but I am not sure.  Tabs most
> likely introduces new frame sizing errors.

I haven't had time to take a look at the implementation, but why do you
need to use window configurations?  It seems cleaner to treat each tab
as a separate frame, at both the C and Lisp levels.

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Chong Yidong skrev 2010-04-01 20.50:
> Jan Djärv<jan.h.d@swipnet.se>  writes:
>
>> Tabs isn't visible internally, it looks like just one frame at the
>> lisp level.  Window configurations are used when switching between
>> tabs.  I think this may cause flicker on slower machines.  Making
>> Emacs use Gtk+ double buffering here would help.  I may violate
>> running Lisp from C restrictions here, but I am not sure.  Tabs most
>> likely introduces new frame sizing errors.
>
> I haven't had time to take a look at the implementation, but why do you
> need to use window configurations?  It seems cleaner to treat each tab
> as a separate frame, at both the C and Lisp levels.
>

Yes, but that kind of requires modifications to almost all .c-files.  I just 
wanted something that does tabs like for example Firefox does.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Jan Djärv]

Chong Yidong skrev 2010-04-01 20.50:
> Jan Djärv<jan.h.d@swipnet.se>  writes:
>
>> Tabs isn't visible internally, it looks like just one frame at the
>> lisp level.  Window configurations are used when switching between
>> tabs.  I think this may cause flicker on slower machines.  Making
>> Emacs use Gtk+ double buffering here would help.  I may violate
>> running Lisp from C restrictions here, but I am not sure.  Tabs most
>> likely introduces new frame sizing errors.
>
> I haven't had time to take a look at the implementation, but why do you
> need to use window configurations?  It seems cleaner to treat each tab
> as a separate frame, at both the C and Lisp levels.
>

Yes, but that kind of requires modifications to almost all .c-files.  I just 
wanted something that does tabs like for example Firefox does.

	Jan D.

Re: Gtk tabs in emacs, new branch.

[Stefan Monnier]

> I haven't had time to take a look at the implementation, but why do you
> need to use window configurations?

FWIW, I think the link between TABs and their "meaning" (i.e. the
action to perform when one TAB is selected) should be in Elisp, and
using window-configs seem like a very natural choice.  Much more
lightweight that frames.


        Stefan "who thinks there's a continuum between tabs-on-frames
                and tabs-on-window, by allowing tabs at any level of the
                window tree".

Re: Gtk tabs in emacs, new branch.

[alin.s]

Jan Djärv wrote:
> 
> Hello.
> 
> I've published a new branch (I hope, it is the first time I do this) that
> adds 
> Gtk+ tabs to Emacs, it is at bzr.savannah.gnu.org/srv/bzr/emacs/gtk-tabs.
> 
> Tabs isn't visible internally, it looks like just one frame at the lisp
> level. 
>     Window configurations are used when switching between tabs.  I think
> this 
> may cause flicker on slower machines.  Making Emacs use Gtk+ double
> buffering 
> here would help.  I may violate running Lisp from C restrictions here, but
> I 
> am not sure.  Tabs most likely introduces new frame sizing errors.
> 
> The TODO file talks about tabs on each window.  To make this happen, at
> least 
> for Gtk+, each window needs to be its own widget, instead of one widget
> per 
> frame as we have now.  This is a bigger task.
> 
> You can drag tabs to reorder them, drop them on another frame to move it
> there
> and drop on the root window to create a new frame.
> 
> The tabs themselves should be smaller IMHO, but the x to delete a tab
> makes 
> them larger than the text.
> 
> Lisp code is in native-tabs.el.  Keybindings are:
> 
>        (global-set-key "\C-x7\C-f" 'find-file-new-tab)
>        (global-set-key "\C-x70" 'tab-delete)
>        (global-set-key "\C-x71" 'tab-delete-other)
>        (global-set-key "\C-x72" 'tab-new)
>        (global-set-key "\C-x7f" 'find-file-new-tab)
>        (global-set-key "\C-x7o" 'tab-next)
>        (global-set-key "\C-x7n" 'tab-next)
>        (global-set-key "\C-x7p" 'tab-previous)))
> 
> 
> The lisp interface is:
> 
> (find-file-new-tab (filename &optional wildcards)
> 
> Edit file FILENAME, in a new tab.
> 
> (tab-new &optional LABEL FRAME)
> 
> Create a new tab with label LABEL in frame FRAME.
> If LABEL is nil, use current buffer name.
> FRAME nil means use the selected frame.
> 
> Returns the key for the tab, which can be passed to `tab-delete'.
> 
> (tab-delete &optional KEY FRAME)
> 
> Remove tab KEY from frame FRAME.
> KEY is what `tab-new' returned or nil, which means the current tab.
> FRAME nil means use the selected frame.
> 
> (tab-delete-other &optional FRAME)
> 
> Remove all tabs from frame FRAME except the current one.
> FRAME nil means use the selected frame.
> 
> (tab-set-label LABEL &optional FRAME)
> 
> Set label for the current tab in frame FRAME to LABEL.
> LABEL nil means use current buffer name.
> FRAME nil means use the selected frame.
> 
> (tab-next &optional FRAME)
> 
> Go to the next tab on frame FRAME.
> Wrap around to the beginning if current tab is last.
> FRAME nil means use the selected frame.
> 
> (tab-previous &optional FRAME)
> 
> Go to the previous tab on frame FRAME.
> Wrap around to the end if current tab is first.
> FRAME nil means use the selected frame.
> 
> I'm sure there are tons of bugs.  I have not compiled this tree for
> anything 
> other than Gtk+.
> 
> 	Jan D.
> 
> 
>  
> 


Hi,


I worked on tabs, and after I did something general at C level, I realised
that I could have done better. Unfortunately, for now I cannot continue to
work on that, but I can do in in about 6 months. I can do the interface at C
level.

For me a tab will  be neither a window configuration, nor a frame, but it
will act according to an initialization function written in lisp. Every
event will have associated a script, like switch, etc. It is useful also for
me to insert an environment of tab-local variables.

In this manner, I could do it in 6 months for all.

If you work on tabs and install a definitive version, please tell me whether
it makes sense for me to implement my version in future, when I have time.




Alin




-- 
View this message in context: http://old.nabble.com/Gtk-tabs-in-emacs%2C-new-branch.-tp28108550p28188551.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Gtk tabs in emacs, new branch.

[Jan D.]

alin.s wrote:

> For me a tab will  be neither a window configuration, nor a frame, but it
> will act according to an initialization function written in lisp. Every
> event will have associated a script, like switch, etc. It is useful also for
> me to insert an environment of tab-local variables.

I don't know if we want tab-local variables. We had frame-local, but 
they are obsolete now.  You have to give a convincing reason for that 
and what an initialization function and script gives for advantages.

> 
> In this manner, I could do it in 6 months for all.
> 
> If you work on tabs and install a definitive version, please tell me whether
> it makes sense for me to implement my version in future, when I have time.
> 

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.