Two GTK related feature requests

Two GTK related feature requests

[Simon Josefsson]

* "Tabbed editing".  People using modern web browsers will know what I
  mean.  It is very addictive.  Essentially it would add buttons at
  the top of the Emacs window, one button for each buffer.  Clicking
  on one button will change focus to that buffer.  Each tab may also
  have a X button that kill that buffer.  There are several details to
  be sorted out, e.g., should the tab be per-window or per-frame?  Per
  frame is more traditional, but per-window might be useful.  I
  suspect GTK have read-made widgets for tabbed applications.

* Elisp GTK bindings.  To be able to build good user interfaces from
  elisp, some kind of access to GTK directly from Elisp would be
  necessary.  Some of the GTK widgets would be very useful in, e.g.,
  Gnus.

Alas, I don't have time to implement these, but thought I should
mention them.

Re: Two GTK related feature requests

[Masatake YAMATO]

> * "Tabbed editing".  People using modern web browsers will know what I
>   mean.  It is very addictive.  Essentially it would add buttons at
>   the top of the Emacs window, one button for each buffer.  Clicking
>   on one button will change focus to that buffer.  Each tab may also
>   have a X button that kill that buffer.  There are several details to
>   be sorted out, e.g., should the tab be per-window or per-frame?  Per
>   frame is more traditional, but per-window might be useful.  I
>   suspect GTK have read-made widgets for tabbed applications.

Try this one.
http://www.jamespo.org.uk/weblog/archives/tabbar.el

Re: Two GTK related feature requests

[Simon Josefsson]

Masatake YAMATO <jet@gyve.org> writes:

>> * "Tabbed editing".  People using modern web browsers will know what I
>>   mean.  It is very addictive.  Essentially it would add buttons at
>>   the top of the Emacs window, one button for each buffer.  Clicking
>>   on one button will change focus to that buffer.  Each tab may also
>>   have a X button that kill that buffer.  There are several details to
>>   be sorted out, e.g., should the tab be per-window or per-frame?  Per
>>   frame is more traditional, but per-window might be useful.  I
>>   suspect GTK have read-made widgets for tabbed applications.
>
> Try this one.
> http://www.jamespo.org.uk/weblog/archives/tabbar.el

Excellent!  Thanks.

So the first feature request collapse into the second one: having
elisp GTK bindings.  Then tabbar.el could use the standard GTK widget
for the tabs.  I think it is important to use standard widgets for
standard operations.  It give a consistent user interface across all
GTK applications.  Application-specific user interface designs have a
greater learning curve.

Re: Two GTK related feature requests

[David PONCE]

> Try this one.
> http://www.jamespo.org.uk/weblog/archives/tabbar.el

The latest version is available at <http://sf.net/projects/emhacks>.

David

Re: Two GTK related feature requests

[Richard Stallman]

    * "Tabbed editing".  People using modern web browsers will know what I
      mean.  It is very addictive.  Essentially it would add buttons at
      the top of the Emacs window, one button for each buffer.  Clicking
      on one button will change focus to that buffer.  Each tab may also
      have a X button that kill that buffer.  There are several details to
      be sorted out, e.g., should the tab be per-window or per-frame?

It is clear how this would work when you have just a few buffers, but
what about when you have 50?  We need to finish designing this feature
before implementing it.

Re: Two GTK related feature requests

[Simon Josefsson]

Richard Stallman <rms@gnu.org> writes:

>     * "Tabbed editing".  People using modern web browsers will know what I
>       mean.  It is very addictive.  Essentially it would add buttons at
>       the top of the Emacs window, one button for each buffer.  Clicking
>       on one button will change focus to that buffer.  Each tab may also
>       have a X button that kill that buffer.  There are several details to
>       be sorted out, e.g., should the tab be per-window or per-frame?
>
> It is clear how this would work when you have just a few buffers, but
> what about when you have 50?  We need to finish designing this feature
> before implementing it.

Right.

I have been using tabbar.el for a while now, and it appear to have
discovered this problem as well.  The solution it uses is to group
different kind of buffers together and only show tabs for those
buffers.  So if you are in a C mode buffer, you only see tabs for C
mode buffers.  Etc.  You can press a special button to go to the
top-level scope and list meta-groups, e.g. 'Mail', 'C', 'Common',
'Help'.

It might be usable approach, but tabbar.el break C-x b RET in some
cases, e.g. switching between a mail buffer and a C mode buffer.  C-x
b RET will only switch between the last used buffer within the current
scope, i.e. mail-to-mail or c-to-c.  C-x b RET will never cross the
scope (unless, I guess, the scope only contain one buffer).  Because
of this, I'll likely stop using it soon.

Re: Two GTK related feature requests

[Luc Teirlinck]

Does C-Mouse-1 not do what you want, except that one does not stare at
that information all the time, but why would one want to be staring at
it all the time, instead of just when one needs it?

Sincerely,

Luc.

Re: Two GTK related feature requests

[Robert J. Chassell]

    * "Tabbed editing".  People using modern web browsers will know what I
      mean.  It is very addictive.  Essentially it would add buttons at
      the top of the Emacs window, one button for each buffer.  Clicking
      on one button will change focus to that buffer.  ...

To try this out, I am using tabbar.el from

    http://unc.dl.sourceforge.net/sourceforge/emhacks/tabbar-1.3.tar.gz

The user interface created by tabbar.el does not scale.

Right now I have 41 open buffers, which is fewer than usual.  To see
the various groups of files, I need a window width of 125 characters

To see the file names in just the `text' group, I need a window that
is 147 characters wide.  My normal window width is the conventional 80
characters.

The `tabbed editing' notion is interesting but I am not sure that any
of the obvious solutions work in the long run.  For example, one could
fill the tab line when needed, so that characters to the right of the
fill-column are moved down to another line.  But this suggestion uses
up screen real estate.

Newbies will say that they never keep more than a dozen buffers open
at once and that the current method will work for them -- but it is
awkward to design features that work for newbies and fail as the
newbies become more expert.

A vertical list is a possibility.  That is what `list-buffers'
provides, as does clicking on the `Buffers' item in the menu bar.

Unfortunately, even now, with only 41 open buffers, my menu bar
`Buffers' list runs out the bottom of the screen (it has a little
arrow at the bottom) -- this makes this feature less convenient than
the buffer list provided by buff-menu.el.

In windows, such as X, perhaps the names could be put in another
frame, like speedbar does.  However, speedbar does not scale well
either -- not for my directories -- but might work on a `tabbed'
buffer list, since the number of open buffers is likely to be smaller
than the number of files in a directory.  (For example, in one
directory right now I have 2361 personal `how-to-*' files, including
backups, but as I said, only 41 open buffers.)  Because it does not
scale, I do not use speedbar; consequently, I do not know the
advantages or disadvantages of this possibility.

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

Re: Two GTK related feature requests

[Simon Josefsson]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Does C-Mouse-1 not do what you want, except that one does not stare at
> that information all the time, but why would one want to be staring at
> it all the time, instead of just when one needs it?

Tabs speed up user interaction, but otherwise I guess it is the same.
In the same sense, typing M-x switch-to-buffer RET is also the same,
but perhaps you appreciate the improvement in C-Mouse-1 compared to
M-x switch-to-buffer RET.

Btw, I think I found a bug in the GTK port of C-Mouse-1: press
C-Mouse-1 and then select the top-level '-----' line to nail the menu
to the desktop.  The menu is nailed down, but pressing any of the
items doesn't do anything.

Re: Two GTK related feature requests

[Simon Josefsson]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>     * "Tabbed editing".  People using modern web browsers will know what I
>       mean.  It is very addictive.  Essentially it would add buttons at
>       the top of the Emacs window, one button for each buffer.  Clicking
>       on one button will change focus to that buffer.  ...
>
> To try this out, I am using tabbar.el from
>
>     http://unc.dl.sourceforge.net/sourceforge/emhacks/tabbar-1.3.tar.gz
>
> The user interface created by tabbar.el does not scale.
>
> Right now I have 41 open buffers, which is fewer than usual.  To see
> the various groups of files, I need a window width of 125 characters

As a comparison, having 50 tabbed web pages open with, e.g., Mozilla
Firebird or Galeon is not a problem.  I typically have 20 tabs.

> To see the file names in just the `text' group, I need a window that
> is 147 characters wide.  My normal window width is the conventional 80
> characters.

The file names should be truncated if they don't fit.  IMHO, the
important thing is not fit some text on the tab, just to provide easy
jumping between buffers.  This is how I usually use it in a web
browser: first identify the tabs for the pages that I'm currently
interested in, and then click on those tabs to switch among them.

When I compare this with how I use emacs, I see the same pattern.  I
switch between two (or maybe a few more, but two is most common)
buffers with C-x b RET.  I know of C-x 2 and C-x 5 2, and use them,
but it doesn't remove my constant use of C-x b RET.

> The `tabbed editing' notion is interesting but I am not sure that any
> of the obvious solutions work in the long run.

I don't disagree.  The details need to be analyzed further before
something like this can be useful, if ever.

Btw, I have been using tabbar.el for a day or so now and can see that
it does not do exactly what I want.  But it probably can help me
articulate what it is I believe I want, though.

Re: Two GTK related feature requests

[Michael Welsh Duggan]

Richard Stallman <rms@gnu.org> writes:

>     * "Tabbed editing".  People using modern web browsers will know what I
>       mean.  It is very addictive.  Essentially it would add buttons at
>       the top of the Emacs window, one button for each buffer.  Clicking
>       on one button will change focus to that buffer.  Each tab may also
>       have a X button that kill that buffer.  There are several details to
>       be sorted out, e.g., should the tab be per-window or per-frame?
>
> It is clear how this would work when you have just a few buffers, but
> what about when you have 50?  We need to finish designing this feature
> before implementing it.

It would make more sense to me to have tabs represent different
"frames" instead of buffers.  In this manner one could switch between
frames in a single actual frame (much like tty frames).  Of course,
one shouldn't disallow the creation of "real" extra frames, and one
should probably have a way to have a frame or frames not show up in
the tabs.

-- 
Michael Welsh Duggan
(md5i@cs.cmu.edu)

Re: Two GTK related feature requests

[James H.Cloos Jr.]

>>>>> "Michael" == Michael Welsh Duggan <md5i@cs.cmu.edu> writes:

Michael> It would make more sense to me to have tabs represent
Michael> different "frames" instead of buffers.

Lately I've been using elscreen¹ for this.  It doesn't provide a
visual pane of tabs, but I'd not want to waste screen real-estate on
one, nor have to switch between kbd and rodent.  The screen(1) like
interface is much more to my liking.

It does overlay C-z, so you have to remember to use C-x C-z instead
for (suspend-emacs) or (iconify-or-deiconify-frame) as applicable.

-JimC

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

Re: Two GTK related feature requests

[Jan D.]

> Btw, I think I found a bug in the GTK port of C-Mouse-1: press
> C-Mouse-1 and then select the top-level '-----' line to nail the menu
> to the desktop.  The menu is nailed down, but pressing any of the
> items doesn't do anything.

Actually popups should not be able to tear off.  Since the context
(lisp code) has changed since the popup was created, there is no good
way to find out what to do to invoke a menu item after the popup has
been teared off.  I have removed the tear off posibility for popups,
I don't know what I was thinking.

	Jan D.

Re: Two GTK related feature requests

[Kai Grossjohann]

Richard Stallman <rms@gnu.org> writes:

> It is clear how this would work when you have just a few buffers, but
> what about when you have 50?  We need to finish designing this feature
> before implementing it.

One thing that people seem to do is to implement scrolling, of sorts.
It looks like this (assuming only two buffers are shown):

 ________  ________
/buffer 3\/buffer 4\[<][>]

Then you can click on [<] to show buffers 2 and 3, and on [>] to show
buffers 4 and 5 in the tab bar.  Or so, maybe the arrows scroll by
more than one buffer.

Another thing that people seem to do is to shorten long buffer names,
so that they display "som...ame" instead of "some long buffer name".

A third thing, which is an alternative to the first thing, is that
they just show multiple rows of buffer tabs.  My coworker, using the
NetBeans Java IDE, always has 4 or 5 rows of buffer tabs below the
editing area.  He always uses the mouse to select one of them, and he
seems to remember them by position: they are not sorted in any obvious
order, at least afaict they are not sorted alphabetically.  In case he
forgets the position of one of the tabs, he scans all of them
visually.  Amazing.

Kai

Re: Two GTK related feature requests

[Richard Stallman]

    One thing that people seem to do is to implement scrolling, of sorts.
    It looks like this (assuming only two buffers are shown):

     ________  ________
    /buffer 3\/buffer 4\[<][>]

    Then you can click on [<] to show buffers 2 and 3, and on [>] to show
    buffers 4 and 5 in the tab bar.  Or so, maybe the arrows scroll by
    more than one buffer.

I think that's a good partial solution.

    Another thing that people seem to do is to shorten long buffer names,
    so that they display "som...ame" instead of "some long buffer name".

I think that's a good partial solution.

Whether these two partial solutions are enough for real usage,
I can't guess in advance.

    A third thing, which is an alternative to the first thing, is that
    they just show multiple rows of buffer tabs.  My coworker, using the
    NetBeans Java IDE, always has 4 or 5 rows of buffer tabs below the
    editing area.  He always uses the mouse to select one of them, and he
    seems to remember them by position: they are not sorted in any obvious
    order, at least afaict they are not sorted alphabetically.  In case he
    forgets the position of one of the tabs, he scans all of them
    visually.  Amazing.

This is fine except I wonder if it would use up too much of the screen
height.