Re: emacs for everything?

[Floyd L. Davidson]

Kai Grossjohann <kai@emptydomain.de> wrote:
>floyd@barrow.com (Floyd L. Davidson) writes:
>> I am really interested in just what put OpenBox on the top of
...
>> 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?

Thank you!  It turns out this is very interesting, and perhaps
somewhat useful too.

The interesting part comes from the difference in what you are
configuring for, and what I am configuring for.  The useful part
of course is that you mention a few things I didn't know existed.

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

I am a very good touch typist, and have no problem with the
manual dexterity necessary for very precision mouse
manipulations...  but my eyes are not all that good.  So I also
don't much care for tiny buttons.  In particular, icons are not
very useful to me, nor is anything with small font sizes.

>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 have somewhat the same problem, though because of the differences,
I've "solved" it in a different way than you have.  I more or less
live with the smallness of the handles, though I make the borders
large enough to at least see them. :-)  I try to keep the border
size right at the point where any smaller and I'd have a fit, rather
than just be annoyed.  (Other than as something I can grab with a
mouse pointer to move a window, borders are a waste of space.  The
trouble is I use them whenever I do move a window, so they have to
be larger than just big enough to see the color change when focus
changes.  They are about 1/16" wide on my screen.)

>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* focus-follows-mouse, but it is also obvious why you don't
and I do, given some other things you describe here.  I also now
and then inadvertently end up switching focus, but my style of using
windows minimizes that, and maximizes other values from using the
focus-follows-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.

I've never used that.  But I rarely ever position two windows
side by side, as such.  My problem is that I have to have most
windows too large (the text has to be big enough for me to read
without eye strain) to put them side by side and have much room
in a window.  (This has been somewhat changed since I've gone to
using a dual head video setup with two monitors, as now I can
put two "fullsized" windows adjacent to each other!  But so far
that hasn't changed my normal way of working much, though given
time it probably will.)

>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?)

All of the above sounds really interesting.  I'm going to have to
look at that.

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

I typically use a 100 column xterm that takes up about 75% of
the screen.  Until I went to two monitors it was sometimes very
annoying to want to use two side by side xterms.  My emacs
windows are about the same size.  (For Usenet though, I use an
emacs window that is about 95% of the screen.)

I do use 15 virtual desktops, and jump between them with
regularity.  (For example, I am still forced to use a dialup
connection, so any time I do something that invokes the World
Wide Wait, I'm like the proverbial couch potato with a remote
control, except I switch screens instead of channels... :-)

>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 don't use C-x b in emacs much.  I use C-x C-b, to get a menu,
a lot.  I also use the bury-buffer function, which I have bound
to C-x x (I'm not sure if that is a default binding or not).

I use FVWM's FvwmPager module to switch between virtual desktops,
either with the mouse or sometimes (not nearly as often) by using
Control Arrow keys (mine is a 1x15 matrix, so there is only up
and down).

>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 :-(

I've never liked a menu for my screen windows.  I fixed up my
own version of such a menu for FVWM, and a right mouse button
click on the root screen displays it, but things like bash show
up as "BASH" at worst, and with the window title at best, and I
can't tell which title applies to whatever it is I want to work
with.

On the other hand, I use a 1x15 graphic page manager, which
shows me which virtual desktop I'm looking at, and can give me
at least some visual clues as to which one has what in it (not
much of a clue, but I can tell at least what the shape of the
windows in each desktop).  My main reference is that I
always do certain things in certain desktops.  For example I
read Usenet in the second one down from the top.  I have another
newsreader open in the top desktop, which I occasionally use for
odd things.  Similarly I have, in the bottom 4 desktops, 4
different browsers (each running as a different user).  The
first two are dedicated pretty much to specific things, and the
bottom two are used for whatever random web activity I might do
(google searches, for example).

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

That is a very fundamental difference in what we do with window
managers.  I start virtually *no* applications from a window manager,
either by menu or with icons.  I work in many different directories,
and anything started by the window manager thinks it is in the
home directory.  So I start almost everything from a command line.
The exceptions are tools that are not tied to any given working
directory (xmag, a couple local database programs, xcalc, my clock,
stuff like that).

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

For me screen is somewhat like having to shift through windows
with the cursor keys.  I don't like it.  I put different xterms
on different virtual desktops, and rather than rotate through
them, I jump directly to the one that I want, using the mouse to
select it.

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

This was interesting, as we share a lot of similar ideas here.

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

With FVWM, I use its facilities to the max.  The window that is in
focus has a light bluegreen colored border, and others turn to grey.
The title bar turns more bluish, but at about the same intensity,
when a mouse button selects the title bar.

>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 ;-)

Mine are as small as I can make them and still have readable
title, which I suspect means that for me they have to be about
twice as big, perhaps more, as you are using.  They are about
1/4" high.  (Anything that doesn't need borders or a title bar,
is configured not to have one though.)

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

Wow, that looks very useful.  With FVWM I just stack them up,
with a slight offset.  I can handle 3 easily, but more than 4
starts getting pretty difficult.  Part of what make 2 or 3 easy
is using the focus-follows-mouse, but that also leads to the
accidental switching too.  I physically place the mouse off to
the right side of my keyboard, which minimizes that.  It also
makes removing my hands from the keyboard necessary every time
I want to things that require mouse... so it is a compromise.

Of course now, with two monitors, I've got an awful lot of space
to work with.  For example an emacs window editing a TeX file on
one and ghostview looking at the results on the other.  I used
to have to switch between the windows to see that, and now they
are both relatively close to "full size" on the monitors.

(For anyone that hasn't tried it, using a dual head video system
under X is just astounding!)

...

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

Useful information!  I'll have to take a look at that.

>Another feature I implemented for Sawfish and ctwm is automatic window
>lowering.  (Autoraise is normally used with focus follows mouse, and
...
>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.

That pretty much described what I do.

I also have FVWM set up to lower a window by using a right mouse click
on the title bar.  So if I lose something small under a large window,
I can get it without having to move the large window or find the small
one in a menu.

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

It doesn't take much, and I don't reconfigure the WM very often, so
just how it is scripted isn't nearly as important as how well it is
documented!  I have to look it all up anyway...

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

Looks to me like you are willing to reconfigure just about
anything to suit your desired style, rather than adjust your
style to match the defaults.  I think that is typical of
programmers (particularly those who do systems programming or
administration) and not so likely with non-programmers.

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

That would drive me right up a tree.

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

Thanks.  It was worth reading a couple times, and thinking about
what you are saying.

-- 
Floyd L. Davidson           <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska)                         floyd@barrow.com