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

[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

[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

[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

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

C-z (Re: Two GTK related feature requests)

[Karl Eichwalder]

James H.Cloos Jr. <cloos@jhcloos.com> writes:

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

Reminds me...  I'd like to see C-z de-assigned from
iconify-or-deiconify-frame.  It happens to me much to often that I
press this key combo by accident without the possibility to 'undo' (C-g)
this action.  I'm forced to use features of the windowmanager to
deiconify Emacs.  This isn't userfriendly.

People are used to make use of the windowmanager to iconify a frame;
thus there is no pressing need to assign C-z to
iconify-or-deiconify-frame, since it usually does more harm than good.

-- 
                                                         |      ,__o
                                                         |    _-\_<,
http://www.gnu.franken.de/ke/                            |   (*)/'(*)

Re: C-z (Re: Two GTK related feature requests)

[Eli Zaretskii]

> From: Karl Eichwalder <ke@gnu.franken.de>
> Date: Sun, 26 Oct 2003 05:10:04 +0100
> 
> Reminds me...  I'd like to see C-z de-assigned from
> iconify-or-deiconify-frame.  It happens to me much to often that I
> press this key combo by accident without the possibility to 'undo' (C-g)
> this action.  I'm forced to use features of the windowmanager to
> deiconify Emacs.  This isn't userfriendly.

Why can't you simply unbind C-z in your .emacs?  There's always "C-x
C-z" which does the same, should you need that.

I have a similar problem, except that in my case C-z is bound to a
different command.  I'm so used to that other command that when I
work in "emacs -q" or on someone else's machine, I frequently forget
and press C-z.  But I never thought it was a reason good enough to
unbind C-z by default: it is simply my personal problem, so I deal
with it as God intended. ;-)

> People are used to make use of the windowmanager to iconify a frame;

Only some ``people''; others don't want to move their hands to the
mouse or some function key to do that.

Re: C-z (Re: Two GTK related feature requests)

[Karl Eichwalder]

Eli Zaretskii <eliz@elta.co.il> writes:

> Why can't you simply unbind C-z in your .emacs?  There's always "C-x
> C-z" which does the same, should you need that.

Sure I can (and actually, I already did).  But a) sometimes I'm "forced"
to use Emacs default settings and b) I believe I'm not the only one who
is affected.

I see your story is pretty similar :)

> Only some ``people''; others don't want to move their hands to the
> mouse or some function key to do that.

Using a function key (or the mouse) is the right way™.  Who does not
like to go this way, can do a key binding he likes.

-- 
                                                         |      ,__o
                                                         |    _-\_<,
http://www.gnu.franken.de/ke/                            |   (*)/'(*)

Re: C-z (Re: Two GTK related feature requests)

[Richard Stallman]

what else useful could we put on c-z
instead of iconify?  it wd not be available on text terminals.

Re: C-z (Re: Two GTK related feature requests)

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> what else useful could we put on c-z
> instead of iconify?  it wd not be available on text terminals.

I have undo on C-z

I find it handy to have it there, and this is also the default binding
for undo in many other apps.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: C-z (Re: Two GTK related feature requests)

[Robert J. Chassell]

   what else useful could we put on c-z
   instead of iconify?  it wd not be available on text terminals.

One possibility is to make it a prefix reserved for users,
like C-c followed by a letter.

For example, someone might bind keys to to show syslog using
live-find-file, to remove text properties that are visible in a
window, or to list and kill processes.

[These can  be derived from

    (defun remove-window-text-properties ()
      "Remove facemenu-created text properties visible in window."
      (interactive)
      (facemenu-remove-all (window-start) (window-end)))

    (defun show-syslog ()
      "Show the syslog using live-find-file.
    You and/or the file must have the correct permissions."
      (interactive)
      (let ((log-buffer (get-file-buffer "/var/log/syslog")))
        (cond (log-buffer (switch-to-buffer log-buffer))
              ((file-readable-p "/var/log/syslog")
               (live-find-file "/var/log/syslog"))
              (t (error "syslog file not readable by user `%s'"
                        (user-real-login-name))))))

and Kyle Jones' 1989 `vkill.el', or something more recent.]

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

Re: C-z (Re: Two GTK related feature requests)

[Kim F. Storm]

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

>    what else useful could we put on c-z
>    instead of iconify?  it wd not be available on text terminals.
> 
> One possibility is to make it a prefix reserved for users,
> like C-c followed by a letter.

In that case, I would rather just reserve it for the user -- if you
want it to be a prefix key, it's your choice.

Notice that cua-mode (by default) binds C-z to undo; quite a number of
users use the cua bindings, so we shouldn't put anything overly
complex there.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: C-z (Re: Two GTK related feature requests)

[Karl Eichwalder]

storm@cua.dk (Kim F. Storm) writes:

> In that case, I would rather just reserve it for the user -- if you
> want it to be a prefix key, it's your choice.

Yes, that's a good proposal.

-- 
                                                         |      ,__o
                                                         |    _-\_<,
http://www.gnu.franken.de/ke/                            |   (*)/'(*)

Re: C-z (Re: Two GTK related feature requests)

[Robert J. Chassell]

    > One possibility is to make it a prefix reserved for users,
    > like C-c followed by a letter.

Kim F. Storm responded

    In that case, I would rather just reserve it for the user -- if you
    want it to be a prefix key, it's your choice.

    Notice that cua-mode (by default) binds C-z to undo; quite a number of
    users use the cua bindings, so we shouldn't put anything overly
    complex there.

Yes, you are right.

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

Re: C-z

[Werner LEMBERG]

>    what else useful could we put on c-z
>    instead of iconify?  it wd not be available on text terminals.
> 
> One possibility is to make it a prefix reserved for users,
> like C-c followed by a letter.

I think this is a good idea.


    Werner

Re: C-z (Re: Two GTK related feature requests)

[Juri Linkov]

"Robert J. Chassell" <bob@rattlesnake.com> writes:
> One possibility is to make it a prefix reserved for users,
> like C-c followed by a letter.

This is what I used for many years.  I use the prefix key `C-z' for my
additional keymap.  On qwerty-keyboards `C-z' is one of the most
accessible keys like `C-x' and `C-c', but the prefix key `C-c' is
reserved for mode-specific commands (both user-defined and standard
Emacs extensions).  I reassigned the previous binding of `C-z'
(`suspend-emacs' or `iconify-or-deiconify-frame') to double key
sequence `C-z C-z'.

Here is what I have in .emacs:

(defvar my-map nil)
(if (not my-map)
    (let ((c-z (global-key-binding "\C-z")))
      (global-unset-key "\C-z")
      (setq my-map (make-sparse-keymap))
      (define-key global-map "\C-z" my-map)
      (define-key my-map "\C-z" c-z)))
(define-key my-map "t" ...)
...

BTW, I once had one problem with this code.  Before I added `if' condition,
this code was called twice on the Emacs startup and created the cyclic
keymap.  The double loading was caused by the bug in the function
`command-line' in lisp/startup.el:

		      (when (stringp custom-file)
                        (unless (assoc custom-file load-history)
                          ;; If the .emacs file has set `custom-file' but hasn't
                          ;; loaded the file yet, let's load it.
                          (load custom-file t t)))

If .emacs contains the following code:

(setq custom-file "/home/full/path/dotemacs.el")
(add-to-list 'load-path "/home/full/path/)
(load "dotemacs")

then the above condition in the startup.el fails, because the variable
`custom-file' has the absolute file name, whereas `load-history'
has the file name without directory, i.e.

(assoc "/home/full/path/dotemacs.el" (("dotemacs.el" ...) ...))

I think that either this code should be fixed, or the documentation
of the variable `custom-file' should be improved to warn about this
problem.

-- 
http://www.jurta.org/emacs/dotemacs.en.html

Re: C-z (Re: Two GTK related feature requests)

[Kevin Rodgers]

Juri Linkov wrote:

> Here is what I have in .emacs:
> 
> (defvar my-map nil)
> (if (not my-map)
>     (let ((c-z (global-key-binding "\C-z")))
>       (global-unset-key "\C-z")
>       (setq my-map (make-sparse-keymap))
>       (define-key global-map "\C-z" my-map)
>       (define-key my-map "\C-z" c-z)))
> (define-key my-map "t" ...)
> ...
> 
> BTW, I once had one problem with this code.  Before I added `if' condition,
> this code was called twice on the Emacs startup and created the cyclic
> keymap.  The double loading was caused by the bug in the function
> `command-line' in lisp/startup.el:

I can't argue about the bug, but the recommended way to do that is:

(defvar my-map
   (let ((map (make-sparse-keymap))
	(c-z (global-key-binding "\C-z")))
     (global-unset-key "\C-z")
     (define-key global-map "\C-z" my-map)
     (define-key map "\C-z" c-z)
     map))

(define-key my-map "t" ...)

Or maybe there's even a better way, using define-prefix-command.
-- 
Kevin Rodgers

Re: C-z (Re: Two GTK related feature requests)

[Richard Stallman]

       what else useful could we put on c-z
       instead of iconify?  it wd not be available on text terminals.

    One possibility is to make it a prefix reserved for users,
    like C-c followed by a letter.

That might be a useful thing to do with some key if it could be
available on ttys also.  But people would probably be very unhappy
that it was unavailable except under X.

Basically I don't see any benefit in this change.  If you want to
redefine it, as a prefix key or any other way, you can already do
that.

Re: C-z (Re: Two GTK related feature requests)

[Karl Eichwalder]

Richard Stallman <rms@gnu.org> writes:

> Basically I don't see any benefit in this change.  If you want to
> redefine it, as a prefix key or any other way, you can already do
> that.

Sure, but the current implementation will continue to confuse new users.
Pressing C-z by accident makes Emacs disappear out of the blue.  And
there is now way to cancel this command using C-g.

At least, please add something to ask the user for confirmation:

    "Do you really want to inconify Emacs? (y/n)"

These days, only experts use Emacs without X; and experts will know
that C-z is something special on the console.

All hackers who speak up in this thread confirmed that they are using
redefinition for C-z - thus ther must be something flawed with the
current key binding ;)

-- 
                                                         |      ,__o
                                                         |    _-\_<,
http://www.gnu.franken.de/ke/                            |   (*)/'(*)

Re: C-z (Re: Two GTK related feature requests)

[Miles Bader]

Karl Eichwalder <ke@gnu.franken.de> writes:
> All hackers who speak up in this thread confirmed that they are using
> redefinition for C-z - thus ther must be something flawed with the
> current key binding ;)

I admit, I often get confused if a use `emacs -q' and accidentally hit
C-z (I usually think emacs crashed for a second).

Also `C-x C-z' is really easy to type, so just plain C-z has very little
advantage over it, except that it's slightly familiar to people running
on tty that are used to other programs' use of C-z (OTOH, `C-x C-z' is
pretty easy to remember -- it's the standard emacs prefix for such
`system commands', followed by the standard unix suspend key).  Given
the scarcity of bindings, it's rather surprising that such a
relatively-rarely used command is given _two_ easy-to-type-and-intuitive
bindings...

Maybe we should just bite the bullet and get rid of the current C-z
binding on both ttys _and_ in X.

-Miles
-- 
We live, as we dream -- alone....

Re: C-z (Re: Two GTK related feature requests)

[Richard Stallman]

    Maybe we should just bite the bullet and get rid of the current C-z
    binding on both ttys _and_ in X.

We could do that if users, even beginning users, would prefer it.  I
always use C-z to suspend Emacs, but I could rebind it myself or learn
to use C-x C-z.  However, we would need to take a poll to find out
whether a substantial fraction of users would be unhappy with this
change.  We can't judge anything from the opinions of the developers
on this list.

The same applies to the idea of removing the C-z binding only under X.

Does anyone want to take a poll?  If so, please send me email.

Re: C-z (Re: Two GTK related feature requests)

[David Kastrup]

Karl Eichwalder <ke@gnu.franken.de> writes:

> Richard Stallman <rms@gnu.org> writes:
> 
> > Basically I don't see any benefit in this change.  If you want to
> > redefine it, as a prefix key or any other way, you can already do
> > that.
> 
> Sure, but the current implementation will continue to confuse new
> users.  Pressing C-z by accident makes Emacs disappear out of the
> blue.

It is exactly what one expects on a tty.  Now iconifying and stopping
a process are different things, and on X, there is no C-z binding
expected, too.

On the other hand, on a tty one would expect C-c to end a program
(well, some of us old geezers perhaps even the DEL key), and we need
C-x C-c to do that, too.

> And there is now way to cancel this command using C-g.
> 
> At least, please add something to ask the user for confirmation:
> 
>     "Do you really want to inconify Emacs? (y/n)"

That would defeat the idea of C-z in the first place.  It turns out
that we have different keybindings on the tty and X, anyway (in the
first case, suspend-emacs, in the second case
iconify-or-deiconify-frame.

The first binding might be more or less what one expects, and people
exposed to the command line will know exactly what happened and how to
revert it, the second binding is a complete surprise and may take some
effort to undo.  In addition, it is completely arbitrary: deiconifying
a frame will force the user to revert to his window manager's
mechanisms of iconification (unless he can get keyboard focus on an
iconified window, which again will require the cooperation of the
window manager), so a method of iconifying that bypasses the window
manager methods for it only gets you half way there.

> All hackers who speak up in this thread confirmed that they are
> using redefinition for C-z - thus ther must be something flawed with
> the current key binding ;)

I am not, but I am lazy.  And I have yet to remember a single occasion
when I indeed used C-z for iconifying a frame.  I actually would
consider it _more_ likely to use C-x C-z for that purpose, now that I
think of it: it has a more Emacsy feeling to it.  In contrast, C-z
gets ingrained into your fingers as a "don't touch, ever, taboo"
combination.  Because it is too easy to type you learn to never type
it.  And thus C-z on X is more or less associated for me with "does
weird things, avoid" rather than "iconifies".

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: C-z (Re: Two GTK related feature requests)

[Stefan Monnier]

> At least, please add something to ask the user for confirmation:
>     "Do you really want to inconify Emacs? (y/n)"

Given the fact that iconification is normally done via the window manager
rather than via Emacs commands, and given the fact that we all seem to
agree that C-z is only ever used by mistake, I'd argue that we should
make either C-z or maybe even iconify-or-deiconify-frame into a "wizard"
command like narrow-to-region, capitalize-region, and eval-expression
which requires confirmation unless explicitly enabled.

The only cases I use C-z or C-x C-z is when my fingers slip.  Admittedly, it
hasn't been enough of an annoyance until now to convince me to remove the
binding, but this thread has prompted me to finally do it.


        Stefan

Re: C-z (Re: Two GTK related feature requests)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: 29 Oct 2003 08:30:54 -0500
> 
> Given the fact that iconification is normally done via the window manager
> rather than via Emacs commands, and given the fact that we all seem to
> agree that C-z is only ever used by mistake, I'd argue that we should
> make either C-z or maybe even iconify-or-deiconify-frame into a "wizard"
> command like narrow-to-region, capitalize-region, and eval-expression
> which requires confirmation unless explicitly enabled.

Or maybe simply remove the binding in a windowed session.

Re: C-z (Re: Two GTK related feature requests)

[Luc Teirlinck]

Karl Eichwalder wrote:

   These days, only experts use Emacs without X;

Absolutely not.  If you are using emacs over a slow connection, you
need to use emacs -nw, whether you are an expert or not.

Sincerely,

Luc.

Re: C-z (Re: Two GTK related feature requests)

[Stefan Monnier]

> Reminds me...  I'd like to see C-z de-assigned from
> iconify-or-deiconify-frame.

Agreed.  It's very rarely useful, but often annoying.
Also it's completely non-standard, except that it tries to simulate the tty
behavior, which seems wrongheaded because iconify-frame rarely brings you
back to the "parent shell" or anything vaguely related.

But admittedly, the C-z key sequence should keep its meaning under tty-use,
so its new binding under X (and w32) should be one that is not meaningful
on a tty.


        Stefan

Re: C-z (Re: Two GTK related feature requests)

[Miles Bader]

On Sun, Oct 26, 2003 at 02:01:50PM -0500, Stefan Monnier wrote:
> But admittedly, the C-z key sequence should keep its meaning under tty-use,
> so its new binding under X (and w32) should be one that is not meaningful
> on a tty.

How about `other-frame' (well OK that's useful on tty too, but probably used
much more heavily on a window system).

[actually I have C-z bound to scroll-one-line-up, but ...]

-Miles
-- 
If you can't beat them, arrange to have them beaten.  [George Carlin]

Re: C-z (Re: Two GTK related feature requests)

[Eli Zaretskii]

> Date: Sun, 26 Oct 2003 16:06:48 -0500
> From: Miles Bader <miles@gnu.org>
> 
> I have C-z bound to scroll-one-line-up

Same here.  I think this was a default binding in one of the old
Emacsen (not GNU Emacs), and I got too used to it to get around
without it.

Re: C-z (Re: Two GTK related feature requests)

[Miles Bader]

Eli Zaretskii <eliz@elta.co.il> writes:
> > I have C-z bound to scroll-one-line-up
> 
> Same here.  I think this was a default binding in one of the old
> Emacsen (not GNU Emacs), and I got too used to it to get around
> without it.

I use it because it was the default in `ez' (the Andrew graphical
toolkit emacs-style editor), along with C-q for scroll-one-line-down.

[I use the latter binding too, with C-x C-q for quote, which can be
annoying...]

-Miles
-- 
`Life is a boundless sea of bitterness'

Re: C-z (Re: Two GTK related feature requests)

[Juri Linkov]

Miles Bader <miles@lsi.nec.co.jp> writes:
> Eli Zaretskii <eliz@elta.co.il> writes:
> > > I have C-z bound to scroll-one-line-up
> > 
> > Same here.  I think this was a default binding in one of the old
> > Emacsen (not GNU Emacs), and I got too used to it to get around
> > without it.
> 
> I use it because it was the default in `ez' (the Andrew graphical
> toolkit emacs-style editor), along with C-q for scroll-one-line-down.

So if everybody has the functions to scroll one line up and down
in .emacs, why not to add the function definitions somewhere
to Emacs (e.g. in simple.el)?  Even though the function definitions
are trivial, it will make easier to bind a key to them.

I just found that Emacs already has these functions in the
`ws-mode.el'.  They could be moved to simple.el.

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

Re: C-z (Re: Two GTK related feature requests)

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
> I just found that Emacs already has these functions in the
> `ws-mode.el'.  They could be moved to simple.el.

Makes sense to me...

-Miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: C-z (Re: Two GTK related feature requests)

[Stephan Stahl]

Hi.

On Sun, Oct 26, 2003 at 02:01:50PM -0500, Stefan Monnier wrote:

> > Reminds me...  I'd like to see C-z de-assigned from
> > iconify-or-deiconify-frame.
> 
> Agreed.  It's very rarely useful, but often annoying.
> Also it's completely non-standard, except that it tries to simulate the tty
> behavior, which seems wrongheaded because iconify-frame rarely brings you
> back to the "parent shell" or anything vaguely related.

If C-z should continue to emulate the behavior of an tty when used in a
windowing system then maybe it should call (shell)? That could at least
be thought of as "parent shell"..

-- 
Stephan Stahl

Re: C-z (Re: Two GTK related feature requests)

[David Kastrup]

Stephan Stahl <stl@isogmbh.de> writes:

> On Sun, Oct 26, 2003 at 02:01:50PM -0500, Stefan Monnier wrote:
> 
> > > Reminds me...  I'd like to see C-z de-assigned from
> > > iconify-or-deiconify-frame.
> > 
> > Agreed.  It's very rarely useful, but often annoying.  Also it's
> > completely non-standard, except that it tries to simulate the tty
> > behavior, which seems wrongheaded because iconify-frame rarely
> > brings you back to the "parent shell" or anything vaguely related.
> 
> If C-z should continue to emulate the behavior of an tty when used
> in a windowing system then maybe it should call (shell)? That could
> at least be thought of as "parent shell"..

I'd call that very much obtuse.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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.

tabs proposal

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

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

I know people who do work with a gazillion tabs in several rows where
the name of the buffers or files just can't be read.  My observation
was that these people usually use tabs when there are few files and
buffers, and just ignore them when there are many.  When there are
many, they resort to other means of switching buffers or files.

An example is "tabbed browsing" in browser such as Firebird.  As soon
as I have five pages open at the same time, tabs stop being useful per
se.  So how come I sometimes have 20 tabs open?  I read a page, and
follow three links by opening them in new tabs.  Now I have four tabs
open, the system is still usable.  Then I switch to tab number two and
find five interesting pages.  I open them all in new tabs.  And from
then on the list of tabs is just a visual indication of how big my
"reading stack" is.  I just keep adding to the stack by opening new
pages in new tabs at the back, and killing tabs after I read them at
the front.

With this description on a narrative level, we can design a different
interface -- there only a max. of five tabs available.  When the user
creaates a new tab, we can add it to the end of the list, and show at
the end of the tab bar we have a tab counter for the hidden tabs
saying "1 more" (and keep increasing this as things are added).  Or if
the new tab is created due to some automatic buffer creation
(eg. Help, Apropos, etc), then we put it right after the current tab.
If we already have five tabs, the last one is removed and the tab
counter is increased.  If the current tab is tab number five, then the
new buffer would have to be invisiible.  Instead, we rotate the stack.
The first tab is moved to the end.  Now the current tab is number
four, and the new buffer is in tab number five.

It makes sense to allow "limitting" tabs to buffers by mode, age,
size, etc. -- all the stuff ibuffer does, too.

The key point is that we don't show more than a small number of tabs
at the same time.  Only the first n elements of the (possibly
filtered) buffer-list are shown.  Whenever this is not enough, we
change the order of the buffer-list such that the list of tabs shown
remains meaningful.

Alex.
-- 
http://www.emacswiki.org/alex/
There is no substitute for experience.

Re: tabs proposal

[Richard Stallman]

    The key point is that we don't show more than a small number of tabs
    at the same time.  Only the first n elements of the (possibly
    filtered) buffer-list are shown.  Whenever this is not enough, we
    change the order of the buffer-list such that the list of tabs shown
    remains meaningful.

I think this is a good approach.  If we use Lisp code to control
which tabs to show, the users will adapt it into something very usable.