Re: Tabs are ready? -> Let us give a definition of tabs.

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

I propose you to give a general definition of a tab, otherwise it will be
disagreement between the tabs of GTK/motif/console , etc.

I propose you a defintion. In choosing a definition, one must agree first
of all on some

* general principles

** in C must be written as little as possible

** almost tab behaviour must be defined in elisp


Here what I propose:


The tabs should be a defined as a list of objects (of type 'tab) in the
struct frame.

On the frame, the tab is represented as a widget in GTK/motif/ , or
something similar in console.

A tab object should be defined as a list of association, in which every
standard event is associated with an elisp function. Apart from events, it
can be defined some constants, like tab-name, etc. It is useful to be able
to insert in this this other variables, that can be seen as tab-local.

The events should be:

 - create

     the elisp funciton is executed once, immediately after the
initialization of a tab

 - hide

    executed when the tab is hidden

 - show

    executed when we switch to that tab

etc.


Example: a tab that does nothing

To create a tab that does absolutely nothing, we define no elisp function
for all events.

After the creation of such a tab, it will be visible in gtk widget, but
commuting to it, nothing happens.

Other example: a tab that switches to a buffer assoc with a file, like
/root/.emacs

 - initialization event is defined so:

   -- erase all windows, and keep 1 window ( delete-other-windows )

   -- open the file . emacs

 - hide event

   -- memorize window configuration into a variable 'OLD-window-config
inserted in the assoc list of the tab

 - show event

  -- restaurate 'OLD-window-config

 - close event

  -- eventually kill the buffer .emacs


In this manner one can define tabs to run processes in background, like
compilations.

Etc.


I hope we could agree on such a definition of a tab.

I implemented it 2 years ago, and give a simple example , in which tabs
saves and restore window-configurations.

Note that it require not too much work at C level, and it gives a huge
number of possibilities of defining tabs, exactly as the 2 principles says.



Alin

[-- Attachment #2: Type: text/html, Size: 3237 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[martin rudalics]

 > The tabs should be a defined as a list of objects (of type 'tab) in the
 > struct frame.

Why do you want to introduce such a restriction?  If people want to
specify tabs on a window- or buffer-local basis they should be allowed
to do so.

 > Other example: a tab that switches to a buffer assoc with a file, like
 > /root/.emacs
 >
 >  - initialization event is defined so:
 >
 >    -- erase all windows, and keep 1 window ( delete-other-windows )

This is an example where frame-only tabs are hardly useful.  Switching
to a buffer should not delete other windows.

 >    -- memorize window configuration into a variable 'OLD-window-config
 > inserted in the assoc list of the tab

This is an example where associating tabs with frames seems useful.

 > Note that it require not too much work at C level, and it gives a huge
 > number of possibilities of defining tabs, exactly as the 2 principles says.

In which sense do your tabs differ from menu or toolbar elements?  You
can easily add a menu element to save the current window configuration
or pick one of a list of earlier saved configurations to restore that.

martin

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

> > The tabs should be a defined as a list of objects (of type 'tab) in the
> > struct frame.
>
> Why do you want to introduce such a restriction?  If people want to
> specify tabs on a window- or buffer-local basis they should be allowed
> to do so.
>
>
I did not think to this important aspect.



>
> > Other example: a tab that switches to a buffer assoc with a file, like
> > /root/.emacs
> >
> >  - initialization event is defined so:
> >
> >    -- erase all windows, and keep 1 window ( delete-other-windows )
>
> This is an example where frame-only tabs are hardly useful.  Switching
> to a buffer should not delete other windows.
>
>
This is how I defined the tab. If you do not want to delete a wndow, you
write a different elisp code.


>
> >    -- memorize window configuration into a variable 'OLD-window-config
> > inserted in the assoc list of the tab
>
> This is an example where associating tabs with frames seems useful.


This makes no sense alone ; it is in connection with the same tab .  This
is just other event for the same tab.




>
> > Note that it require not too much work at C level, and it gives a huge
> > number of possibilities of defining tabs, exactly as the 2 principles
> says.
>
> In which sense do your tabs differ from menu or toolbar elements?  You
> can easily add a menu element to save the current window configuration
> or pick one of a list of earlier saved configurations to restore that.
>
>
You cannot at all define menu or toolbar buttons which respond to standard
events , at which tab widgets shoud respond.


From what you say, it is worth seeing how to define the tabs as
tab-objects, as I said, such that they can be buffue-local when desired.

[-- Attachment #2: Type: text/html, Size: 2803 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[martin rudalics]

 > This makes no sense alone ; it is in connection with the same tab .  This
 > is just other event for the same tab.

What are the events you envision for one and the same tab ...

 >> In which sense do your tabs differ from menu or toolbar elements?  You
 >> can easily add a menu element to save the current window configuration
 >> or pick one of a list of earlier saved configurations to restore that.
 >>
 >>
 > You cannot at all define menu or toolbar buttons which respond to standard
 > events , at which tab widgets shoud respond.

... and what is a "standard event" in this context?  And why can a
toolbar button not react to such a standard event in the same way?

 >>From what you say, it is worth seeing how to define the tabs as
 > tab-objects, as I said, such that they can be buffue-local when desired.

And window-local.  I think that for two different windows the sets of
buffers you might want to switch to would differ according to the
buffers shown in the respective window before.

martin

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

> > This makes no sense alone ; it is in connection with the same tab .  This
> > is just other event for the same tab.
>
> What are the events you envision for one and the same tab ...
>
>
Almost the same events as the events the notebook widget of GTK responds.

Quite so, one cannot attach all events of gtk+.

In this case, the 'response' must be defined as a lambda.

What is to be done: to insert C code , minimally, that execute the events
when needed.

For console only, I did myself. For GTK and motif it should be even easier.



>
> >> In which sense do your tabs differ from menu or toolbar elements?  You
> >> can easily add a menu element to save the current window configuration
> >> or pick one of a list of earlier saved configurations to restore that.
> >>
> >>
> > You cannot at all define menu or toolbar buttons which respond to
> standard
> > events , at which tab widgets shoud respond.
>
> ... and what is a "standard event" in this context?  And why can a
> toolbar button not react to such a standard event in the same way?


Initialize tab, hide tab, show tab, kill tab, at least.





>
> >>From what you say, it is worth seeing how to define the tabs as
> > tab-objects, as I said, such that they can be buffue-local when desired.
>
> And window-local.  I think that for two different windows the sets of
> buffers you might want to switch to would differ according to the
> buffers shown in the respective window before.



Ya, right. A tab structure should be added alone , and a ponter to a such
tab struct must be present in every structure of frame, buffer, window.

[-- Attachment #2: Type: text/html, Size: 2512 bytes --]

Fwd: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

>
>
>> ... and what is a "standard event" in this context?  And why can a
>> toolbar button not react to such a standard event in the same way?
>
>
> Initialize tab, hide tab, show tab, kill tab, at least.
>


I think it should be evident why toolbar or menub cannot do it: because
there is no C code to call the events when needed.

[-- Attachment #2: Type: text/html, Size: 795 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

There is the conception of mozilla and many text editors that changing a
tab means to pass to other web page or other file to edit.

In Emacs, I propose , the behaviour of each event of a tab to be defined
using lisp functions, attached to the events that tab reponds to.

This does not mean necessarly only commuting to other buffer, or commuting
to other window; in order to make a tab that does such a commutation like
in other text editors,  particular lisp functions should be defined for the
events of that tab.

[-- Attachment #2: Type: text/html, Size: 662 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[Andy Moreton]

On Sun 05 Feb 2012, Alin Soare wrote:

> There is the conception of mozilla and many text editors that changing a
> tab means to pass to other web page or other file to edit.
>
> In Emacs, I propose , the behaviour of each event of a tab to be defined
> using lisp functions, attached to the events that tab reponds to.
>
> This does not mean necessarly only commuting to other buffer, or commuting
> to other window; in order to make a tab that does such a commutation like
> in other text editors,  particular lisp functions should be defined for the
> events of that tab.

Please give your proposed feature a different name. Given the existing
confusion between meaning of tab (hard tab characters vs. the TAB key),
adding more meanings for the word 'tab' will only add to the confusion.

Call your feature a tabbed-window or tabbed-frame, or anything else which is
distinct from 'tab' as this will avoid of lot of confusion for end users
trying to understand what is being discussed.

    AndyM

RE: Tabs are ready? -> Let us give a definition of tabs.

[Drew Adams]

> Please give your proposed feature a different name. Given the existing
> confusion between meaning of tab (hard tab characters vs. the 
> TAB key), adding more meanings for the word 'tab' will only add
> to the confusion.
> 
> Call your feature a tabbed-window or tabbed-frame, or 
> anything else which is distinct from 'tab' as this will avoid
> of lot of confusion for end users trying to understand what
> is being discussed.

+1 for the attempt, FWIW.

These things are called "tabs" by folks in general, but we do need a short way
to distinguish them from tab chars and the TAB key.

However, I'm not sure that "tabbed window" and "tabbed frame" are appropriate,
given the generality of these things (but I have not followed this discussion,
so maybe they are).  IIUC, the only thing we can really say about them to
distinguish them is that they are on a "tab bar", wherever that might be and
whatever any individual tabs on that bar might do.

One possibility, which is not very pretty but pretty much distinguishes these
tabs without committing to any particular uses, would be to call them "tabbar
tabs".  Just a suggestion.

RE: Tabs are ready? -> Let us give a definition of tabs.

[Stephen J. Turnbull]

Drew Adams writes:

 > One possibility, which is not very pretty but pretty much
 > distinguishes these tabs without committing to any particular uses,
 > would be to call them "tabbar tabs".  Just a suggestion.

Why not just call the feature the tab bar or tab control, avoiding
mention of the "tabs feature"?  Then the individual components can be
naturally called "tabs" when you need to refer to the GUI control that
gets clicked.

Re: Tabs are ready? -> Let us give a definition of tabs.

[martin rudalics]

 > There is the conception of mozilla and many text editors that changing a
 > tab means to pass to other web page or other file to edit.

What does "changing a tab" mean?  Do you mean pushing some graphical
object with the mouse or replacing one graphical object with another?

 > In Emacs, I propose , the behaviour of each event of a tab to be defined
 > using lisp functions, attached to the events that tab reponds to.

Can I transcribe this as "reacting to a tab event means to call a
function written in Elisp"?

 > This does not mean necessarly only commuting to other buffer, or commuting
 > to other window; in order to make a tab that does such a commutation like
 > in other text editors,  particular lisp functions should be defined for the
 > events of that tab.

Sure.  But any such function could be used in another context as well.
As mentioned before, we could easily add menu- or toolbar items which
stand for "saving the current window configuration" or "restoring a
previously saved window configuration".  I can neither see why such
actions should be exclusively tied to tabs nor why tabs are very suited
for them.

martin

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

> > There is the conception of mozilla and many text editors that changing a
> > tab means to pass to other web page or other file to edit.
>
> What does "changing a tab" mean?  Do you mean pushing some graphical
> object with the mouse or replacing one graphical object with another?


Yes. Not necessarily with the mouse. You can call a lisp function to
commute to a new tab. In firefox you can commute to the next tab using
C-PgDn .

Every time when you commute to a tab, the lisp function associated to the
'show event is called.


> > In Emacs, I propose , the behaviour of each event of a tab to be defined
> > using lisp functions, attached to the events that tab reponds to.
>
> Can I transcribe this as "reacting to a tab event means to call a
> function written in Elisp"?


Yes.

In graphical systems, like GTK, there is the concept of 'callback.

>
>
> > This does not mean necessarly only commuting to other buffer, or
> commuting
> > to other window; in order to make a tab that does such a commutation like
> > in other text editors,  particular lisp functions should be defined for
> the
> > events of that tab.
>
> Sure.  But any such function could be used in another context as well.
> As mentioned before, we could easily add menu- or toolbar items which
> stand for "saving the current window configuration" or "restoring a
> previously saved window configuration".  I can neither see why such
> actions should be exclusively tied to tabs nor why tabs are very suited
> for them.
>
>
Probably yes. But a toolbar button is not a tab. And do not forget that
toolbar does not exist in console.

In mozilla you can install lots of kind of bars. And there is no doubt that
the tabs are still useful. In mozilla the tabs are used for current-open
pages.

[-- Attachment #2: Type: text/html, Size: 2656 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[martin rudalics]

 >>> There is the conception of mozilla and many text editors that changing a
 >>> tab means to pass to other web page or other file to edit.
 >> What does "changing a tab" mean?  Do you mean pushing some graphical
 >> object with the mouse or replacing one graphical object with another?
 >
 >
 > Yes. Not necessarily with the mouse. You can call a lisp function to
 > commute to a new tab. In firefox you can commute to the next tab using
 > C-PgDn .

IIUC in firefox you have something like a "currently active tab" which
is higlighted and confers to the page currently shown in the firefox
frame.  In Emacs we can do something similar for tabs conferring to the
buffer currently shown in a window or the selected window.  Highlighting
the tab conferring to "save the current window configuration" doesn't
make much sense to me.  So if the last tab action we activated was such
a save we probably shouldn't highlight the associated tab.  But then
moving ("commuting") to the next tab will happen without visual feedback
from where we started moving.  Think of doing C-PgDn and the next tab is
a "restore window configuration" tab.

 > Every time when you commute to a tab, the lisp function associated to the
 > 'show event is called.

In firefox moving to the next tab means showing the associated page.
What is the 'show event for "restore window configuration"?

 > In mozilla you can install lots of kind of bars. And there is no doubt that
 > the tabs are still useful. In mozilla the tabs are used for current-open
 > pages.

And that's well-defined IMHO.  Doing something different might be
tricky.

martin

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

> >>> There is the conception of mozilla and many text editors that changing
> a
> >>> tab means to pass to other web page or other file to edit.
> >> What does "changing a tab" mean?  Do you mean pushing some graphical
> >> object with the mouse or replacing one graphical object with another?
> >
> >
> > Yes. Not necessarily with the mouse. You can call a lisp function to
> > commute to a new tab. In firefox you can commute to the next tab using
> > C-PgDn .
>
> IIUC in firefox you have something like a "currently active tab" which
> is higlighted and confers to the page currently shown in the firefox
> frame.  In Emacs we can do something similar for tabs conferring to the
> buffer currently shown in a window or the selected window.  Highlighting
>

This is one possibility.


> the tab conferring to "save the current window configuration" doesn't
> make much sense to me.  So if the last tab action we activated was such
> a save we probably shouldn't highlight the associated tab.  But then
> moving ("commuting") to the next tab will happen without visual feedback
> from where we started moving.  Think of doing C-PgDn and the next tab is
> a "restore window configuration" tab.


In order to be able to restore a window configuration you have to save it
first.



>
>
> > Every time when you commute to a tab, the lisp function associated to the
> > 'show event is called.
>
> In firefox moving to the next tab means showing the associated page.
> What is the 'show event for "restore window configuration"?


Restoring the saved window configuration, for example.




> > In mozilla you can install lots of kind of bars. And there is no doubt
> that
> > the tabs are still useful. In mozilla the tabs are used for current-open
> > pages.
>
> And that's well-defined IMHO.  Doing something different might be
> tricky.
>
>
Emacs-devel is created for people to talk and take a decision how to define
the tabs


Alin

[-- Attachment #2: Type: text/html, Size: 2993 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

>
>
>
> > This does not mean necessarly only commuting to other buffer, or
> commuting
> > to other window; in order to make a tab that does such a commutation like
> > in other text editors,  particular lisp functions should be defined for
> the
> > events of that tab.
>
> Sure.  But any such function could be used in another context as well.
> As mentioned before, we could easily add menu- or toolbar items which
> stand for "saving the current window configuration" or "restoring a
> previously saved window configuration".  I can neither see why such
> actions should be exclusively tied to tabs nor why tabs are very suited
> for them.
>
>
I give you an example that I would like to have in emacs.

I wish to be able define a tab that does so:


1. at initialization it starts a grep and looks for something in background
2. The 'show event should commute to the buffer *grep*
3. when grep finds something, and the tab is hidden , the tab widget to
change the color
4. The 'close event should kill the *grep* buffer, and the process , if it
had not finished yet


 Could you do this using buttons in toolbar or menubar, as you insist ?

[-- Attachment #2: Type: text/html, Size: 1614 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[martin rudalics]

 > 1. at initialization it starts a grep and looks for something in background

How do you communicate to the tab what the "something" is?

 > 2. The 'show event should commute to the buffer *grep*

This is the standard buffer switching functionality.

 > 3. when grep finds something, and the tab is hidden , the tab widget to
 > change the color

What sense does it make to have a hidden tab change color?  And what
kind of event is this in your nomenclature?

 > 4. The 'close event should kill the *grep* buffer, and the process , if it
 > had not finished yet

 >  Could you do this using buttons in toolbar or menubar, as you insist ?

So far I'd only insist that saving and restoring window configurations
should be done with the menubar rather than with a tab.  I never ever
use toolbars but I think that mail handling routines using the toolbar
(could) do such things routinely (inform of new mail, kill a buffer and
remove the associated button when mail has been sent , ...).

martin

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

2012/2/6 martin rudalics <rudalics@gmx.at>

> > 1. at initialization it starts a grep and looks for something in
> background
>
> How do you communicate to the tab what the "something" is?



execute 'grep -i foo *' in background , example




> > 2. The 'show event should commute to the buffer *grep*
>
> This is the standard buffer switching functionality.
>
>
I know how to commute a buffer. In this case of tab, I want the show event
to commute to a given buffer.


>
> > 3. when grep finds something, and the tab is hidden , the tab widget to
> > change the color
>
> What sense does it make to have a hidden tab change color?  And what
> kind of event is this in your nomenclature?
>
>
Tabs should register a callback for an event , for example, when i/o
arrives in  the given process...


>
> > 4. The 'close event should kill the *grep* buffer, and the process , if
> it
> > had not finished yet
>
> >  Could you do this using buttons in toolbar or menubar, as you insist ?
>
> So far I'd only insist that saving and restoring window configurations
> should be done with the menubar rather than with a tab.  I never ever
> use toolbars but I think that mail handling routines using the toolbar
> (could) do such things routinely (inform of new mail, kill a buffer and
> remove the associated button when mail has been sent , ...).
>
>
Why do you change the subject of discussion ? saving and restoring window
configurations concerns other type of tab, not this one I am talking here.



Quite so, you can do this functionality using only M-x and calling lisp
functions. Or menu entries. But I am sure most people would be happy to be
able to define a tab that shows a 'grep process.

[-- Attachment #2: Type: text/html, Size: 2841 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[Stephen J. Turnbull]

Alin Soare writes:

 > > > 3. when grep finds something, and the tab is hidden , the tab widget to
 > > > change the color
 > >
 > > What sense does it make to have a hidden tab change color?  And what
 > > kind of event is this in your nomenclature?

Alin, in English the physical metaphor that "tab" invokes refers to
the small piece of a folder or notebook divider that sticks out where
you can find it in a stack.  It specifically does *not* refer to the
content area that is linked with the tab.  So if the tab is hidden
(eg, by another row of tabs), you can't see it change color!  This
precise definition may be difficult to understand from the way native
speakers use the term, but I assure you your usage is confusing the
hell out of the native speakers here.

As well as some of the non-native speakers, as I presume Martin is.

 > Tabs should register a callback for an event , for example, when i/o
 > arrives in  the given process...

You're going around in circles.  Martin knows how events and callbacks
work.

 > Quite so, you can do this functionality using only M-x and calling lisp
 > functions. Or menu entries. But I am sure most people would be happy to be
 > able to define a tab that shows a 'grep process.

I doubt it.  In real life as defined in the English language, a tab is
a way to quickly find a flat object in a neat stack of flat objects of
similar size and shape, such as pages of an address book or file
folders in a file cabinet.  It is very similar to a bookmark (I mean
things the ribbon you find in a nicely bound book or some odd scrap of
paper, not the web browser sort), except that bookmarks are ad hoc and
tend to have no fixed relationship to the content that they mark,
while tabs are systematic, and have a fixed relationship to content.
Eg, a common tabbed object is an address book, and the tabs are small
areas that stick out, have labels such as "A", "B", "C", and the
related content is "names that start with A," and so on.  Another
example is a product manual divided into sections, such as the well
known Unix manual with "Commands", "OS entry points", "Standard
library", and so on.

In computers, because software is more dynamic than printed books
(even looseleaf notebooks), tabs tend to be more ad hoc.  Still,
they're really just glorified bookmarks, usually coming in sets with
some sort of relationship to each other.

So basically a tab control is just a set of windows (or frames) that
share the same screen real estate, with a visible but nonobtrusive GUI
to switch windows (frames) quickly.[1]

I can easily believe that *you* might use a tab to invoke a grep
process, and there's nothing wrong with that if you want that
.
However, that is not the way most people think of tabs.  Most people
would invoke the grep process with M-! or a menu item or maybe a
toolbar button, and then -- if the output was to be referred to
frequently -- they *might* use a tab to navigate to *Shell Command
Output* buffer that holds that output.  I doubt very many people would
find it natural to invoke commands with a tab.

In practice, the only things that a tab needs is a Lisp object to
represent it and to keep track of its screen real estate, and a small
API to control its appearance.  Everything else can be defined in
terms of existing Lisp primitives (eg, your grep example with the tab
changing color when the associated process buffer receives output
could be implemented with a process sentinel).


Footnotes: 
[1]  That's not 100% accurate, depending on how you think of GUI
window decorations etc, but it's close enough.

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

2012/2/6 Stephen J. Turnbull <stephen@xemacs.org>

> Alin Soare writes:
>
>  > > > 3. when grep finds something, and the tab is hidden , the tab
> widget to
>  > > > change the color
>  > >
>  > > What sense does it make to have a hidden tab change color?  And what
>  > > kind of event is this in your nomenclature?
>
> Alin, in English the physical metaphor that "tab" invokes refers to
> the small piece of a folder or notebook divider that sticks out where
> you can find it in a stack.  It specifically does *not* refer to the
> content area that is linked with the tab.  So if the tab is hidden
> (eg, by another row of tabs), you can't see it change color!  This
> precise definition may be difficult to understand from the way native
> speakers use the term, but I assure you your usage is confusing the
> hell out of the native speakers here.
>

In 'konsole of KDE there are tabs. In each such tab can e run a process
(not necessrily 'bash) .

In konsole, when a tab is hidden and its process gave output, the tab
changed the color.

The same happens to alll chat programs.





> As well as some of the non-native speakers, as I presume Martin is.
>
>  > Tabs should register a callback for an event , for example, when i/o
>  > arrives in  the given process...
>
> You're going around in circles.  Martin knows how events and callbacks
> work.
>
>  > Quite so, you can do this functionality using only M-x and calling lisp
>  > functions. Or menu entries. But I am sure most people would be happy to
> be
>  > able to define a tab that shows a 'grep process.
>
> I doubt it.  In real life as defined in the English language, a tab is
> a way to quickly find a flat object in a neat stack of flat objects of
> similar size and shape, such as pages of an address book or file
> folders in a file cabinet.  It is very similar to a bookmark (I mean
> things the ribbon you find in a nicely bound book or some odd scrap of
> paper, not the web browser sort), except that bookmarks are ad hoc and
> tend to have no fixed relationship to the content that they mark,
> while tabs are systematic, and have a fixed relationship to content.
> Eg, a common tabbed object is an address book, and the tabs are small
> areas that stick out, have labels such as "A", "B", "C", and the
> related content is "names that start with A," and so on.  Another
> example is a product manual divided into sections, such as the well
> known Unix manual with "Commands", "OS entry points", "Standard
> library", and so on.
>
> In computers, because software is more dynamic than printed books
> (even looseleaf notebooks), tabs tend to be more ad hoc.  Still,
> they're really just glorified bookmarks, usually coming in sets with
> some sort of relationship to each other.
>
> So basically a tab control is just a set of windows (or frames) that
> share the same screen real estate, with a visible but nonobtrusive GUI
> to switch windows (frames) quickly.[1]
>
> I can easily believe that *you* might use a tab to invoke a grep
> process, and there's nothing wrong with that if you want that
> .
> However, that is not the way most people think of tabs.  Most people
> would invoke the grep process with M-! or a menu item or maybe a
> toolbar button, and then -- if the output was to be referred to
> frequently -- they *might* use a tab to navigate to *Shell Command
> Output* buffer that holds that output.  I doubt very many people would
> find it natural to invoke commands with a tab.
>
> In practice, the only things that a tab needs is a Lisp object to
> represent it and to keep track of its screen real estate, and a small
> API to control its appearance.  Everything else can be defined in
> terms of existing Lisp primitives (eg, your grep example with the tab
> changing color when the associated process buffer receives output
> could be implemented with a process sentinel).
>


I propose to find a definition of tabs, such they are programmablem and
give whatever default behaviour of tabs you wish, give the LIBERTY to those
programmers who wish to define other kind of tabs for themselves, to be
able to do so.

[-- Attachment #2: Type: text/html, Size: 5150 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

I give you other example: the erc.

I wish every channel in erc to have its own tab, and when somebody writes
something, the tab of the given channel to change the color.

So, in Emacs we do not need tabs like in mozilla or something fixed.

We need _programmable_ tabs.

I think the method of callbacks could be applied to make such tabs.

[-- Attachment #2: Type: text/html, Size: 469 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[Stephen J. Turnbull]

Alin Soare writes:

 > I propose to find a definition of tabs,

We already have a definition of tabs: a GUI control containing a
linear array of buttons, each of which evokes a different display in a
single, fixed region of the screen, adjacent to the linear array.
This neither requires nor denies the kind of flexible programmability
you want.

 > such they are programmable, and give whatever default behaviour of
 > tabs you wish, give the LIBERTY to those programmers who wish to
 > define other kind of tabs for themselves, to be able to do so.

But this does not require all of the junk (events, callbacks, etc)
that you've talked about.  All that *needs* to be added to Emacs is
the very limited API needed to associate tabs with a window or frame,
displayable content and a label with each tab, and to query that
information.  The rest can be implemented with existing Emacs Lisp
facilities, such as faces (to change the color of a tab) and process
sentinels (one sort of event callback).  If you want a GTK-like API,
that should be easy to write in Lisp.

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

>
>
>
>  > such they are programmable, and give whatever default behaviour of
>  > tabs you wish, give the LIBERTY to those programmers who wish to
>  > define other kind of tabs for themselves, to be able to do so.
>
> But this does not require all of the junk (events, callbacks, etc)
> that you've talked about.  All that *needs* to be added to Emacs is
> the very limited API needed to associate tabs with a window or frame,
> displayable content and a label with each tab, and to query that
> information.  The rest can be implemented with existing Emacs Lisp
> facilities, such as faces (to change the color of a tab) and process
> sentinels (one sort of event callback).  If you want a GTK-like API,
> that should be easy to write in Lisp.
>
>
Without events, do you have a concrete idea how to signal to a hidden tab
that something changed , such that it changes the color?

I do not need a very limited API. I need a programmable tab bar.

[-- Attachment #2: Type: text/html, Size: 1272 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

Googling for images of "emacs tabs" , I found lots of images of emacs with
all kind of tabs.

So the code already exist.

Let us try to give a general definition of tabs, common for all interfaces.

[-- Attachment #2: Type: text/html, Size: 287 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[Stephen J. Turnbull]

Alin Soare writes:

 > Without events, do you have a concrete idea how to signal to a
 > hidden tab that something changed , such that it changes the color?

C-h f set-process-sentinel and C-h f next-event, please.  Yes, I know
that's gross and disgusting if you're used to working with modern
widget sets, but that's how things are done in Emacsen.  Think of it
as very low-level, and build the nice API you want from that.  Tab
controls are UI; they don't need to be massively fast or anything.

 > I do not need a very limited API. I need a programmable tab bar.

I have one.  Emacs won't accept it for legal reasons.  I see no reason
to do more work on it (it wasn't my baby in the first place, so I'm
not up on the internals), but I'm happy to offer API advice based on
my experience with the tab control I have.

Re: Tabs are ready? -> Let us give a definition of tabs.

[PJ Weisberg]

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

On Monday, February 6, 2012, Alin Soare <as1789@gmail.com> wrote:

>> But this does not require all of the junk (events, callbacks, etc)
>> that you've talked about.  All that *needs* to be added to Emacs is
>> the very limited API needed to associate tabs with a window or frame,
>> displayable content and a label with each tab, and to query that
>> information.  The rest can be implemented with existing Emacs Lisp
>> facilities, such as faces (to change the color of a tab) and process
>> sentinels (one sort of event callback).  If you want a GTK-like API,
>> that should be easy to write in Lisp.
>>
>
> Without events, do you have a concrete idea how to signal to a hidden tab
that something changed , such that it changes the color?
> I do not need a very limited API. I need a programmable tab bar.

I would give the tab a "wants attention" flag that gets unset when the tab
is activated, and set when `(tab-request-attention TAB)' is called, e.g. by
a process sentinal.  Then the tab's title would switch from
`tab-inactive-face' to `tab-wants-attention-face'.

The way I'm picturing it, the tab's internal state consists of four pieces
of data: a title, a window (or possibly window configuration), a function
that's called when it becomes active, and another function that's called
when it becomes inactive.  That *seems* like it's meeting all your
requirements, as I've understood them.

-- 

-PJ

Gehm's Corrollary to Clark's Law: Any technology distinguishable from
magic is insufficiently advanced.

[-- Attachment #2: Type: text/html, Size: 1777 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

>
> >
> > Without events, do you have a concrete idea how to signal to a hidden
> tab that something changed , such that it changes the color?
> > I do not need a very limited API. I need a programmable tab bar.
>
>



> I would give the tab a "wants attention" flag that gets unset when the tab
> is activated, and set when `(tab-request-attention TAB)' is called, e.g. by
> a process sentinal.  Then the tab's title would switch from
> `tab-inactive-face' to `tab-wants-attention-face'.
>
>
I would do somethig else: attach to tab an ID; using this id I generate a
function whose name depends on its id. I add this function in the list of
hooks of a process.

When the process makes an internal change, it calls the hook attached
exactly to the tab I am interested about. This function could chnage the
color , make a beep, or force a show-tab.




> The way I'm picturing it, the tab's internal state consists of four pieces
> of data: a title, a window (or possibly window configuration), a function
> that's called when it becomes active, and another function that's called
> when it becomes inactive.  That *seems* like it's meeting all your
> requirements, as I've understood them.
>
>
Good. At least, yes.

NOT a window (or possibly window configuration). We need a LIST OF
VARIABLES, local to tab. Imagine the tab as an actor. It can keep such a
list. In fact, I wanted to say that I define a tab with message-passing
style, and this is a way of implementing an object-oriented system.

Into such a list we can keep a variable that is evaluated to a
window-config. In the moment of hide the tab, the hide event can save the
current win-conf into a variable, and the show event can restore the
winconf from this variable.

[-- Attachment #2: Type: text/html, Size: 2539 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

> The way I'm picturing it, the tab's internal state consists of four pieces
>> of data: a title, a window (or possibly window configuration), a function
>> that's called when it becomes active, and another function that's called
>> when it becomes inactive.  That *seems* like it's meeting all your
>> requirements, as I've understood them.
>>
>>
>
The title must also a tab-local variable.

For example, a process calls a callback of the event of a tab, and this
callback should be able to change the name of a tab .

For example, a tab should be able to display the ##cinema buffer of an IRC
process.

When somebody writes in channel, I want to change the name of a tab to the
last person who wrote there, etc.

Or to change the name of the tab when somebody wrote ME someting.

So, the tabs must be programmable, with no restriction, as a fixed name,
etc.

[-- Attachment #2: Type: text/html, Size: 1509 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

people who died in the houses cannot be buried.

[-- Attachment #2: Type: text/html, Size: 78 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

2012/2/10 Alin Soare <as1789@gmail.com>

> people who died in the houses cannot be buried.
>
>
>
Sorry, I wanted to give a message elsewhere; it was about the tsunami of
snow that passed over europe. there are thousands of houses blocked under a
mountain of snow of 4 meters.

[-- Attachment #2: Type: text/html, Size: 564 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[Nix]

On 9 Feb 2012, Alin Soare stated:

>> The way I'm picturing it, the tab's internal state consists of four pieces
>>> of data: a title, a window (or possibly window configuration), a function
>>> that's called when it becomes active, and another function that's called
>>> when it becomes inactive.  That *seems* like it's meeting all your
>>> requirements, as I've understood them.
>>
> The title must also a tab-local variable.

I've already pointed out that true tab-local variables would have nasty
consequences for critical code in Emacs, confusing the semantics of
variable lookup. Look at the sad history of frame-local variables and
their interaction with buffer-local variables for an indication of the
subtle problems you'll be inviting. (The problem is simple: if a buffer
and its frame *both* declare a variable to be 'local', which takes
precedence? There is probably code that depends on *each* taking
precedence, so any answer will be wrong.)

Now a list of 'tab parameters', like frame parameters, which have to be
explicitly looked up when needed, is more likely to be accweptable.

-- 
NULL && (void)

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

>
>
> >> The way I'm picturing it, the tab's internal state consists of four
> pieces
> >>> of data: a title, a window (or possibly window configuration), a
> function
> >>> that's called when it becomes active, and another function that's
> called
> >>> when it becomes inactive.  That *seems* like it's meeting all your
> >>> requirements, as I've understood them.
> >>
> > The title must also a tab-local variable.
>
> I've already pointed out that true tab-local variables would have nasty
> consequences for critical code in Emacs, confusing the semantics of
> variable lookup. Look at the sad history of frame-local variables and
> their interaction with buffer-local variables for an indication of the
> subtle problems you'll be inviting. (The problem is simple: if a buffer
> and its frame *both* declare a variable to be 'local', which takes
> precedence? There is probably code that depends on *each* taking
> precedence, so any answer will be wrong.)
>
> Now a list of 'tab parameters', like frame parameters, which have to be
> explicitly looked up when needed, is more likely to be accweptable.
>
>

Please follow the previous messages; I pointed the fact that tabs could be
conceived  as object oriented system.

If a tab needs to create a process, it needs to keep the process variable
TABPROC somewhere. This 'somewhere does not belong to global env, but to a
tab-env.

The system will never see the variable  TABPROC.

The variable tabproc is evaluated only by the callbacks associated with the
events of the tab.

Only the callbacks of the tab need to evaluate that variable.

Frame local and buffer-local works on another env which is accessible to
Eval, so to global env. In object oriented, the envs are separated.

For me it is clear that we will never agree on a common solution . The
conclusion is that only 1 person will have to write the code for
console/gtk/athena/motif. I can write it, and need to read the manual of
motif and athena. I know GTK at beginning level.

I will not be abe to cope with this problem in the near future.

[-- Attachment #2: Type: text/html, Size: 2662 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[Nix]

On 11 Feb 2012, Alin Soare uttered the following:
> If a tab needs to create a process, it needs to keep the process variable
> TABPROC somewhere. This 'somewhere does not belong to global env, but to a
> tab-env.
>
> The system will never see the variable  TABPROC.
>
> The variable tabproc is evaluated only by the callbacks associated with the
> events of the tab.
>
> Only the callbacks of the tab need to evaluate that variable.

So it's a hook parameter, part of state kept by the tab. Right. That's
less likely to be agony to implement and less likely to cause
dissension.

-- 
NULL && (void)

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

>
>
> So it's a hook parameter, part of state kept by the tab. Right.



If the hok 'initialize-tab produce that variable local to tab, I cannot see
how to send this variable to the hooks 'show-tab or 'kill-tab that uses it,
via parameters of hooks.


In the same time, ideally if that this variable be hidden to global env,
because no other part of emacs needs it, apart from the hooks of the tab...

[-- Attachment #2: Type: text/html, Size: 742 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

>
>> So it's a hook parameter, part of state kept by the tab. Right.
>
>
>
> If the hok 'initialize-tab produce that variable local to tab, I cannot
> see how to send this variable to the hooks 'show-tab or 'kill-tab that uses
> it, via parameters of hooks.
>
>
>
In fact, it is possible. There is a fact in computation, that using an
 operation of adding, testing for 0, and having  many variables , one can
do everything.

[-- Attachment #2: Type: text/html, Size: 890 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[Stephen J. Turnbull]

Nix writes:

 > (The problem is simple: if a buffer and its frame *both* declare a
 > variable to be 'local', which takes precedence? There is probably
 > code that depends on *each* taking precedence, so any answer will
 > be wrong.)

I've not seen complaints about this in re: XEmacs specifiers where the
default precedence is window beats buffer beats frame beats global
beats baked-in-code-fallback.  (Of course that may be because people
who need a different precedence use the DOMAIN parameter to
`specifier-instance' -- but AFAIK only Ben Wing and I know that it
exists.  *You* might, but who else would? :-)

ISTM, that the question arises in Emacs because the *-local variables
never had a different API from ordinary variable reference, so
everybody just assumed it would DTRT for them.  I suspect that because
of the history of experience with specifiers, XEmacs could arrange for
variables with specifier values to be magic, ie, dereferenced via
specifier-instance (with no DOMAIN parameter specified), and no XEmacs
users would be confused.

WDYT?

Re: Tabs are ready? -> Let us give a definition of tabs.

[Nix]

On 13 Feb 2012, Stephen J. Turnbull verbalised:

> Nix writes:
>
>  > (The problem is simple: if a buffer and its frame *both* declare a
>  > variable to be 'local', which takes precedence? There is probably
>  > code that depends on *each* taking precedence, so any answer will
>  > be wrong.)
>
> I've not seen complaints about this in re: XEmacs specifiers where the
> default precedence is window beats buffer beats frame beats global
> beats baked-in-code-fallback.

Yeah, but horrible though specifiers are, at least they don't interfere
with normal variable lookup, which both has to remain consistent with
how it used to be (or break the world) *and* is time-critical. Calls to
'specifier-instance' just don't have the same criticality.

>                                (Of course that may be because people
> who need a different precedence use the DOMAIN parameter to
> `specifier-instance' -- but AFAIK only Ben Wing and I know that it
> exists.  *You* might, but who else would? :-)

Guilty :) I found it useful to use one set of colours on a TTY and
another in X...

> ISTM, that the question arises in Emacs because the *-local variables
> never had a different API from ordinary variable reference, so
> everybody just assumed it would DTRT for them.

Yep. However, I do think the Emacs approach is preferable *if* you can
work the wrinkles out: it's less irregular and more transparent. Nobody
gets confused about local variables the way everyone does about
specifiers.

Someone really should sit down with *-local variable precedence and give
it a good formal backing the way specifiers (sort of) got one. We
already have several layers of local variable: if one works, N should
work in an unsurprising fashion once the semantics are actually nailed
down. But it does mean you have to nail the semantics down first rather
than whapping in something that sort of works in the usual Emacs fashion
:PPP

(note the careful absence of actors here: *I'm* not doing it anytime
soon! But the mythical impersonal infinite-in-capacity 'someone'
perhaps should.)

-- 
NULL && (void)

Re: Tabs are ready? -> Let us give a definition of tabs.

[Tom Tromey]

>>>>> "Nix" == Nix  <nix@esperi.org.uk> writes:

Nix> Someone really should sit down with *-local variable precedence and give
Nix> it a good formal backing the way specifiers (sort of) got one.

I was under the (perhaps mistaken?) impression that the decision had
been made to deprecate frame-locals and not ever introduce other kinds
of *-local variables, reducing the problem to just dealing with
buffer-locals.

Tom

Re: Tabs are ready? -> Let us give a definition of tabs.

[Nix]

On 13 Feb 2012, Tom Tromey outgrape:

>>>>>> "Nix" == Nix  <nix@esperi.org.uk> writes:
>
> Nix> Someone really should sit down with *-local variable precedence and give
> Nix> it a good formal backing the way specifiers (sort of) got one.
>
> I was under the (perhaps mistaken?) impression that the decision had
> been made to deprecate frame-locals and not ever introduce other kinds
> of *-local variables, reducing the problem to just dealing with
> buffer-locals.

Well, yes, but that's really *because* nobody could figure out
consistent and unsurprising semantics regarding the interaction of
*-local variables with (let ...). That problem remains: it's there even
for buffer-locals, which we are surely not planning to deprecate.

-- 
NULL && (void)

Re: Tabs are ready? -> Let us give a definition of tabs.

[Tom Tromey]

>>>>> "Nix" == Nix  <nix@esperi.org.uk> writes:

Nix> Well, yes, but that's really *because* nobody could figure out
Nix> consistent and unsurprising semantics regarding the interaction of
Nix> *-local variables with (let ...). That problem remains: it's there even
Nix> for buffer-locals, which we are surely not planning to deprecate.

What are the problems with just buffer-locals?  I thought they were
pretty well-defined.  There's some text and an example in the manual
that explains the weird case.  If there are other weird cases, I would
like to know what they are.

Once you add other kinds of locals you have to decide how they all
interact.  That is a lot harder than just defining how buffer-locals
act.  To my mind that is the major issue; it is simpler to just define
it away, and in practice I don't think it makes elisp harder to use.
Perhaps the latter point is wishful thinking?

Tom

Re: Tabs are ready? -> Let us give a definition of tabs.

[Nix]

On 13 Feb 2012, Tom Tromey outgrape:

>>>>>> "Nix" == Nix  <nix@esperi.org.uk> writes:
>
> Nix> Well, yes, but that's really *because* nobody could figure out
> Nix> consistent and unsurprising semantics regarding the interaction of
> Nix> *-local variables with (let ...). That problem remains: it's there even
> Nix> for buffer-locals, which we are surely not planning to deprecate.
>
> What are the problems with just buffer-locals?  I thought they were
> pretty well-defined.

Agreed, but that doesn't mean they're not problematic.

>                       There's some text and an example in the manual
> that explains the weird case.  If there are other weird cases, I would
> like to know what they are.

See, the intuitive definition of buffer-locals would have them nesting
just underneath the global scope, so they would never ever supplant let
bindings. I can't imagine anyone actually wanting the current semantics:
they are purely an implementation artifact.

Can you recall any elisp code that establishes let bindings, switches
buffers, then operates under the assumption that some or all of its let
bindings or parameters may have changed? Because that's what we should
be doing if we actually think those semantics make sense and don't want
our elisp code broken by users establishing whatever buffer-local
bindings they like. Nobody actually codes that way, because it would be
insane. Instead we *hope* that nobody establishes makes variables
buffer-local whose names overlap the names of any local variables or
parameters. Generally, we are lucky (and it is actually quite hard to
contrive a case that is broken by the current rules). But this is hardly
ideal!

More worryingly, if you choose the wrong name for your buffer-local
variable, parameters and local bindings will smash it out of hand, with
no warnings at all. *This* is easy to contrive a test for: just try
assigning a local value to a buffer-local variable named 'start': it
doesn't even survive a round of C-h v and quit-window!

We may be saved here by the relatively large size of the space available
for names, and by the fact that mostly it is Lisp code that establishes
new global and buffer-local bindings, not users. But it is still icky
and feels *wrong* and generally makes my correctness-inclined skin
crawl.

> Once you add other kinds of locals you have to decide how they all
> interact.

Yep. That's what I meant by someone having to sit down and define the
semantics of this sort of thing before adding any new types of
locally-scoped variable. But the behaviour of buffer-locals is, to be
honest, already a bug, documented or not. You can break all sorts of
core Emacs functions with M-x make-local-variable, which is not
documented nor expected by users who do it.

>            That is a lot harder than just defining how buffer-locals
> act.

Unfortunately they do not currently act in a way I would consider
consistent. "The global value is global, the local value is less local
than 'let' unless you switch buffers inside a 'let' whereupon it is
suddenly more local than 'let', even if you switch back again" is not
sane. It happens to be easy to implement, but it doesn't follow anything
I would consider normal scoping rules for any language.

It so happens that this rarely causes trouble. But *ick*.

-- 
NULL && (void)

Re: Tabs are ready? -> Let us give a definition of tabs.

[Tom Tromey]

>>>>> "Nix" == Nix  <nix@esperi.org.uk> writes:

Nix> See, the intuitive definition of buffer-locals would have them nesting
Nix> just underneath the global scope, so they would never ever supplant let
Nix> bindings. I can't imagine anyone actually wanting the current semantics:
Nix> they are purely an implementation artifact.

I can't imagine it either; but at the same time, changing anything seems
dangerous, especially given that the current behavior is explicitly
documented.

Nix> Can you recall any elisp code that establishes let bindings, switches
Nix> buffers, then operates under the assumption that some or all of its let
Nix> bindings or parameters may have changed?

I can't recall any, but I don't think that is a reasonable test.

Nix> More worryingly, if you choose the wrong name for your buffer-local
Nix> variable, parameters and local bindings will smash it out of hand, with
Nix> no warnings at all. *This* is easy to contrive a test for: just try
Nix> assigning a local value to a buffer-local variable named 'start': it
Nix> doesn't even survive a round of C-h v and quit-window!

More code should use lexical binding; or we should have CL-style
packages; or both :-)

Tom

Re: Tabs are ready? -> Let us give a definition of tabs.

[Stefan Monnier]

Nix> Can you recall any elisp code that establishes let bindings, switches
Nix> buffers, then operates under the assumption that some or all of its let
Nix> bindings or parameters may have changed?
> I can't recall any, but I don't think that is a reasonable test.

It's probably rare, but I'd be surprised if such code doesn't exist.
The likely variable involved could be default-directory (one of the most
common variables to be both buffer-local and let-bound).


        Stefan

Re: Tabs are ready? -> Let us give a definition of tabs.

[Nix]

On 15 Feb 2012, Tom Tromey verbalised:

>>>>>> "Nix" == Nix  <nix@esperi.org.uk> writes:
> Nix> More worryingly, if you choose the wrong name for your buffer-local
> Nix> variable, parameters and local bindings will smash it out of hand, with
> Nix> no warnings at all. *This* is easy to contrive a test for: just try
> Nix> assigning a local value to a buffer-local variable named 'start': it
> Nix> doesn't even survive a round of C-h v and quit-window!
>
> More code should use lexical binding; or we should have CL-style
> packages; or both :-)

I wonder if lexical binding solves this bug? Presumably it does, because
the actual variable you end up using gets cconved to a different name.

-- 
NULL && (void)

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

I propose you something else -- I do not know just now whether this is
realizable with human efforts.

I thought whether Emacs could insert Morphic Objects, like Smalltalk.

Quite so -- first of all the closures must appear in Emacs , which is not
the actual case.

But in case this would happen, the buffers will become simple Morphs.

All graphical objects will become morphs.

That means, we could drop a TAB inside a Buffer, or inside a Frame.

Having closures, we can communicate via messages, which makes possible a
real graphical environment.

Well ... this is the theory.

But it would be good to have it in practice.

What do you say?



Alin

[-- Attachment #2: Type: text/html, Size: 929 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

I propose you something else -- I do not know just now whether this is
> realizable with human efforts.
>
> I thought whether Emacs could insert Morphic Objects, like Smalltalk.
>
>
For realizing such a project I could contribute with inseting closures in
Emacs , or writing a minimal smalltalk evaluator -- but an evaluator of
lisp with closures would be enough.

[-- Attachment #2: Type: text/html, Size: 662 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[Stefan Monnier]

>> (The problem is simple: if a buffer and its frame *both* declare a
>> variable to be 'local', which takes precedence? There is probably
>> code that depends on *each* taking precedence, so any answer will
>> be wrong.)
> I've not seen complaints about this in re: XEmacs specifiers where the

Indeed, the problem is not one of precedence.  It's one of implementing
it efficiently and still make it work right (after defining what "right"
means) in the presence of let-bindings.  Compound this with the fact
that such combinations are virtually never used (and hence never
tested/debugged) and you'll see that it's both a painful problem to
solve and one that comes with no reward.

Specifiers are easier because they don't have to interact with
let-binding (and since their code path is separate from the one of
variables, they don't need to be particularly efficient, so I guess
they can/could provide let-style rebinding with less pain).


        Stefan

Re: Tabs are ready? -> Let us give a definition of tabs.

[Nix]

On 13 Feb 2012, Stefan Monnier stated:
> Indeed, the problem is not one of precedence.  It's one of implementing
> it efficiently and still make it work right (after defining what "right"
> means) in the presence of let-bindings.  Compound this with the fact
> that such combinations are virtually never used (and hence never
> tested/debugged) and you'll see that it's both a painful problem to
> solve and one that comes with no reward.

The 'never tested' problem is surely best fixed -- once we figure out
what the semantics of such an interaction should be -- with a test in
the Emacs testsuite. This sort of subtle rarely-noticed-when-it-breaks
lisp-layer thing is what the automated testsuite was *made* for.

(but I am teaching my elderly relatives to aspirate calcinated avian
embryos again. I should give this up.)

-- 
NULL && (void)

Re: Tabs are ready? -> Let us give a definition of tabs.

[Stefan Monnier]

> The 'never tested' problem is surely best fixed -- once we figure out
> what the semantics of such an interaction should be -- with a test in

But in the present case it was easier to fix it by removing the
corresponding unused feature.


        Stefan

Re: Tabs are ready? -> Let us give a definition of tabs.

[Nix]

On 13 Feb 2012, Stefan Monnier outgrape:

>> The 'never tested' problem is surely best fixed -- once we figure out
>> what the semantics of such an interaction should be -- with a test in
>
> But in the present case it was easier to fix it by removing the
> corresponding unused feature.

Yeah, but it was a nicely orthogonal feature which, *had* consistent
semantics existed, would probably not have been removed. (This is all
rather hypothetical, I know.)

-- 
NULL && (void)

Re: Tabs are ready? -> Let us give a definition of tabs.

[martin rudalics]

> As well as some of the non-native speakers, as I presume Martin is.

He is.

martin

Re: Tabs are ready? -> Let us give a definition of tabs.

[martin rudalics]

 >> How do you communicate to the tab what the "something" is?
 >
 >
 >
 > execute 'grep -i foo *' in background , example

I didn't ask "what" the something is.  I asked "how" you want to
communicate that something to the tab.

 >>> 2. The 'show event should commute to the buffer *grep*
 >> This is the standard buffer switching functionality.
 >>
 >>
 > I know how to commute a buffer. In this case of tab, I want the show event
 > to commute to a given buffer.

I meant that this is the standard behavior associated with tabs: Display
something like a file or a webpage in the display area associated with
the tab.

 >>> 3. when grep finds something, and the tab is hidden , the tab widget to
 >>> change the color
 >> What sense does it make to have a hidden tab change color?  And what
 >> kind of event is this in your nomenclature?
 >>
 >>
 > Tabs should register a callback for an event , for example, when i/o
 > arrives in  the given process...

But what do you want to do?  I suppose you want to show the tab that was
hidden before.  OTOH "show" in your nomenclature meant something
different so far: Do some standard action associated with the tab like
switching buffers or restoring a window configuration.

 >>> 4. The 'close event should kill the *grep* buffer, and the process , if
 >> it
 >>> had not finished yet
 >>>  Could you do this using buttons in toolbar or menubar, as you insist ?
 >> So far I'd only insist that saving and restoring window configurations
 >> should be done with the menubar rather than with a tab.  I never ever
 >> use toolbars but I think that mail handling routines using the toolbar
 >> (could) do such things routinely (inform of new mail, kill a buffer and
 >> remove the associated button when mail has been sent , ...).
 >>
 >>
 > Why do you change the subject of discussion ? saving and restoring window
 > configurations concerns other type of tab, not this one I am talking here.

I referred to the window configuration example because so far that was
the only one where I "insisted" on providing a menubar entry rather than
a tab.  You can't accuse me of insistence with an example you didn't
provide before.  My argument was that the "'close event" for the *grep*
buffer is rather similar to a toolbar button provided by an email
problem which, when hit, causes the currently written mail to get sent
and the associated display area where that mail was shown removed.  I
don't know of any MUA that uses tabs for such a purpose but I don't want
to exclude it.

I also agree that the hourglass functionality of a tab you cited earlier
(that is changing the color of a tab while work like grep searching is
in progress) can be useful, for example, when performing a couple of
grep searches or compilations simultaneously.

martin

Re: Tabs are ready? -> Let us give a definition of tabs.

[martin rudalics]

 >> ... and what is a "standard event" in this context?  And why can a
 >> toolbar button not react to such a standard event in the same way?
 >
 >
 > Initialize tab, hide tab, show tab, kill tab, at least.

I don't understand that yet.  For me an event is a user action like
hitting a key or moving the mouse.  The type of that action and any
additional information are communicated by the OS to Emacs which reacts
to the event by executing some action (or doing nothing).  Initializing
or hiding a tab is in my opinion an action performed by Emacs itself,
possibly in reaction to an event or triggered by a timer.

martin

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

> >> ... and what is a "standard event" in this context?  And why can a
> >> toolbar button not react to such a standard event in the same way?
> >
> >
> > Initialize tab, hide tab, show tab, kill tab, at least.
>
> I don't understand that yet.  For me an event is a user action like
> hitting a key or moving the mouse.  The type of that action and any
> additional information are communicated by the OS to Emacs which reacts
> to the event by executing some action (or doing nothing).  Initializing
> or hiding a tab is in my opinion an action performed by Emacs itself,
> possibly in reaction to an event or triggered by a timer.
>
>
In graphocal contexts , like GTK / motif programming, the concept of 'event
has almost nothing to do with the concept of UNIX signal.

Initializing a tab is not an action performed by emacs, but it is what you
define it to be.

In gtk for example, if you insert a gtk-notebook widget in emacs, you write
the callback functions in C , such that they call elisp function of that
signals.

[-- Attachment #2: Type: text/html, Size: 1492 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[joakim]

Alin Soare <as1789@gmail.com> writes:

>     >> ... and what is a "standard event" in this context?  And why
>     can a
>     >> toolbar button not react to such a standard event in the same
>     way?
>     >
>     >
>     > Initialize tab, hide tab, show tab, kill tab, at least.
>     
>     
>     I don't understand that yet.  For me an event is a user action
>     like
>     hitting a key or moving the mouse.  The type of that action and
>     any
>     additional information are communicated by the OS to Emacs which
>     reacts
>     to the event by executing some action (or doing nothing).
>      Initializing
>     or hiding a tab is in my opinion an action performed by Emacs
>     itself,
>     possibly in reaction to an event or triggered by a timer.
>     
>     
>
> In graphocal contexts , like GTK / motif programming, the concept of
> 'event has almost nothing to do with the concept of UNIX signal.
>  
> Initializing a tab is not an action performed by emacs, but it is what
> you define it to be.
>
> In gtk for example, if you insert a gtk-notebook widget in emacs, you
> write the callback functions in C , such that they call elisp function
> of that signals.

In Emacs low-level code, callbacks are not really used. Instead events
are generated, that get handled by the Emacs event loop that eventually
will result in Lisp code being called.

I use this technique in my xwidget branch, where GTK components can be
embedded in an Emacs buffer. The GTK widgets then register GTK callback
signals that in turn generate Emacs events, that then get handled by the
Emacs message loop. You then use the normal message map to bind lisp to
your event.

Initially I had the misconception that the callback should call Lisp
directly, but that didn't work out well. Thankfully I was pointed in the
right direction by emacs-devel.

-- 
Joakim Verona

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

> In Emacs low-level code, callbacks are not really used. Instead events
> are generated, that get handled by the Emacs event loop that eventually
> will result in Lisp code being called.
>
>
Good. We need a mechanism common for tabs of console, gtk, motif.

The best starting point is to start thinking from GTK notebook widget,
because it is easy to insert in emacs, and it is already well known.



> I use this technique in my xwidget branch, where GTK components can be
> embedded in an Emacs buffer. The GTK widgets then register GTK callback
> signals that in turn generate Emacs events, that then get handled by the
> Emacs message loop. You then use the normal message map to bind lisp to

your event.
>


I do not think we need to catch all GTK events, like mouse passing over a
widget.



>

Initially I had the misconception that the callback should call Lisp
> directly, but that didn't work out well. Thankfully I was pointed in the
> right direction by emacs-devel.
>
>
In my opinion, fot tabs at least, at C level , the callbacks should do
nothing, apart from calling lisp function associated to that events ...

[-- Attachment #2: Type: text/html, Size: 2050 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[martin rudalics]

 > Initializing a tab is not an action performed by emacs, but it is what you
 > define it to be.

And who executes what I define?

 > In gtk for example, if you insert a gtk-notebook widget in emacs, you write
 > the callback functions in C , such that they call elisp function of that
 > signals.

Emacs tabs should work without gtk as well.

martin

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

> > Initializing a tab is not an action performed by emacs, but it is what
> you
> > define it to be.
>
> And who executes what I define?


The tabs will have an interface of primitive functions, written at the
C-level.

The primitive function 'create-tab will have to execute at its end the
callback written in lisp. This callback will make the initialization.




> > In gtk for example, if you insert a gtk-notebook widget in emacs, you
> write
> > the callback functions in C , such that they call elisp function of that
> > signals.
>
> Emacs tabs should work without gtk as well.



Yes, so ? What do you mean by that ?

Tabs must have a common mechaninsm for gtk/console/etc


Alin

[-- Attachment #2: Type: text/html, Size: 1208 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[martin rudalics]

 >> So if the last tab action we activated was such
 >> a save we probably shouldn't highlight the associated tab.  But then
 >> moving ("commuting") to the next tab will happen without visual feedback
 >> from where we started moving.  Think of doing C-PgDn and the next tab is
 >> a "restore window configuration" tab.
 >
 >
 > In order to be able to restore a window configuration you have to save it
 > first.

Which has been done as described in the text above.

 >>> Every time when you commute to a tab, the lisp function associated to the
 >>> 'show event is called.
 >> In firefox moving to the next tab means showing the associated page.
 >> What is the 'show event for "restore window configuration"?
 >
 >
 > Restoring the saved window configuration, for example.

Showing another buffer in a window is reversible.  You can easily switch
back to the buffer shown before.  Restoring a window configuration is
irreversible unless you save the current configuration when restoring.
Providing such behavior via a "show" event is confusing at least.

martin

Re: Tabs are ready? -> Let us give a definition of tabs.

[Nix]

On 6 Feb 2012, martin rudalics stated:
>>>> Every time when you commute to a tab, the lisp function associated to the
>>>> 'show event is called.
>>> In firefox moving to the next tab means showing the associated page.
>>> What is the 'show event for "restore window configuration"?
>>
>> Restoring the saved window configuration, for example.
>
> Showing another buffer in a window is reversible.  You can easily switch
> back to the buffer shown before.  Restoring a window configuration is
> irreversible unless you save the current configuration when restoring.
> Providing such behavior via a "show" event is confusing at least.

I don't know. I'd actually very much like a set of per-window tabs which
recorded not a single buffer per tab but an entire window-configuration
per tab. It would make a nice user interface for things like winring.el.

-- 
NULL && (void)

Re: Tabs are ready? -> Let us give a definition of tabs.

[martin rudalics]

 > I don't know. I'd actually very much like a set of per-window tabs which
 > recorded not a single buffer per tab but an entire window-configuration
 > per tab.

OK.  But these should be per-frame tabs since a window configuration is
defined for frames.

 > It would make a nice user interface for things like winring.el.

We'd probably have to do the following things:

(1) When switching to another configuration make it easy to switch back to
     the last configuration.

(2) Provide a naming scheme suitable for tabs.

(3) Handle tab switching via the keyboard in an appropriate way.  For
     example, we could use a virtual, highlighted tab representing the
     current window configuration such that switching to the next or
     previous tab could be done with the necessary feedback.

martin

Re: Tabs are ready? -> Let us give a definition of tabs.

[Nix]

On 6 Feb 2012, martin rudalics said:

>> I don't know. I'd actually very much like a set of per-window tabs which
>> recorded not a single buffer per tab but an entire window-configuration
>> per tab.
>
> OK.  But these should be per-frame tabs since a window configuration is
> defined for frames.

Er, um, yes, of course. Never talk Emacs while hacking Qt, one's
terminology gets confused. :)

>> It would make a nice user interface for things like winring.el.
>
> We'd probably have to do the following things:
>
> (1) When switching to another configuration make it easy to switch back to
>     the last configuration.

Yep. (A key to toggle tabs, basically, like C-a a in screen.)

> (2) Provide a naming scheme suitable for tabs.
>
> (3) Handle tab switching via the keyboard in an appropriate way.  For
>     example, we could use a virtual, highlighted tab representing the
>     current window configuration such that switching to the next or
>     previous tab could be done with the necessary feedback.

winring.el already does much of this (though I don't think it is exactly
ideal in all respects).

-- 
NULL && (void)

RE: Tabs are ready? -> Let us give a definition of tabs.

[Drew Adams]

> I'd actually very much like a set of per-window tabs
> which recorded not a single buffer per tab but an
> entire window-configuration per tab.

I don't really want to delve into this discussion now, but I'd say that a tab
should be about as general as a menu item.  Yes, I know there is pushback by
some from that level of generality - already seen that the last time this topic
went 'round.  It's still my view, so far.

In particular, what you describe wrt a window config could as easily be extended
to a desktop (i.e., what desktop.el traffics in), and from there to a desktop
bookmark (which Bookmark+ offers).  And so on.  Why not?

The general idea is about switching to some alternative config/state, which
remains associated with a particular tab.  That's a bit less general than a
completely arbitrary action (function), but not by a lot.

Why prescribe that the only such alternative configs/states supported/allowed
are windows or frames or buffers or window/frame configs?

Anway, don't be surprised if I bow out now.  I don't really have anything
specific to say about this at the moment.  And I do realize that this is a
minority view (probably a minority of one).

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

I propose the following  [brief/ main steps of a] concrete solution for
changing the color of a hidden tab whose process gave output in the
meantime:

1. Every tab has a unique ID that can be read and not modified. This ID is
dubbed by the system at the creation of the tab.

1' Every tab has an internal state. The tab can be seen as a dispather of
messages (or actor) of scheme.

2. When the tab is created , it starts the process, and memorize the
process in its internal state.

3. we use the hooks from process , low level programming.

4. we add a hook that calls a function like tabs-process-signals. This is
either a function of the internal state of a tab, and in case must be
generated for each tab, using the ID of a tab, or be in global environment,
and loop over each tab.

5. this function (tabs--process-signals) either is generated separately for
each tab, or loops over the list of tabs, and identify the tab whose
process' buffer modified.

6. for that tab, tabs--process-signals calls a function like
change-color-tab, or make a noise, or force the commutation of the tab, in
order to see that a process gave an output/ that somebody wrote on an IRC
channel, etc.

Essential of this is that a tab must have its own internal state.

These are the main steps that pass in my mind now.

If emacs had actors, a tab could be implemented directly. If not, the idea
of internal state can be encoded somehow.



I am waiting for your ideas, please, and better solutions.

I am looking forward to find a mechanism for a  interface of tabs, common
for console/gtk/athena/etc.



Alin

[-- Attachment #2: Type: text/html, Size: 2100 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[Nix]

On 8 Feb 2012, Alin Soare outgrape:

> I propose the following  [brief/ main steps of a] concrete solution for
> changing the color of a hidden tab whose process gave output in the
> meantime:
>
> 1. Every tab has a unique ID that can be read and not modified. This ID is
> dubbed by the system at the creation of the tab.

This is pointless. Window configurations don't need a 'unique ID',
neither does this. Just reify the tab: make it a unique Lisp object type
(again, like window-configurations). Now the tab object serves as its
own unique ID.

> 1' Every tab has an internal state. The tab can be seen as a dispather of
> messages (or actor) of scheme.

I don't understand. Are you saying that each tab is its own recursive
editing loop? Because that seems unnecessary (and likely to be very
confusing to users).

> 2. When the tab is created , it starts the process, and memorize the
> process in its internal state.

Tabs surely have nothing to do with processes. I expect most tabs to
contain buffers (or window configurations, perhaps). A constraint that
they all contain processes is surely impractical.

Do you mean that (create-tab ...) returns a 'tab process', much as
'make-network-process' does, and that this 'tab process' is then used to
receive events from the tab somehow (such as the user switching to it)?

That's reasonable, I suppose, though we'd need to define what that
process sentinel does. For network processes this is clear enough:
creation of a network connection, its breaking, and the reception of
data invoke the sentinel and optionally dump the data into a buffer.

This makes conceptual sense because network connections are like
processes in that they are things down which asynchronous bytestreams
are transmitted in both directions. None of this is true for tabs, as
far as I can see, so the process sentinel model isn't such a good fit.
(I can't think of anything that is a better fit, except perhaps
some hooks called from the C core whenever a tab is switched to. I would
strongly advise against any concept of tab-local variables: while they
make programming a tiny bit easier they make variable lookup slower and
much harder to get right. Frame-local variables have enough ugliness and
unfixable bugs that they are being removed. Let's not make it worse. I
know nobody has proposed this yet: I thought I'd just shoot it down
pre-emptively.)

> 3. we use the hooks from process , low level programming.

You need a lot more description than that. What does a tab sentinel
function do? Processes and network streams send and receive data. What
do tabs do?

> 4. we add a hook that calls a function like tabs-process-signals. This is
> either a function of the internal state of a tab, and in case must be
> generated for each tab, using the ID of a tab, or be in global environment,
> and loop over each tab.

The latter is unscalable, but there's no requirement for something in
the global environment to necessarily do any sort of loop. A tabs hook
function would probably be called with the tab object as a parameter.

> 5. this function (tabs--process-signals) either is generated separately for
> each tab, or loops over the list of tabs, and identify the tab whose
> process' buffer modified.

If you passed the tab object as a parameter, that would be entirely
unnecessary.

> If emacs had actors, a tab could be implemented directly. If not, the idea
> of internal state can be encoded somehow.

Er, yeah, quite a lot of things in Emacs have internal state. More
internal state than you can shake a stick at. :)

-- 
NULL && (void)

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

>
>
> > I propose the following  [brief/ main steps of a] concrete solution for
> > changing the color of a hidden tab whose process gave output in the
> > meantime:
> >
> > 1. Every tab has a unique ID that can be read and not modified. This ID
> is
> > dubbed by the system at the creation of the tab.
>
> This is pointless. Window configurations don't need a 'unique ID',
> neither does this. Just reify the tab: make it a unique Lisp object type
> (again, like window-configurations). Now the tab object serves as its
> own unique ID.
>
>
We were talking here about a method to implement the hourglass
functionality of a tab.

Please read the previous discussion , and what means message passing in
scheme. I was talking about that.

[-- Attachment #2: Type: text/html, Size: 1095 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

2012/2/9 Alin Soare <as1789@gmail.com>

>
>> > I propose the following  [brief/ main steps of a] concrete solution for
>> > changing the color of a hidden tab whose process gave output in the
>> > meantime:
>> >
>> > 1. Every tab has a unique ID that can be read and not modified. This ID
>> is
>> > dubbed by the system at the creation of the tab.
>>
>> This is pointless. Window configurations don't need a 'unique ID',
>> neither does this. Just reify the tab: make it a unique Lisp object type
>> (again, like window-configurations). Now the tab object serves as its
>> own unique ID.
>>
>>
> We were talking here about a method to implement the hourglass
> functionality of a tab.
>
> Please read the previous discussion , and what means message passing in
> scheme. I was talking about that.
>
>
>

I already implemented an identical idea, and it works in console.

I am waiting to establish a common mechanism for gtk and motif.

Otherwise tabs cannot be installed.

[-- Attachment #2: Type: text/html, Size: 1616 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[Stephen J. Turnbull]

Nix writes:

 > I don't know. I'd actually very much like a set of per-window tabs which
 > recorded not a single buffer per tab but an entire window-configuration
 > per tab. It would make a nice user interface for things like winring.el.

I agree with this to a point.  The sticking point is that to me the
tab metaphor is about controlling what's displayed in a given region
(usually rectangular, always of constant shape and size) of the
screen.  I would be disconcerted if clicking a tab caused the frame to
resize.

Or the Emacs window, for that matter.  I don't have a problem
(conceptually) with a frame being divided into windows, each of which
holds a (sub?) window configuration.

In any case, a quick and dirty implementation should not be hard, as
long as you let the window configuration associated with a tab drive
the frame geometry (who cares if Steve is disconcerted? ;-) The
refinements would be to deal with (a) constraining the window
configurations allowed and (b) constructing a "normalized" (adapted to
the tab's preferred geometry) configuration.

Re: Tabs are ready? -> Let us give a definition of tabs.

[Nix]

On 7 Feb 2012, Stephen J. Turnbull spake thusly:

> Nix writes:
>
>  > I don't know. I'd actually very much like a set of per-window tabs which
>  > recorded not a single buffer per tab but an entire window-configuration
>  > per tab. It would make a nice user interface for things like winring.el.
>
> I agree with this to a point.  The sticking point is that to me the
> tab metaphor is about controlling what's displayed in a given region
> (usually rectangular, always of constant shape and size) of the
> screen.  I would be disconcerted if clicking a tab caused the frame to
> resize.

Indeed. I don't really expect window configurations to resize the frame
either, and am surprised whenever it happens. I'd much rather they tried
to fit the windows into the frame given its current size, as best they
could... (but that might be hard if the frame has radically resized).

This rarely impacts me though because all my Emacs X frames are the same
size.

> In any case, a quick and dirty implementation should not be hard, as
> long as you let the window configuration associated with a tab drive
> the frame geometry (who cares if Steve is disconcerted? ;-) The
> refinements would be to deal with (a) constraining the window
> configurations allowed and (b) constructing a "normalized" (adapted to
> the tab's preferred geometry) configuration.

Yes indeed.

-- 
NULL && (void)

Re: Tabs are ready? -> Let us give a definition of tabs.

[Alin Soare]

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

I received lots of messages , and I will not respond all now, sorry.

I just want to say, that if we do not agree on a definition of tabs that
are VERY GENERAL , that means , to be able to programm them from the first
version to do everything you think that a tab should/could do , then
another implementation/definition of tabs is loss of time.

But as time as you can programm in elisp a buffer/a window to behave as you
wish, why it would not be possible to create tabs that could be
programmable ?

Stephen : The junk with the events, etc was just a supposition. If you have
better idea, tell us how to do it.

[-- Attachment #2: Type: text/html, Size: 749 bytes --]

Re: Tabs are ready? -> Let us give a definition of tabs.

[Stephen J. Turnbull]

Alin Soare writes:

 > Stephen : The junk with the events, etc was just a supposition. If you have
 > better idea, tell us how to do it.

I already did, at least twice.

Specifically, an implementation is already available (in the
per-Emacs-window form) in XEmacs (>= 21.4) and SXEmacs.  The low-level
programming API is clumsy, you should be able to do better than what
we've got, but sufficient for proof-of-concept experimentation.

Re: Tabs are ready? -> Let us give a definition of tabs.

[martin rudalics]

 > The tabs will have an interface of primitive functions, written at the
 > C-level.
 >
 > The primitive function 'create-tab will have to execute at its end the
 > callback written in lisp. This callback will make the initialization.

But why for God's sake should I want to invoke a C routine whose sole
purpose is to call back a Lisp function?

 >>> In gtk for example, if you insert a gtk-notebook widget in emacs, you
 >> write
 >>> the callback functions in C , such that they call elisp function of that
 >>> signals.
 >> Emacs tabs should work without gtk as well.
 >
 >
 >
 > Yes, so ? What do you mean by that ?
 >
 > Tabs must have a common mechaninsm for gtk/console/etc

That's what I meant.

martin