From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: floyd@barrow.com (Floyd L. Davidson) Newsgroups: gmane.emacs.help Subject: Re: emacs for everything? Date: Wed, 24 Nov 2004 14:58:58 -0900 Organization: __________ Message-ID: <87653u4x4t.fld@barrow.com> References: <87pt2ej98v.fsf@node1.ddorf.de> <87zn1g2t5j.fld@barrow.com> <876540gxzw.fld@barrow.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1101340876 26530 80.91.229.6 (25 Nov 2004 00:01:16 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 25 Nov 2004 00:01:16 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Nov 25 01:01:03 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CX74J-00050h-00 for ; Thu, 25 Nov 2004 01:01:03 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CX7DT-0006xQ-4Q for geh-help-gnu-emacs@m.gmane.org; Wed, 24 Nov 2004 19:10:31 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!newsmi-us.news.garr.it!newsmi-eu.news.garr.it!NewsITBone-GARR!fu-berlin.de!uni-berlin.de!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 333 Original-X-Trace: news.uni-berlin.de d/FCMSSZF8X9EwzJPC4uCgsPicDbNXk05d3zlbr8gKUWmY+e1k User-Agent: gnus 5.10.6/XEmacs 21.4.15/Linux 2.6.5 Cancel-Lock: sha1:gvqXXlPgLXeNOu07OErfyWJHD8g= Original-Xref: shelby.stanford.edu gnu.emacs.help:126889 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:22290 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:22290 Kai Grossjohann 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 and C-x (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 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- 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 Ukpeagvik (Barrow, Alaska) floyd@barrow.com