Tabbed buffers

Tabbed buffers

[Nick Roberts]

On help-gnu-emacs, Per Nordlöw has asked about showing the threads view by
default in gdb-ui.  The problem is trying to fit so many windows in a single
frame.  Eclipse gets round this problem by displaying tabbed panes.  I know
that you can do something like this in Emacs using tabbar.el.  Nowadays though,
many applications, e.g., Firefox, use the underlying toolkit for this.  I
wonder if we should add such a feature to Emacs at the C level, at least for
GTK.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Tabbed buffers

[Miles Bader]

Nick Roberts <nickrob@snap.net.nz> writes:
> Eclipse gets round this problem by displaying tabbed panes.  I know
> that you can do something like this in Emacs using tabbar.el.
> Nowadays though, many applications, e.g., Firefox, use the underlying
> toolkit for this.  I wonder if we should add such a feature to Emacs
> at the C level, at least for GTK.

It seems like it would need some thought to work well in Emacs, as
tabbed user interfaces quickly become unusable if there lots of tabs,
and Emacs buffer counts are quite often _way_ over that threshold.

-Miles

-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

Re: Tabbed buffers

[Nick Roberts]

 > It seems like it would need some thought to work well in Emacs, as
 > tabbed user interfaces quickly become unusable if there lots of tabs,
 > and Emacs buffer counts are quite often _way_ over that threshold.

I'm sure it will take some work but I'm not suggesting that *all* the buffers
buffers are displayed in tabbed windows, just as currently not all the buffers
are displayed in normal windows.

In terms of lisp interface, for example, there could be optional extra argument
to display-buffer which gets ignored if Emacs doesn't support tabbed windows
for the toolkit with which it has been built.

--- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Tabbed buffers

[Miles Bader]

Nick Roberts <nickrob@snap.net.nz> writes:
> > It seems like it would need some thought to work well in Emacs, as
> > tabbed user interfaces quickly become unusable if there lots of
> > tabs, and Emacs buffer counts are quite often _way_ over that
> > threshold.
>
> I'm sure it will take some work but I'm not suggesting that *all* the
> buffers buffers are displayed in tabbed windows, just as currently not
> all the buffers are displayed in normal windows.

You have to be careful though, as I think typical user-experience is
with tools that _do_ put all "buffers" (or whatever term they use) in
tabs, so users will expect that they are.

Actually though, I suppose using the GUI's existing tab overflow
mechanism is probably good enough in many cases (e.g., which limits the
number of tabs, and puts remaining stuff in a menu which can be popped
up by a "..."  button on the far right).

My experiences with debuggers that use tabs are

  (1) Eclipse, which has an aggressive pruning/overflow mechanism.

      This keeps the number of tabs low, so the tab labels remain easily
      readable, but I've found that my typical "debugging working set"
      is larger than the number of tabs shown by default, and it quickly
      becomes annoying having to select tabs from the menu (you'd think
      it wouldn't be such a big deal, but for whatever reason I found
      this very annoying... :-)  Still, not that bad...

      [Of course this is partly due to Eclipse's wonky window layout
      (let's display all possible types of information crammed into the
      same display, in small unreadable windows), which makes the space
      available for the tab display much smaller than in most systems.]

  (2) VS [whatever version they have at work :-] seems to put far more
      files in tabs, to the point where the tab labels quickly become
      completely unreadable.  At this point the tabs become almost
      useless, you'd be better off just selecting from a menu.

> In terms of lisp interface, for example, there could be optional extra
> argument to display-buffer which gets ignored if Emacs doesn't support
> tabbed windows for the toolkit with which it has been built.

I don't think any interface that requires calls to display-buffer to
know about tabs is workable, there's simply too much code that wouldn't
know about them (not to mention we probably don't want to build in
dependencies on system-specific GUI features like tabs).

-Miles

-- 
Quidquid latine dictum sit, altum viditur.

Re: Tabbed buffers

[Stefan Monnier]

> I don't think any interface that requires calls to display-buffer to
> know about tabs is workable, there's simply too much code that wouldn't
> know about them (not to mention we probably don't want to build in
> dependencies on system-specific GUI features like tabs).

I could imagine introducing tabs as a new concept between windows
and frames.  So the behavior of display-buffer could be configured to
either use the current window, or pop a new window, or pop a new tab or
pop a new frame.

In any case we should probably ask tabbar.el users, and (more
importantly) XEmacs users&developers since XEmacs has had tabs for
a while now.

For what it's worth, I think that if we introduce this notion of tab, we
should change ttys to use tabs rather than frames since tty frames
behave much more like tabs.  Of course multiple ttys would each get its
own frame.


        Stefan

Re: Tabbed buffers

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> I could imagine introducing tabs as a new concept between windows
> and frames.  So the behavior of display-buffer could be configured to
> either use the current window, or pop a new window, or pop a new tab or
> pop a new frame.

Hmm, do we want the tab-bar to be per-frame, or per-emacs-window?

For "switching buffer" use of tabs, per-emacs-window seems like it might
be more useful, though obviously eating more screen real-estate.
[With such a setup, it would be useful to have "non-tabbed" and "tabbed"
emacs windows though I don't know how that UI would work...]

-Miles

-- 
Run away!  Run away!

Re: Tabbed buffers

[Thomas Lord]

[-- Attachment #1.1: Type: text/plain, Size: 908 bytes --]

Miles Bader wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>   
>> I could imagine introducing tabs as a new concept between windows
>> and frames.  So the behavior of display-buffer could be configured to
>> either use the current window, or pop a new window, or pop a new tab or
>> pop a new frame.
>>     
>
> Hmm, do we want the tab-bar to be per-frame, or per-emacs-window?
>   


As a user --- my thought is that a "tab" should contain a frame.
i.e., it's kind of filling in for a gap left by crappy X11 window
managers.


Coordination with the GNU desktop project here might help.

-t





> For "switching buffer" use of tabs, per-emacs-window seems like it might
> be more useful, though obviously eating more screen real-estate.
> [With such a setup, it would be useful to have "non-tabbed" and "tabbed"
> emacs windows though I don't know how that UI would work...]
>
> -Miles
>
>   


[-- Attachment #1.2: Type: text/html, Size: 1528 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Tabbed buffers

[Stefan Monnier]

>> I could imagine introducing tabs as a new concept between windows
>> and frames.  So the behavior of display-buffer could be configured to
>> either use the current window, or pop a new window, or pop a new tab or
>> pop a new frame.

> Hmm, do we want the tab-bar to be per-frame, or per-emacs-window?

Both make sense.

> For "switching buffer" use of tabs, per-emacs-window seems like it might
> be more useful, though obviously eating more screen real-estate.
> [With such a setup, it would be useful to have "non-tabbed" and "tabbed"
> emacs windows though I don't know how that UI would work...]

Yes, it'd be a per-window or per-frame setting.
If it's per-frame it'd switch between window-configurations, otherwise
it'd switch between buffers.


        Stefan

Re: Tabbed buffers

[Chong Yidong]

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

> I could imagine introducing tabs as a new concept between windows
> and frames.  So the behavior of display-buffer could be configured to
> either use the current window, or pop a new window, or pop a new tab or
> pop a new frame.

Here's another approach.  Currently, frames can be iconified or
normal/deiconified.  We could add a third state, "unselected tab",
which also contains information about a "master" frame that is the
selected tab to which the unselected tab is attached.  That way, a
"selected" tab is a frame in its normal or iconified states, and an
"unselected" tab is a frame in the "unselected tab" state.

Re: Tabbed buffers

[Richard Stallman]

    Here's another approach.  Currently, frames can be iconified or
    normal/deiconified.  We could add a third state, "unselected tab",
    which also contains information about a "master" frame that is the
    selected tab to which the unselected tab is attached.  That way, a
    "selected" tab is a frame in its normal or iconified states, and an
    "unselected" tab is a frame in the "unselected tab" state.

I think the most natural thing is for tabs to exist just within a
frame, and for each tab to have a window configuration.  Thus,
switching to another tab would select its window configuraton.
This is natural and already implemented.

Re: Tabbed buffers

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> I think the most natural thing is for tabs to exist just within a
> frame, and for each tab to have a window configuration.  Thus,
> switching to another tab would select its window configuraton.
> This is natural and already implemented.

That would be easy to implement, and I agree it would be insanely great
for many uses (especially if there are convenient key bindings for
moving to adjacent tabs) -- I'd _love_ to have a "Gnus" tab, and a "Gdb"
tab!

However that system would seem to essentially require making a tab to be
an explicit user action, somewhat heavyweight.

In many other systems, on the other hand, tabs are more lightweight, and
essentially represent different buffers; making a new "buffer" (in some
other app) automatically creates a new tab, so the user can easily see
what buffers/files he's created, and move among them.

I suspect this latter style of usage is what most people mean when they
say they wish Emacs supported tabs, and they might be disappointed to
see some other meaning of the term.

Such "buffer switching" usage _could_ work with your implementation, if
Emacs sticks to one window per frame, though -- and maybe users used to
that style would even _like_ one window per frame -- so maybe a
combination of settings could make everything work nicely in that case,
e.g., having the tab title default to the [first/only?] buffer name, and
configuring emacs to always create new tabs instead of new windows...?

-Miles

-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that
            will  make every christian in the world foamm at the mouth?
[iddt]      nurg, that's the goal

Re: Tabbed buffers

[Stefan Monnier]

> Such "buffer switching" usage _could_ work with your implementation, if
> Emacs sticks to one window per frame, though -- and maybe users used to
> that style would even _like_ one window per frame -- so maybe a
> combination of settings could make everything work nicely in that case,
> e.g., having the tab title default to the [first/only?] buffer name, and
> configuring emacs to always create new tabs instead of new windows...?

That's pretty much what I was suggesting: introduce a pop-up-tabs
variable between pop-up-windows and pop-up-frames.


        Stefan

Re: Tabbed buffers

[Richard Stallman]

    > combination of settings could make everything work nicely in that case,
    > e.g., having the tab title default to the [first/only?] buffer name, and
    > configuring emacs to always create new tabs instead of new windows...?

    That's pretty much what I was suggesting: introduce a pop-up-tabs
    variable between pop-up-windows and pop-up-frames.

Maybe there should be two kinds of tabs:

* Ordinary tabs.  If you are in one of these, the "other window"
operations work as now, staying in the same tab.

* Specified tabs.  These are created by programs such as GUD, and set
up in precise window configurations by them.

If you are in a specified tab, and you visit a buffer in "another
window", `display-buffer' creates a new ordinary tab, switches to it,
and displays the buffer there.

The user command to make a tab should make an ordinary tab.

Re: Tabbed buffers

[Nick Roberts]

 > > I think the most natural thing is for tabs to exist just within a
 > > frame, and for each tab to have a window configuration.  Thus,
 > > switching to another tab would select its window configuraton.
 > > This is natural and already implemented.

It's not what I had in mind,  Eclipse has tabs for each window.  However,
it's probably a more realistic goal and would provide benefit.

 > That would be easy to implement, and I agree it would be insanely great
 > for many uses (especially if there are convenient key bindings for
 > moving to adjacent tabs) -- I'd _love_ to have a "Gnus" tab, and a "Gdb"
 > tab!
 > 
 > However that system would seem to essentially require making a tab to be
 > an explicit user action, somewhat heavyweight.

I don't agree, there seems to a direct correspondence with creating a new
frame:

C-x 7 C-f	find-file-other-tab
C-x 7 C-o	display-buffer-other-tab
C-x 7 .		find-tag-other-tab
C-x 7 0		delete-tab
C-x 7 1		delete-other-tabs
C-x 7 2		make-tab-command
C-x 7 b		switch-to-buffer-other-tab
C-x 7 d		dired-other-tab
C-x 7 f		find-file-other-tab
C-x 7 m		compose-mail-other-tab
C-x 7 o		other-tab
C-x 7 r		find-file-read-only-other-tab

in additions to actions that could be associated with mouse clicks.

 > In many other systems, on the other hand, tabs are more lightweight, and
 > essentially represent different buffers; making a new "buffer" (in some
 > other app) automatically creates a new tab, so the user can easily see
 > what buffers/files he's created, and move among them.
 > 
 > I suspect this latter style of usage is what most people mean when they
 > say they wish Emacs supported tabs, and they might be disappointed to
 > see some other meaning of the term.

I don't know what people would expect but I think a new tab should only
be created when explicitly requested.  Also for toolkits for which Emacs
doesn't support tabs the *-tab commands could revert to *frame commands

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Tabbed buffers

[Miles Bader]

Nick Roberts <nickrob@snap.net.nz> writes:
>  > That would be easy to implement, and I agree it would be insanely great
>  > for many uses (especially if there are convenient key bindings for
>  > moving to adjacent tabs) -- I'd _love_ to have a "Gnus" tab, and a "Gdb"
>  > tab!
>  > 
>  > However that system would seem to essentially require making a tab to be
>  > an explicit user action, somewhat heavyweight.
>
> I don't agree, there seems to a direct correspondence with creating a new
> frame:

Er, but creating a new frame is an explicit user action, and somewhat
heavyweight...

-Miles

-- 
My books focus on timeless truths.  -- Donald Knuth

Re: Tabbed buffers

[Nick Roberts]

 > > I don't agree, there seems to a direct correspondence with creating a new
 > > frame:
 > 
 > Er, but creating a new frame is an explicit user action, and somewhat
 > heavyweight...

I'm not sure what you mean by heavyweight but it sounds negative.  If you just
mean the user must do something like press some keys or click the mouse then
that's true for most of Emacs.  If he would prefer a more passive experience
he really needs to find another activity like watching television.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Tabbed buffers

[Richard Stallman]

      So the behavior of display-buffer could be configured to
    either use the current window, or pop a new window, or pop a new tab or
    pop a new frame.

When a window has multiple tabs, only one of them is displayed at a time.
For most purposes, the non-current tabs can be ignored.
However, for purposes of displaying a buffer, switching tabs
could be one method `display-buffer' can use.

    For what it's worth, I think that if we introduce this notion of tab, we
    should change ttys to use tabs rather than frames since tty frames
    behave much more like tabs.  Of course multiple ttys would each get its
    own frame.

Tabs should be supported on ttys, but we should not get rid of the
current frame support on ttys.  The main reason we have frames on ttys
is to reduce the difference between handling of ttys and handling of
graphics displays.  People normally don't use multiple frames on ttys,
and that is ok, people can continue not to use them.  But getting rid
of them would just mean trouble.

Re: Tabbed buffers

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 26 Jan 2008 19:45:31 -0500
> Cc: nickrob@snap.net.nz, emacs-devel@gnu.org, miles@gnu.org
> 
> The main reason we have frames on ttys is to reduce the difference
> between handling of ttys and handling of graphics displays.  People
> normally don't use multiple frames on ttys, and that is ok, people
> can continue not to use them.

FWIW, I do use them on a tty, for several reasons.  One is to organize
my work: one frame for editing code, another for Info, etc.  Another
reason for several frames is when I read mail: one frame is used for
Rmail buffer, another for the *mail* buffer where I reply.

> But getting rid of them would just mean trouble.

I would certainly object.

Re: Tabbed buffers

[T. V. Raman]

1+ on that. Also with multitty now integrated, it's nice to be
able to open a frame on a tty that is talking to an emacs running
under X or more importantly the other way around, i.e. run emacs
under screen on a tty and then use emacsclient from X to open a frame.

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
    >> From: Richard Stallman <rms@gnu.org> Date: Sat, 26 Jan
    >> 2008 19:45:31 -0500 Cc: nickrob@snap.net.nz,
    >> emacs-devel@gnu.org, miles@gnu.org
    >> 
    >> The main reason we have frames on ttys is to reduce the
    >> difference between handling of ttys and handling of
    >> graphics displays.  People normally don't use multiple
    >> frames on ttys, and that is ok, people can continue not to
    >> use them.
    Eli> 
    Eli> FWIW, I do use them on a tty, for several reasons.  One
    Eli> is to organize my work: one frame for editing code,
    Eli> another for Info, etc.  Another reason for several
    Eli> frames is when I read mail: one frame is used for Rmail
    Eli> buffer, another for the *mail* buffer where I reply.
    Eli> 
    >> But getting rid of them would just mean trouble.
    Eli> 
    Eli> I would certainly object.
    Eli> 
    Eli> 
    Eli> _______________________________________________
    Eli> Emacs-devel mailing list Emacs-devel@gnu.org
    Eli> http://lists.gnu.org/mailman/listinfo/emacs-devel

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: Tabbed buffers

[Stefan Monnier]

> 1+ on that. Also with multitty now integrated, it's nice to be
> able to open a frame on a tty that is talking to an emacs running
> under X or more importantly the other way around, i.e. run emacs
> under screen on a tty and then use emacsclient from X to open a frame.

Nobody has ever talked about removing such features.


        Stefan

Re: Tabbed buffers

[Stefan Monnier]

>> But getting rid of them would just mean trouble.
> I would certainly object.

Richard was talking about a suggestion of mine, which was not to remove
the frame functionality on ttys.  How can people even expect me to
suggest throwing away such a feature?

All I was pointing out was that if we introduce frame-level tabs, then
it might make sense to treat the current "multiple-frames on a single tty"
as tabs rather than as frames.  So we may want to refine the notion of
tty frames so that each tty gets exactly 1 frame, and it can then
multiplex several tabs on that frame: the end result is the same
featureset as before, but in a way that more closely matches the
semantics of frames&tabs under GUIs (where only one of the tabs of
a frame can be displayed at a time, just like frames on a single tty).


        Stefan

Re: Tabbed buffers

[Robert J. Chassell]

    where only one of the tabs of a frame can be displayed at a time, just
    like frames on a single tty).

In a tty, using W3M mode, which works in but is not part of GNU Emacs,
I am able to view multiple windows, each with one lightweight tab
buffer visible in it.  I am not limited to one window per frame.

Why do differently with anything that displays a buffer, even one that
is part of a heavyweight tab set that uses two lines, one for the
frames and one for the buffers in the current frame?

Today's GNU Emacs CVS snapshot, Sun, 2008 Jan 27  11:02 UTC
GNU Emacs 23.0.50.48 (i686-pc-linux-gnu, GTK+ Version 2.12.1)

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Tabbed buffers

[Stefan Monnier]

>     where only one of the tabs of a frame can be displayed at a time, just
>     like frames on a single tty).

> In a tty, using W3M mode, which works in but is not part of GNU Emacs,
> I am able to view multiple windows, each with one lightweight tab
> buffer visible in it.  I am not limited to one window per frame.

I was talking about frame-level tabs, not window-level tabs.


        Stefan

Re: Tabbed buffers

[Richard Stallman]

    All I was pointing out was that if we introduce frame-level tabs, then
    it might make sense to treat the current "multiple-frames on a single tty"
    as tabs rather than as frames.

That seems like an unnecessary complication with no benefit.

Re: Tabbed buffers

[Stephen J. Turnbull]

Richard Stallman writes:

 >     All I was pointing out was that if we introduce frame-level
 >     tabs, then it might make sense to treat the current
 >     "multiple-frames on a single tty" as tabs rather than as
 >     frames.
 > 
 > That seems like an unnecessary complication with no benefit.

The benefit is that the tabs provide a visual cue (which many users
will have experience with) of what alternatives are available via
`next-tab' or `pop-to-tab'.

I don't think it is a good idea to think of tabs per se as associated
with any given content class.  They are a UI component, like any other
widget such as toolbar or radio button box (each of which is very
similar to a tab and could be used to simulate a tab control).

I think Alan's idea of a frameset (possibly implemented as Stefan
describes, but this area is conceptually hairy since a frame is the
biggest object Emacs deals with so tabs have to be *in* the frame,
while from the users' point of view it *acts like* multiple frames) is
probably the best default use of tabs.  Users will understand it
immediately.  Some will hate it for stealing precious screen real
estate, so there must be a way to turn it off.  But users new to Emacs
or to multitty will find it a convenient way to learn about that
facility.

Re: Tabbed buffers

[Stefan Monnier]

>> All I was pointing out was that if we introduce frame-level tabs,
>> then it might make sense to treat the current "multiple-frames on
>> a single tty" as tabs rather than as frames.
>> 
>> That seems like an unnecessary complication with no benefit.

> The benefit is that the tabs provide a visual cue (which many users
> will have experience with) of what alternatives are available via
> `next-tab' or `pop-to-tab'.

Actually, I was not even thinking of adding a "tabs line" to the
tty display.  I was talking about the elisp-level.


        Stefan

Re: Tabbed buffers

[Stephen J. Turnbull]

Stefan Monnier writes:

 > Actually, I was not even thinking of adding a "tabs line" to the
 > tty display.  I was talking about the elisp-level.

That doesn't make any sense to me.  What you're talking about then is
a (Emacs) window configuration.  Tabs are a UI component.

It would make sense to have tabs available as a UI to switch window
configurations in a frame, but tabs could also be used to switch
buffers in a window, to page through a long list (as with library
catalog cards if you're old enough to remember them), etc.  All of
these could be implemented as a separate display container structure
(presumably frame > tab > window > buffer), but I really don't think
the extra complexity would buy you anything more than the current
frame > window > buffer scheme.  And (possibly) it would be more
restrictive than a tabs as UI scheme, where the tabs could be attached
to various display container widgets (although I suppose Emacs, like
XEmacs, doesn't really take advantage of widgets very much).

Re: Tabbed buffers

[Stefan Monnier]

>> Actually, I was not even thinking of adding a "tabs line" to the
>> tty display.  I was talking about the elisp-level.

> That doesn't make any sense to me.  What you're talking about then is
> a (Emacs) window configuration.  Tabs are a UI component.

This is a completely theoretical discussion.

So take a few thousand steps back and look at (single)tty frames, X11
frames, and frame-level tabs.  Do tty frames look more like X11 frames
or like frame-level tabs?

To me they look like frame-level tabs: only one can be displayed at
a time, you can't "move" them, you can "resize" them, they're all
displayed at the same place, ...

That's all there is to it really.  That's all I was saying.

What we should do with this depends on way too many details to even
start talking about it before there's any resemblance of code to support
tabs somewhere.


        Stefan

Re: Tabbed buffers

[Stephen J. Turnbull]

Stefan Monnier writes:

 > What we should do with this depends on way too many details to even
 > start talking about it before there's any resemblance of code to support
 > tabs somewhere.

I gather XEmacs is "nowhere". ;-)  But if you decide you'd like to hear
the thoughts of somebody who has used and maintained tab control widgets
in Emacs, just let me know.  I think I know "somewhere" I can find one.

Re: Tabbed buffers

[Nick Roberts]

 > I gather XEmacs is "nowhere". ;-)  But if you decide you'd like to hear
 > the thoughts of somebody who has used and maintained tab control widgets
 > in Emacs, just let me know.  I think I know "somewhere" I can find one.

Does XEmacs have tabbed buffers in a tty?  I can't get them to appear.  In
fact their functionality seems very limited in an X window and even the
manual says that they are experimental.  The only way I've found to create
a second tab is by clicking on a link in a help buffer.  Can you please say
what functions are available to manipulate them?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Tabbed buffers

[Stephen J. Turnbull]

Nick Roberts writes:

 > Does XEmacs have tabbed buffers in a tty?  I can't get them to
 > appear.

No.  We have no GUI features in TTYs, no menus, no scrollbars, no
dialogs, no toolbars, no images.  Nobody has ever asked for them,
either, not even for compatibility with Emacs.

 > In fact their functionality seems very limited in an X window and
 > even the manual says that they are experimental.  The only way I've
 > found to create a second tab is by clicking on a link in a help
 > buffer.

To see what they do, try C-x C-f *.c in emacs/src/ (or maybe for
sanity's sake in lib-src).  The default configuration takes buffer
list and applies the filter "keep buffers whose major mode is the same
as the current mode", then truncates that list to at most ten tabs.

C-h a buffers-tab will tell you a list of functions and variables used
to implement the default configuration.

Re: Tabbed buffers

[Nick Roberts]

 > No.  We have no GUI features in TTYs, no menus, no scrollbars, no
 > dialogs, no toolbars, no images.  Nobody has ever asked for them,
 > either, not even for compatibility with Emacs.

AFAIK Emacs only has a menu-bar in a tty.

 >  > In fact their functionality seems very limited in an X window and
 >  > even the manual says that they are experimental.  The only way I've
 >  > found to create a second tab is by clicking on a link in a help
 >  > buffer.
 > 
 > To see what they do, try C-x C-f *.c in emacs/src/ (or maybe for
 > sanity's sake in lib-src).  The default configuration takes buffer
 > list and applies the filter "keep buffers whose major mode is the same
 > as the current mode", then truncates that list to at most ten tabs.

If I do C-x C-f *.c in XEmacs I only get one empty buffer called *.c
(21.4 (patch 19) "Constant Variable" XEmacs Lucid)

 > C-h a buffers-tab will tell you a list of functions and variables used
 > to implement the default configuration.

There appear to be no functions that put a file/display a buffer in a new tab,
delete a tab etc.

Also, unlike Eclipse there is just one gutter per frame, which appears to
be shared by all the buffers in that frame, just displaying the tabs for
the one selected.  When a tab is selected it moves to the left, not just to
the front.  They don't appear to be part of a toolkit but built from one.
Now that toolkits like GTK provide tabs as widgets, I presume they might
be easier to add to Emacs.



-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Tabbed buffers

[Stephen J. Turnbull]

Nick Roberts writes:

 > If I do C-x C-f *.c in XEmacs I only get one empty buffer called *.c
 > (21.4 (patch 19) "Constant Variable" XEmacs Lucid)

Oh.  I guess globbing in C-x C-f was added in the 21.5 series.  Sorry.
Then do it by hand.  Then do some Makefiles and the like.  Notice what
tabs appear according to the current buffer.

This behavior is highly configurable; filter-on-mode is just the
default (and only built-in) behavior.

 >  > C-h a buffers-tab will tell you a list of functions and variables used
 >  > to implement the default configuration.
 > 
 > There appear to be no functions that put a file/display a buffer in
 > a new tab, delete a tab etc.

Nope.  That's not how they're used.  That could be done, but it wasnt.

 > Also, unlike Eclipse there is just one gutter per frame, which
 > appears to be shared by all the buffers in that frame, just
 > displaying the tabs for the one selected.

In the default configuration, yes.

 > When a tab is selected it moves to the left, not just to the front.

Actually, that should not happen if you use the GUI (ie, click on the
tab).  (Or maybe that too is a bug fixed in 21.5.)  That is an
artifact of the underlying implementation which recomputes the tabs
each time the buffer displayed changes via switch-to-buffer.

 > They don't appear to be part of a toolkit but built from one.  Now
 > that toolkits like GTK provide tabs as widgets, I presume they
 > might be easier to add to Emacs.

That depends on whether you insist that they be cross-platform or not.
Native GTK widgets and native Windose widgets (not that they deserve
the name, as I understand it) require quite different kinds of TLC,
which conflict is an unending source of bugs if you try to provide a
flexible implementation with Lisp callbacks that works on both
platforms.  At least, that is our experience.

Re: Tabbed buffers

[Richard Stallman]

    > The benefit is that the tabs provide a visual cue (which many users
    > will have experience with) of what alternatives are available via
    > `next-tab' or `pop-to-tab'.

    Actually, I was not even thinking of adding a "tabs line" to the
    tty display.  I was talking about the elisp-level.

The whole point of a tabs feature is to have the tabs line, isn't it?

Re: Tabbed buffers

[Bastien Guerry]

Richard Stallman <rms@gnu.org> writes:

>     > The benefit is that the tabs provide a visual cue (which many users
>     > will have experience with) of what alternatives are available via
>     > `next-tab' or `pop-to-tab'.
>
>     Actually, I was not even thinking of adding a "tabs line" to the
>     tty display.  I was talking about the elisp-level.
>
> The whole point of a tabs feature is to have the tabs line, isn't it?

I use tabs without using the tab line, which consumes to much space.

I use tabs as provided by elscreen:

  http://www.morishima.net/~naoto/software/elscreen/

And I set `elscreen-display-tab' to make tabs invisible.

I can still switch from one tab to another: in this case, a tab is
really just a window configuration, but switching from one window
configuration to another one without having to store them is quite
handy.  

-- 
Bastien

Re: Tabbed buffers

[Richard Stallman]

    I can still switch from one tab to another: in this case, a tab is
    really just a window configuration, but switching from one window
    configuration to another one without having to store them is quite
    handy.  

It sounds like, in your usage, this is just a way
to save and name window configurations.  Is that right?

Re: Tabbed buffers

[Bastien Guerry]

Richard Stallman <rms@gnu.org> writes:

>     I can still switch from one tab to another: in this case, a tab is
>     really just a window configuration, but switching from one window
>     configuration to another one without having to store them is quite
>     handy.  
>
> It sounds like, in your usage, this is just a way
> to save and name window configurations.  Is that right?

Right but not complete.  

I use elscreen mainly to *cycle* through tabs (i.e. to cycle through
window configurations) and to open a new tab when needed.

It seems to me that, in this discussion, we should really talk about
"workspaces" - not "tabs".  Or at least we could disambiguate these and
use "tab" for the visual UI feature and "workspace" for the underlying
window configuration (and the properties we would like to attach to it.)

I use elscreen to easily *cycle* through workspaces and to easily
*create* new ones.

Having "workspaces" (or whatever you want to call them) would be very
useful for letting variables be local to them.  For example I use this:

  (make-variable-buffer-local 'search-ring)

but this would make more sense in a workspace rather than in a buffer.

Or see the function `erc-iswitchb': it restricts the list of buffers to
the one that are used by ERC.  I've implemented something like this for
Org as well.  If you use ERC in a dedicated workspace, then the notion
of "ERC buffers" is really an instance of the more general notion of
"This workspace buffers."

-- 
Bastien

Re: Tabbed buffers

[Richard Stallman]

     >     All I was pointing out was that if we introduce frame-level
     >     tabs, then it might make sense to treat the current
     >     "multiple-frames on a single tty" as tabs rather than as
     >     frames.
     > 
     > That seems like an unnecessary complication with no benefit.

    The benefit is that the tabs provide a visual cue (which many users
    will have experience with) of what alternatives are available via
    `next-tab' or `pop-to-tab'.

That benefit comes from having the feature of tabs.
I think it is a good idea to add that feature.

But you are talking about something else: to treat the current
"multiple-frames on a single tty" as tabs rather than as frames.  That
has nothing to do with the benefits tabs provide, and I don't see how
it would provide any benefit.  It would just create an unnecessary
loss of parallelism between the tty case and the graphical display
case, right?

Perhaps you should state your proposal more concretely and precisely.

Re: Tabbed buffers

[Stephen J. Turnbull]

Richard Stallman writes:

 > But you are talking about something else:

Wrong "you".  Stefan is the guy who proposed the analogy of tty frames
to tabs.

I'm simply proposing that a tab control widget would be a useful
addition.  Specifically it allows one-click switching of the entire
content of a rectangular area, under control of a per-tabset Lisp
callback which takes the particular tab as an argument.  This could be
implemented as a GUI window (where available) or as a stripped-down
Emacs frame.  XEmacs instead allows a general callback which could
actually do anything, but by default uses switch-to-buffer.

My feeling is that tabs could be a useful alternative to the buffers
menu if attached to an Emacs window, but I have no experience with
that (XEmacs doesn't support that, at least, I don't know how to make
it happen).

What XEmacs does by default is attach tabs to each Emacs frame as an
always-visible alternative to the buffers menu, containing a
configurable selection of buffers.  The default filter collects all
the buffers in the same major mode as the buffer in the selected
window, but it's easy to use any other predicate, such as all buffers
visiting files in the same directory, all buffers with the same
name-sans-extension, etc.

If a frame contains multiple windows, the buffers tab refers to the
buffer in the selected window and other buffers in the same mode.
I find this implementation mildly awkward, rarely useful, and am
always amazed at how pleased newbies are to have this feature. ;-)
It's quite popular, actually.

Re: Tabbed buffers

[Richard Stallman]

     > But you are talking about something else:

    Wrong "you".  Stefan is the guy who proposed the analogy of tty frames
    to tabs.

Ok.  In any case, that is the proposal I was criticizing.

    I'm simply proposing that a tab control widget would be a useful
    addition.  Specifically it allows one-click switching of the entire
    content of a rectangular area, under control of a per-tabset Lisp
    callback which takes the particular tab as an argument.

It sounds good to me.  It is easy except for the GUI part.

    What XEmacs does by default is attach tabs to each Emacs frame as an
    always-visible alternative to the buffers menu, containing a
    configurable selection of buffers.

I think tabs should operate at frame level
and each tab should be a window configuration.

Re: Tabbed buffers

[T. V. Raman]

Doing this on Linux would also have the nice side-effect of
allowing tty users to place  each frameset on a different virtual
console, something which would make it  easier to logically
separate out frames.

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:
    >>> But getting rid of them would just mean trouble.
    >> I would certainly object.
    Stefan> 
    Stefan> Richard was talking about a suggestion of mine, which
    Stefan> was not to remove the frame functionality on ttys.
    Stefan> How can people even expect me to suggest throwing
    Stefan> away such a feature?
    Stefan> 
    Stefan> All I was pointing out was that if we introduce
    Stefan> frame-level tabs, then it might make sense to treat
    Stefan> the current "multiple-frames on a single tty" as tabs
    Stefan> rather than as frames.  So we may want to refine the
    Stefan> notion of tty frames so that each tty gets exactly 1
    Stefan> frame, and it can then multiplex several tabs on that
    Stefan> frame: the end result is the same featureset as
    Stefan> before, but in a way that more closely matches the
    Stefan> semantics of frames&tabs under GUIs (where only one
    Stefan> of the tabs of a frame can be displayed at a time,
    Stefan> just like frames on a single tty).
    Stefan> 
    Stefan> 
    Stefan>         Stefan
    Stefan> 
    Stefan> 
    Stefan> _______________________________________________
    Stefan> Emacs-devel mailing list Emacs-devel@gnu.org
    Stefan> http://lists.gnu.org/mailman/listinfo/emacs-devel

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: Tabbed buffers

[Richard Stallman]

    Doing this on Linux would also have the nice side-effect of
    allowing tty users to place  each frameset on a different virtual
    console, something which would make it  easier to logically
    separate out frames.

I don't follow that.

Re: Tabbed buffers

[T. V. Raman]

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:
    Richard>     Doing this on Linux would also have the nice
    Richard> side-effect of allowing tty users to place each
    Richard> frameset on a different virtual console, something
    Richard> which would make it easier to logically separate out
    Richard> frames.
    Richard> 
    Richard> I don't follow that.

I run exclusively on the console, ie no X.
I hve lots of buffers open, and prefer to organize them in
frames, with  ech frame holding related buffers.

If I could place each frame on a separate virtual console where
I'm already logged in,
then I could switch among those frames by hitting alt-f<n>, and
then use emacs' buffer switching commands in that frame to manage
the  orde rin which buffers are cycled through in that particular
frame.

At present I move among frames by naming them first; but if I
forget to move to the named frame first, then I end up with
buffers that I'd ideally leave in one frame getting accessed in another.

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: Tabbed buffers

[Richard Stallman]

    If I could place each frame on a separate virtual console where
    I'm already logged in,
    then I could switch among those frames by hitting alt-f<n>, and

It should be possible to set this up using the current trunk version
of Emacs, since it can open multiple ttys.  You'll have to do a certain
amount of work to make it run, but with luck you don't have to change
the C code, only the Lisp.

I would guess that you need to set up /etc/inittab so that the other
ttys have nothing running on them.  That way Emacs will be able to
open them and use them.

Using several frames on TTYs, switching them, terminology: [Is also: Tabbed buffers]

[Alan Mackenzie]

'Evening, Richard and Stefan!

On Sat, Jan 26, 2008 at 07:45:31PM -0500, Richard Stallman wrote:

[Stefan:]
>     For what it's worth, I think that if we introduce this notion of
>     tab, we should change ttys to use tabs rather than frames since
>     tty frames behave much more like tabs.  Of course multiple ttys
>     would each get its own frame.

Er, what does a C-i look like on a TTY?  Why are we using this word
"tab" to denote something other than the <tab> key or ASCII 0x09?
Haven't we got enough confusion already with "windows" (emacs) and
"windows" (X) aka "frames"?

I'm not that familiar with the concept of "tabs", but I guess the word
came by analogy from the ~1 inch wide bit of card protruding from the
top of a cardboard index card.  Such would not be displayed on a TTY (or
would it?), so the term "tab" would be doubly unfortunate.

Again, why the word "tab"?  The display stratagem seems redundant -
we've already got frames and windows - so, would it not be a better idea
to have @def{frame sets}, a collection of frames displayed in the same
place, any one of which can be selected by its tab?  Perhaps we could
call this a "glazing" instead, analogous to "double glazing" and "triple
glazing".  This more appropriate word would fit TTYs better.  :-)

Seriously, though, aren't GUI screens cluttered enough already, without
introducing yet another space-taker-upper, even if it could be switched
off?  (Don't forget the ruckus that the unswitchoffable fringe caused
when Emacs 21 was released in 2001.)

> Tabs should be supported on ttys, but we should not get rid of the
> current frame support on ttys.  The main reason we have frames on ttys
> is to reduce the difference between handling of ttys and handling of
> graphics displays.  People normally don't use multiple frames on ttys,

Says who?  I very rarely have fewer than 4 or 5 frames open in my TTY
Emacs.

Actually, you may be right.  The mechanism for switching frames (C-x 5
o, repeated ad nauseam till you finally reach the frame you're looking
for) is so broken as to be unusable, at least for me.  So most TTY users
probably don't bother.  I've solved the problem by making the function
key <F1> switch to frame F1, and so on, not being that bothered about
2-column, and so on.  Maybe the so-far unused bindings C-x <F1>, etc.,
could be used for these in a standard Emacs.

> and that is ok, people can continue not to use them.  But getting rid
> of them would just mean trouble.

Too damn right it would!  I'd start screaming!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Using several frames on TTYs, switching them, terminology: [Is also: Tabbed buffers]

[Eli Zaretskii]

> Date: Sun, 27 Jan 2008 19:55:38 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: nickrob@snap.net.nz, miles@gnu.org, emacs-devel@gnu.org
> 
> Actually, you may be right.  The mechanism for switching frames (C-x 5
> o, repeated ad nauseam till you finally reach the frame you're looking
> for) is so broken as to be unusable, at least for me.

A solution has been in existence for that problem for a very long
time: give your frame a name with "M-x set-frame-name RET FOO RET",
then select it with "M-x select-frame-by-name RET FOO RET".  Puff!
problem gone.

Re: Using several frames on TTYs, switching them, terminology: [Is also: Tabbed buffers]

[Alan Mackenzie]

Hi, Eli!

On Sun, Jan 27, 2008 at 10:52:19PM +0200, Eli Zaretskii wrote:
> > Date: Sun, 27 Jan 2008 19:55:38 +0000
> > From: Alan Mackenzie <acm@muc.de>

> > The mechanism for switching frames (C-x 5 o, repeated ad nauseam till
> > you finally reach the frame you're looking for) is so broken as to be
> > unusable, at least for me.

> A solution has been in existence for that problem for a very long time:
> give your frame a name with "M-x set-frame-name RET FOO RET", then
> select it with "M-x select-frame-by-name RET FOO RET".  Puff!  problem
> gone.

Hmm.  I'm not imaginative enough with names.  ;-)  Having to keep coming
up with names for new frames (probably, by putting the question in
after-make-frame-functions) would be intolerably annoying.

The names F1, F2, .... are good enough for me, and even match the names
of the keys used to switch to them.  :-)  Trouble is, these names don't
seem to be used on GUI Emacs (which I have to use at work).  So there,
I've enhanced my mode line to display the "Fn".

Obviously, select-frame-by-name would need a binding if you were using it
all the time.  select-frame-by-number would be quite handy too, but even
that would be too slow for me, even assuming a numeric prefix argument
and a single-key binding.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Using several frames on TTYs, switching them, terminology: [Is also: Tabbed buffers]

[Eli Zaretskii]

> Date: Sun, 27 Jan 2008 21:33:15 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > A solution has been in existence for that problem for a very long time:
> > give your frame a name with "M-x set-frame-name RET FOO RET", then
> > select it with "M-x select-frame-by-name RET FOO RET".  Puff!  problem
> > gone.
> 
> Hmm.  I'm not imaginative enough with names.  ;-)  Having to keep coming
> up with names for new frames (probably, by putting the question in
> after-make-frame-functions) would be intolerably annoying.
> 
> The names F1, F2, .... are good enough for me

You don't _have_ to invent names if you have no trouble remembering
which one of them holds what.  select-frame-by-name is happy with the
Fn names as well.

I usually name the frames by what I'm doing there: "Mail" for reading
mail, "Foo" for some project Foo I'm working on, etc.  But that's me.

> Obviously, select-frame-by-name would need a binding if you were using it
> all the time.

Me, I don't need any binding: command history is good enough in that I
never have to type the command's name more than once.  But if you need
a binding, by all means do it.

> select-frame-by-number would be quite handy too

It would only save you one keystroke (2 vs F2 with selection by name),
and would be unreliable, since a frame can be given any name, not just
Fn.

> but even that would be too slow for me, even assuming a numeric
> prefix argument and a single-key binding.

Look, this subthread started with your complaint about the need to
step through all the frames with "C-x 5 o" repeated ad nauseam.
Surely, what I suggested is faster than that!

Re: Using several frames on TTYs, switching them, terminology: [Is also: Tabbed buffers]

[T. V. Raman]

and I can vouch for this, it  works well.
I use it all  the time

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
    >> Date: Sun, 27 Jan 2008 19:55:38 +0000 From: Alan Mackenzie
    >> <acm@muc.de> Cc: nickrob@snap.net.nz, miles@gnu.org,
    >> emacs-devel@gnu.org
    >> 
    >> Actually, you may be right.  The mechanism for switching
    >> frames (C-x 5 o, repeated ad nauseam till you finally
    >> reach the frame you're looking for) is so broken as to be
    >> unusable, at least for me.
    Eli> 
    Eli> A solution has been in existence for that problem for a
    Eli> very long time: give your frame a name with "M-x
    Eli> set-frame-name RET FOO RET", then select it with "M-x
    Eli> select-frame-by-name RET FOO RET".  Puff!  problem gone.
    Eli> 
    Eli> 
    Eli> _______________________________________________
    Eli> Emacs-devel mailing list Emacs-devel@gnu.org
    Eli> http://lists.gnu.org/mailman/listinfo/emacs-devel

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: Using several frames on TTYs, switching them, terminology: [Is also: Tabbed buffers]

[Stefan Monnier]

>> and that is ok, people can continue not to use them.  But getting rid
>> of them would just mean trouble.
> Too damn right it would!  I'd start screaming!

Hello?  It's me!
Do you really think I'd suggest to plainly throw away tty frames?
Seriously?


        Stefan

Re: Using several frames on TTYs, switching them, terminology: [Is also: Tabbed buffers]

[Alan Mackenzie]

'Evening, Stefan!

On Sun, Jan 27, 2008 at 04:13:29PM -0500, Stefan Monnier wrote:
> >> and that is ok, people can continue not to use them.  But getting rid
> >> of them would just mean trouble.
> > Too damn right it would!  I'd start screaming!

> Hello?  It's me!
> Do you really think I'd suggest to plainly throw away tty frames?
> Seriously?

No, of course not, not you!  It was actually Richard who brought the
issue up, but he wouldn't get rid of them either.

People sometimes express the opinion that TTYs have been superseded by
GUIs, sometimes they express it forcefully, and sometimes offensively
(though this hasn't happened on this thread).  It doesn't hurt,
sometimes, to remind people that this is not the case.

>         Stefan

-- 
Alan Mackenzie (Nuremnberg, Germany).

Re: Using several frames on TTYs, switching them, terminology: [Is also: Tabbed buffers]

[Stefan Monnier]

Hi Alan,

> People sometimes express the opinion that TTYs have been superseded by
> GUIs, sometimes they express it forcefully, and sometimes offensively
> (though this hasn't happened on this thread).  It doesn't hurt,
> sometimes, to remind people that this is not the case.

Don't worry: the seriousness with which the multi-tty effort has been
taken is proof that tty support is in no way "on the way out".


        Stefan

Re: Using several frames on TTYs, switching them, terminology: [Is also: Tabbed buffers]

[Richard Stallman]

    Again, why the word "tab"?

Because that's the word they are generally called, in regard to
browsers for instance, and what most computer users will know.

				The display stratagem seems redundant -
    we've already got frames and windows - so, would it not be a better idea
    to have @def{frame sets}, a collection of frames displayed in the same
    place, any one of which can be selected by its tab?

That's not what a tab should do.  Tabs should operate within a frame.

Re: Using several frames on TTYs, switching them, terminology: [Is also: Tabbed buffers]

[David De La Harpe Golden]

On 28/01/2008, Richard Stallman <rms@gnu.org> wrote:
>     Again, why the word "tab"?
>
> Because that's the word they are generally called, in regard to
> browsers for instance, and what most computer users will know.
>

Heh. Maybe should rename [emacs] frames to windows and [emacs] windows
to panes, too. :-)

>> The display stratagem seems redundant  - we've already got frames
>> and windows - so, would it not be a better idea  to have @def{frame
>> sets}, a collection of frames displayed in the same place, any one of
>> which can be selected by its tab?
>
> That's not what a tab should do.  Tabs should operate within a frame.
>

[using emacs terminology]:

(i) I think by "a collection of frames in the same place" was meant
tabs switching between frame contents i.e. sets of windows?  They'd be
in the one "physical" frame, tabs would select different window
configurations i.e. "virtual" frames.  That sounds a bit like
latter-day-IDE "views" being tabbed.
Of course, winner-mode already exists. Maybe emacs just needs to
expose general tab bar widgets that winner-mode could then use...

(ii) IIRC clicking XEmacs "buffer-tabs"  widgets in its "gutters"
switches between the buffers in the current window of the current
frame though:
http://www.xemacs.org/Documentation/21.5/html/xemacs_4.html#SEC16

While the (i) might be useful I think (ii) is probably what
people would expect  tabs to do if implemented in GNU Emacs
(especially since it's what XEmacs already does...).  Would rapidly
become unwieldy for large buffer counts though.  Then again, the menu
and toolbar are totally unwieldy for large command counts and probably
rapidly get turned off by many advanced emacs users, just as the
buffer-tabs would.

(You _could_ have both (i) and (ii), really.  Would probably look
quite cluttered  though. Of course maybe the GUI clutter of an IDE
with [nonemacs terminology] a zillion tabbed panes holding tabbed
panes of tabbed panes (and let's not forget the customary tabbed panes
that are too big to fit in the enclosing pane and thus induce
horizontal and vertical scrollbars - bleurgh) is what people really
/miss/ in emacs :-) )

Re: Using several frames on TTYs, switching them, terminology: [Is also: Tabbed buffers]

[Richard Stallman]

    > Because that's the word they are generally called, in regard to
    > browsers for instance, and what most computer users will know.

    Heh. Maybe should rename [emacs] frames to windows and [emacs] windows
    to panes, too. :-)

That might be good if it were not for the painful incompatibility that
would mean.

Since we have no tabs, now, we have no existing name for them.
There is no obstacle to using the generally known name.

Re: Tabbed buffers

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Sat, 26 Jan 2008 07:40:42 +0900
> Cc: emacs-devel@gnu.org
> 
> Nick Roberts <nickrob@snap.net.nz> writes:
> > Eclipse gets round this problem by displaying tabbed panes.  I know
> > that you can do something like this in Emacs using tabbar.el.
> > Nowadays though, many applications, e.g., Firefox, use the underlying
> > toolkit for this.  I wonder if we should add such a feature to Emacs
> > at the C level, at least for GTK.
> 
> It seems like it would need some thought to work well in Emacs, as
> tabbed user interfaces quickly become unusable if there lots of tabs,
> and Emacs buffer counts are quite often _way_ over that threshold.

How about using the tool-bar infrastructure for that?  We could have a
second tool-bar line, below the usual one, with buttons for buffers.
When buttons are too many to display in a single line, we could add
another line, etc.  Alternatively, when there are too many buttons to
fit on a single line, we display a "More..." button that would pop up
a menu of the rest; those that get their own buttons would then be
maintained on some kind of LRU basis.

Re: Tabbed buffers

[Robert J. Chassell]

W3M mode, which works in but is not part of GNU Emacs, has optional
tabbed buffers for different browsing sessions.  You might look at
them.

The tabbed buffers are within an existing *w3m* buffer, so you can
have both a normal buffer, such as an RMAIL buffer in one part of a
frame and several W3M mode tabbed buffers in what looks like a single
*w3m* buffer in another part of that frame.

    http://emacs-w3m.namazu.org/

    cvs -d:pserver:anonymous@cvs.namazu.org:/storage/cvsroot co emacs-w3m

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Tabbed buffers

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sat, 26 Jan 2008 10:57:14 +1300
> 
> On help-gnu-emacs, Per Nordlöw has asked about showing the threads view by
> default in gdb-ui.  The problem is trying to fit so many windows in a single
> frame.

For that specific problem, you could put each thread's info in a
separate set of GUD buffers, and have a gdb-ui command to switch them
all in lockstep.

Re: Tabbed buffers

[Nick Roberts]

 > > On help-gnu-emacs, Per Nordlöw has asked about showing the threads view by
 > > default in gdb-ui.  The problem is trying to fit so many windows in a
 > > single frame.
 > 
 > For that specific problem, you could put each thread's info in a
 > separate set of GUD buffers, and have a gdb-ui command to switch them
 > all in lockstep.

I thought lockstep referred to stepping all threads together.  

Anyway, I am thinking of using a separate multi-window frame for each thread
with indirect buffers for the source, but it would still need the threads
buffer to be initially visible.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Tabbed buffers

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sun, 27 Jan 2008 13:12:47 +1300
> Cc: emacs-devel@gnu.org
> 
>  > > On help-gnu-emacs, Per Nordlöw has asked about showing the threads view by
>  > > default in gdb-ui.  The problem is trying to fit so many windows in a
>  > > single frame.
>  > 
>  > For that specific problem, you could put each thread's info in a
>  > separate set of GUD buffers, and have a gdb-ui command to switch them
>  > all in lockstep.
> 
> I thought lockstep referred to stepping all threads together.  

Do I have to apologize that English is not my first language?

> Anyway, I am thinking of using a separate multi-window frame for each thread
> with indirect buffers for the source

Multiple frames would be a nuisance in gdb-ui, since many users (at
least many that I witnessed) make Emacs full-screen when they use
gdb-ui, because otherwise it's hard to see enough stuff in each one of
the 6 windows.  That is why I suggested to reuse the same windows for
the other threads.

Re: Tabbed buffers

[Nick Roberts]

 > >  > For that specific problem, you could put each thread's info in a
 > >  > separate set of GUD buffers, and have a gdb-ui command to switch them
 > >  > all in lockstep.
 > > 
 > > I thought lockstep referred to stepping all threads together.  
 > 
 > Do I have to apologize that English is not my first language?

I didn't follow what you were saying as lockstep has a special meaning when
debugging multi-threaded programs - that's all.  I now think/see you are just
saying replace all the windows for one thread with those for another.

 > > Anyway, I am thinking of using a separate multi-window frame for each
 > > thread with indirect buffers for the source
 > 
 > Multiple frames would be a nuisance in gdb-ui, since many users (at
 > least many that I witnessed) make Emacs full-screen when they use
 > gdb-ui, because otherwise it's hard to see enough stuff in each one of
 > the 6 windows.  That is why I suggested to reuse the same windows for
 > the other threads.

Do you think then that tabbed buffers, as Richard proposes, might provide a
solution, with one tab per thread and multiple windows per tab.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Is there any document about Emacs implementation (C source code)?

[brianjiang]

Hi,

I'd like to do some studying of Emacs C source code? I wonder if there
are any existing introduction documents about the Emacs internal
implementation?

Thanks,
Brian

Re: Is there any document about Emacs implementation (C source code)?

[dhruva]

Yes, the source code. I go through the same problem everytime i muster
enough courage to implement something in emacs.
A book on crafting an editor has lot of references to emacs but does
not give you the guts of emacs.
There is however an Xemacs internals which might have a lot in common
to emacs, not sure though (written by Ben Wing)

-dky

On 1/27/08, brianjiang@gdnt.com.cn <brianjiang@gdnt.com.cn> wrote:
> Hi,
>
> I'd like to do some studying of Emacs C source code? I wonder if there
> are any existing introduction documents about the Emacs internal
> implementation?
>
> Thanks,
> Brian
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>

-- 
Sent from Gmail for mobile | mobile.google.com

Contents reflect my personal views only!

Re: Is there any document about Emacs implementation (C source code)?

[Stephen J. Turnbull]

dhruva writes:
 > Yes, the source code. I go through the same problem everytime i muster
 > enough courage to implement something in emacs.
 > A book on crafting an editor has lot of references to emacs but does
 > not give you the guts of emacs.
 > There is however an Xemacs internals which might have a lot in common
 > to emacs, not sure though (written by Ben Wing)

http://www.xemacs.org/Documentation/21.5/html/internals.html

There are many things that are done differently in XEmacs from Emacs.
However important things like the DEFUN macro are very similar.
Also, I believe that although the implementations are different, the
overview of things like the read-eval-print/read-eval-redisplay loop
will be useful to any new Emacs developer.

 > 
 > -dky
 > 
 > On 1/27/08, brianjiang@gdnt.com.cn <brianjiang@gdnt.com.cn> wrote:
 > > Hi,
 > >
 > > I'd like to do some studying of Emacs C source code? I wonder if there
 > > are any existing introduction documents about the Emacs internal
 > > implementation?
 > >
 > > Thanks,
 > > Brian
 > >
 > >
 > > _______________________________________________
 > > Emacs-devel mailing list
 > > Emacs-devel@gnu.org
 > > http://lists.gnu.org/mailman/listinfo/emacs-devel
 > >
 > 
 > -- 
 > Sent from Gmail for mobile | mobile.google.com
 > 
 > Contents reflect my personal views only!
 > 
 > 
 > _______________________________________________
 > Emacs-devel mailing list
 > Emacs-devel@gnu.org
 > http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Is there any document about Emacs implementation (C source code)?

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Mon, 28 Jan 2008 05:32:11 +0900
> Cc: brianjiang@gdnt.com.cn, emacs-devel@gnu.org
> 
> There are many things that are done differently in XEmacs from Emacs.
> However important things like the DEFUN macro are very similar.

DEFUN is explained in the Emacs's ELisp manual as well (see the node
"Writing Emacs Primitives").

The rest of the "GNU Emacs Internals" appendix describes the internals
of several Emacs objects, and a few other things, but leaves out quite
a few important mechanisms, such as the display engine.

Re: Tabbed buffers

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sun, 27 Jan 2008 17:48:32 +1300
> Cc: emacs-devel@gnu.org
> 
> Do you think then that tabbed buffers, as Richard proposes, might provide a
> solution, with one tab per thread and multiple windows per tab.

Yes, probably.