all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Two GTK related feature requests
@ 2003-10-21  4:09 Simon Josefsson
  2003-10-21  4:17 ` Masatake YAMATO
  2003-10-22  9:25 ` Richard Stallman
  0 siblings, 2 replies; 15+ messages in thread
From: Simon Josefsson @ 2003-10-21  4:09 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Two GTK related feature requests
  2003-10-21  4:09 Simon Josefsson
@ 2003-10-21  4:17 ` Masatake YAMATO
  2003-10-21  4:27   ` Simon Josefsson
  2003-10-22  9:25 ` Richard Stallman
  1 sibling, 1 reply; 15+ messages in thread
From: Masatake YAMATO @ 2003-10-21  4:17 UTC (permalink / raw)
  Cc: emacs-devel

> * "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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Two GTK related feature requests
  2003-10-21  4:17 ` Masatake YAMATO
@ 2003-10-21  4:27   ` Simon Josefsson
  0 siblings, 0 replies; 15+ messages in thread
From: Simon Josefsson @ 2003-10-21  4:27 UTC (permalink / raw)
  Cc: emacs-devel

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Two GTK related feature requests
@ 2003-10-21  7:34 David PONCE
  0 siblings, 0 replies; 15+ messages in thread
From: David PONCE @ 2003-10-21  7:34 UTC (permalink / raw)
  Cc: emacs-devel, jas

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

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

David

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Two GTK related feature requests
  2003-10-21  4:09 Simon Josefsson
  2003-10-21  4:17 ` Masatake YAMATO
@ 2003-10-22  9:25 ` Richard Stallman
  2003-10-22 12:04   ` Simon Josefsson
                     ` (2 more replies)
  1 sibling, 3 replies; 15+ messages in thread
From: Richard Stallman @ 2003-10-22  9:25 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Two GTK related feature requests
  2003-10-22  9:25 ` Richard Stallman
@ 2003-10-22 12:04   ` Simon Josefsson
  2003-10-22 12:39     ` Luc Teirlinck
  2003-10-23  2:08   ` Michael Welsh Duggan
  2003-11-17 20:40   ` Kai Grossjohann
  2 siblings, 1 reply; 15+ messages in thread
From: Simon Josefsson @ 2003-10-22 12:04 UTC (permalink / raw)
  Cc: emacs-devel

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Two GTK related feature requests
  2003-10-22 12:04   ` Simon Josefsson
@ 2003-10-22 12:39     ` Luc Teirlinck
  2003-10-22 13:44       ` Simon Josefsson
  0 siblings, 1 reply; 15+ messages in thread
From: Luc Teirlinck @ 2003-10-22 12:39 UTC (permalink / raw)
  Cc: rms, emacs-devel

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Two GTK related feature requests
@ 2003-10-22 12:43 Robert J. Chassell
  2003-10-22 13:59 ` Simon Josefsson
  0 siblings, 1 reply; 15+ messages in thread
From: Robert J. Chassell @ 2003-10-22 12:43 UTC (permalink / raw)


    * "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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Two GTK related feature requests
  2003-10-22 12:39     ` Luc Teirlinck
@ 2003-10-22 13:44       ` Simon Josefsson
  2003-11-02 19:34         ` Jan D.
  0 siblings, 1 reply; 15+ messages in thread
From: Simon Josefsson @ 2003-10-22 13:44 UTC (permalink / raw)
  Cc: rms, emacs-devel

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Two GTK related feature requests
  2003-10-22 12:43 Two GTK related feature requests Robert J. Chassell
@ 2003-10-22 13:59 ` Simon Josefsson
  0 siblings, 0 replies; 15+ messages in thread
From: Simon Josefsson @ 2003-10-22 13:59 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Two GTK related feature requests
  2003-10-22  9:25 ` Richard Stallman
  2003-10-22 12:04   ` Simon Josefsson
@ 2003-10-23  2:08   ` Michael Welsh Duggan
  2003-10-25 20:08     ` James H.Cloos Jr.
  2003-11-17 20:40   ` Kai Grossjohann
  2 siblings, 1 reply; 15+ messages in thread
From: Michael Welsh Duggan @ 2003-10-23  2:08 UTC (permalink / raw)
  Cc: emacs-devel, 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.

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)

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Two GTK related feature requests
  2003-10-23  2:08   ` Michael Welsh Duggan
@ 2003-10-25 20:08     ` James H.Cloos Jr.
  0 siblings, 0 replies; 15+ messages in thread
From: James H.Cloos Jr. @ 2003-10-25 20:08 UTC (permalink / raw)
  Cc: Simon Josefsson, rms, emacs-devel

>>>>> "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/

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Two GTK related feature requests
  2003-10-22 13:44       ` Simon Josefsson
@ 2003-11-02 19:34         ` Jan D.
  0 siblings, 0 replies; 15+ messages in thread
From: Jan D. @ 2003-11-02 19:34 UTC (permalink / raw)
  Cc: Luc Teirlinck, rms, emacs-devel

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Two GTK related feature requests
  2003-10-22  9:25 ` Richard Stallman
  2003-10-22 12:04   ` Simon Josefsson
  2003-10-23  2:08   ` Michael Welsh Duggan
@ 2003-11-17 20:40   ` Kai Grossjohann
  2003-11-18 23:03     ` Richard Stallman
  2 siblings, 1 reply; 15+ messages in thread
From: Kai Grossjohann @ 2003-11-17 20:40 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Two GTK related feature requests
  2003-11-17 20:40   ` Kai Grossjohann
@ 2003-11-18 23:03     ` Richard Stallman
  0 siblings, 0 replies; 15+ messages in thread
From: Richard Stallman @ 2003-11-18 23:03 UTC (permalink / raw)
  Cc: emacs-devel

    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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2003-11-18 23:03 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-10-22 12:43 Two GTK related feature requests Robert J. Chassell
2003-10-22 13:59 ` Simon Josefsson
  -- strict thread matches above, loose matches on Subject: below --
2003-10-21  7:34 David PONCE
2003-10-21  4:09 Simon Josefsson
2003-10-21  4:17 ` Masatake YAMATO
2003-10-21  4:27   ` Simon Josefsson
2003-10-22  9:25 ` Richard Stallman
2003-10-22 12:04   ` Simon Josefsson
2003-10-22 12:39     ` Luc Teirlinck
2003-10-22 13:44       ` Simon Josefsson
2003-11-02 19:34         ` Jan D.
2003-10-23  2:08   ` Michael Welsh Duggan
2003-10-25 20:08     ` James H.Cloos Jr.
2003-11-17 20:40   ` Kai Grossjohann
2003-11-18 23:03     ` Richard Stallman

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.