Re: emacs for everything?

[Kai Grossjohann]

floyd@barrow.com (Floyd L. Davidson) writes:

> Kai Grossjohann <kai@emptydomain.de> wrote:
>>
>>Currently, I use OpenBox.  It's painful, but I can bear it.
>
> What????  You don't just switch back and forth between
> virtual consoles...  :-)

He, he.

> I am really interested in just what put OpenBox on the top of
> your list, and what makes it painful too.  Given that list, you
> must have a well developed concept of what is of value to you in
> a window manager.

(I forgot to mention that I also used KDE for a while.)

> Can you give a brief (or not if the mood strikes you) description of
> what you do or don't like in a window manager?

One thing certainly is the newness: it hasn't gotten boring, yet ;-)
Also, I'm still dreaming of extending OpenBox with some functions I'm
missing...

I think the most important issue is that I'm a fair typist, but I'm a
really bad mouse user.  So if I have to hit tiny buttons with the
mouse, I'll be angry.

So I want to be able to move and resize a window by clicking (and/or
dragging) inside it, instead of having to hit a handle.

I also want to be able to focus a window by clicking inside it, but
OpenBox doesn't allow that, yet.  It always passes the focusing click
to the application.  So if I want to focus Firefox, and I use the left
mouse button, then there's a fair chance I'll follow a link, which I
don't want.  If I use the right mouse button, then I'll get a context
menu, which I also don't want.

I want focusing left clicks to be passed, and focusing right clicks to
be swallowed.  (Right clicks should be passed to the application if it
already has focus, though.)

Ion side-steps the whole issue because it is focus-follows-mouse.
Normally, I don't like that, but interestingly enough, focus follows
mouse doesn't bother me that much with Ion.  Not sure why.  But it
still does bother me that the position of the mouse pointer determines
which window gets focus after switching workspaces.

(I dislike focus follows mouse because I sometimes inadvertently bump
against the mouse.)

I like window border snapping (or resistance) for moving windows.
That makes it easy to position two windows adjacent to each other.
Of course, with Ion, windows are always adjacent (or they cover each
other), so there is no problem there.

Still on the subject of moving windows, I found out that I normally
move a window to be adjacent to another one, or the screen edge.  And
some WMs have keybindings which will move a window in some direction
until it bumps into another one.  Very useful.

A related function I like is to grow a window in some direction until
it bumps into another one.  That helps me fill empty areas on the
desktop.

Of course, I don't need these operations with Ion.  (I think there is
an fvwm module which does like Ion does -- is it called tiling?)

Back when I used ctwm, I used another feature instead.  Ctwm allows
you to bind a key to a function which will move a window to a
predetermined location and resize it to a predetermined size.  It
turns out that all my xterms are either 80x25 or 80x(height of
screen).  So I had some functions which moved an xterm to be 80x25 in
the upper left corner, 80x25 in the upper right corner, then two more
for the locations below these, and more functions for 80x(screen
height) on the left and on the right.

(I select my font such that an 80 column xterm is about half the
screen width, or a bit less.)

KDE allows you to move a window interactively: hold down cursor-right
until it has moved far enough.  That was a kludge for achieving what I
wanted, but I could bear the pain for some months.

So far with window movement, on to window selection.

I like to use C-x b in Emacs.  Sawfish and Ion provide a similar
function for windows.  It's even more like iswitchb because you can
enter substrings, not only prefixes as with C-x b.

I also like to use C-x <right> and C-x <left> (next-buffer and
previous-buffeer), and indeed most window managers offer this function
on Alt-Tab (and Alt-Shift-Tab).  But I really hate the WMs to steal
Alt-Tab.  I want to use M-TAB for completion in Emacs.  This
functionality should select windows in MRU order.

I also like to select windows from menus, but then I prefer to use
vi-like bindings or Emacs-like bindings to navigate those menus.  Too
many WMs (OpenBox included) make me use the cursor keys for navigating
the menus :-(

The Windows-style Start menu navigation is also quite nice: P selects
the only item starting with P.  If there is more than one item
starting with P, then P moves to the first one, and you can hit P
again to move to the next one.  Then RET selects it.

Some time ago, I used to have many windows, most of them xterms.  But
then I discovered screen, and now I just have a few xterms, all
attached to the same screen session.

I also distribute my windows across workspaces.  This means that
selecting a window via the C-x b like function has become less
important -- often selecting a workspace and hitting Alt-TAB (or the
keybinding I have instead) a few times will do just fine.

But screen doesn't provide C-x b like functionality for its screen
sessions :-(

I also have some ideas about the looks.

I like it for the focused window to be visually distinct.  So I like
it for the whole border of the window to change color when the window
has focus.  Fvwm does this very nicely.  (The OpenBox theme I chose
does not use left and right window borders at all, but the title bar
and the bottom border do change color on focus.)

I also like the title bars to be quite small.  (That makes them more
difficult to hit with the mouse, but thanks to the keyboard support I
don't need to do that ;-)


There is a feature sometimes called "window tabs", or "piles".  PWM is
known for this feature.  It means that you can have two windows on top
of each other and see the title bar of each of them, for easy
selection of the window.  Here is an asciified screenshot:

+-----+ +-----+
| W1  | | W2  |
+-----+--------------+
|                    |
| contents of W1     |
|                    |
+--------------------+

W1 and W2 have the same size and position, such that W1 covers W2
completely.  The title bars do not stretch across the whole window
width.  That's how I can see W2's title bar, too.

There are keybindings for switching between the windows in a pile (W1
and W2 comprise the pile shown above), and other bindings for
switching between piles.

Most piled window managers allow you to drag windows onto piles.  Then
the window is resized to match the pile size.

I implemented a module dwp.jl (dynamic window piles) for Sawfish which
did something similar but computed the piles dynamically based on
which windows just happened to be on top of each other.  dwp.jl also
didn't resize windows, so that piles could contain windows of
different sizes.  This was quite nice for a while, but somtimes the
dynamic pile computation algorithm failed, and then funny things
happened...

Of course, Ion has taken piles to the extreme.  (It calls a pile a
frame, and frames have slightly different behavior, too.)


Another feature I implemented for Sawfish and ctwm is automatic window
lowering.  (Autoraise is normally used with focus follows mouse, and
it means that a window is raised when it receives focus, i.e. the
mouse enters it.  Autolower means that a window is lowered when the
mouse leaves the window.)  I used that feature for small informational
windows.  I would keep them in one corner of the screen such that
always a couple of pixels were visible.  Then I would move the mouse
pointer onto those couple of pixels, which autoraised the window, then
I would read the contents.  Then I moved the mouse back out of the
window, which made it disappear behind the other, more important,
windows.  Another use case was an editor plus xdvi for composing LaTeX
documents: move the mouse into xdvi, it raises so I can use it, then
move the mouse out of the xdvi, and all the other windows become
visible again.  I used to like this a lot, but now it's gotten
somewhat old, and I switched to click-to-focus, as well.


I like Ion a lot because I don't need to move windows, and Ion allows
me to arrange the windows in the ways I use most often: Either I work
with firefox or openoffice, which are fullscreen, or I work with
xterms or Emacs, which are half the screen width.

The problem with Ion is that Ion doesn't handle popup (transient)
windows very well.  So some applications are not that well usable with
Ion.  (Ion resizes the transients, and some badly written apps don't
expect that and then you can't read the contents of the popups
anymore.)


Something that really surprises me is that I don't seem to need
scriptability in a WM.  Sawfish groks Lisp, and so I scripted it a
lot.  But if the functionality of the WM is right, then I don't need
all that scripting.

I didn't write much Lua at all with Ion.  I just tweaked some settings
and the keybindings.

Given how I work with Emacs, I'm quite surprised about myself.  Can
somebody explain my behavior to me? ;-)



Another thing is the subwindow handling (where an application window
contains several subwindows).

I use buffers and windows in Emacs.  I use screen to manage my
shells.  I use tabbed browsing with Firefox.  So this means that I've
got to remember three different ways to select "subentities" in a
program.  In Emacs, I use C-x <right> and C-x b to select between
buffers.  In screen, I use C-a n and C-a p.  In Firefox I use
Ctrl-Tab.  If I was using konsole (the KDE program) I'd use
Shift-<right> to select between shell sessions.

This really really really sucks.

Why can't I have a central mechanism for doing this?  The central
mechanism could be enhanced to be like iswitchb with substring
matching and completion, and then Bob would be my uncle.  But, no, I
have to live with different kinds of minimalistic functionality in
different programs.  Argh.


Whee.

Long rant.

Let me stop now.

Kai