▲ 88 points
back
43 comments
If you'd prefer to use Scheme over Common Lisp and would like to get your hands dirty, consider hacking on guile-wm. I try it out from time to time and make small patches to improve it. You can modify guile-wm at runtime by connecting to the REPL server using telnet or the geiser Emacs extension. I recall StumpWM not having something as convenient.
I wish guile-wm was under more active development, so maybe a few more hackers could help get the ball rolling.
You are mistaken.
One could always modify StumpWM at runtime, via SLIME, which is far superior to geiser. Common Lisp is also superior to Scheme (as a language) and SBCL/CCL are miles better than Guile in particular, Guile being one of the worst Scheme implementations out there.
Those are a lot of claims to throw out there in one sentence. Can you elaborate a bit (although I'll give you SLIME over Geiser)?
The incompatibilities between Schemes is one for starters.
The core Scheme language seems pretty small compared to CL so compatibility might not be the best argument to make. The best you can say about CL is that it was designed with the expectation of incompatibility.
For libraries, CL has the same problems as Scheme so it's a wash. I hit this keenly when interacting with the OS (POSIX calls, mostly).
No, CL doesn't have the same problems as Scheme, not by a long shot. See Quicklisp or cliki.net even. All these libraries (Quicklisp alone has 1000+ libraries last I checked) work perfectly fine on _multiple_ CL implementations.
You doing work on Linux and need a very fast compiler? Use SBCL, 3rd party libraries continue to work (unless they're platform specific)
Doing work on OSX or Windows? Use CCL. 3rd party libraries continue to work (unless they're platform specific).
This flexibility is absent from the Scheme world, with the myriad slightly incompatible implementations and extremely fragmented library space. The emergence of Quicklisp for Common Lisp was so important that it alone KILLED Scheme for any sort of practical use. For most cases, one has not the slightest incentive to stray from using Common Lisp these days, and if he does, he better have a good reason.
What is the equivalent for Scheme? The SRFI hell? _shudder_
I do find even outside-the-standard CL libraries somewhat more portable than Scheme libraries. Varies by library, but CL library authors seem to make more of an effort to test on multiple implementations, using conditional compilation where necessary. It's semi-standard to use a compatibility layer for extensions, e.g. use Bordeaux-Threads rather than directly using sb-thread. Whereas Scheme programming style (at least in the Chicken and Racket ecosystems, the two I've used) seems to make more direct use of implementation-specific functions and comes with less expectation that any nontrivial program will run on another implementation without porting.
At least that's the case in the newer "open" CL world; older CL code, especially commercial code, more often did target a specific implementation like Franz, which is more like the Scheme approach.
Yes, I'm sure that's what's behind the new R7RS.
Your knowledge of Guile is outdated. Read http://wingolog.org
> Common Lisp is also superior to Scheme (as a language)
Your comment would be much better without this bit, which is entirely subjective.
All what humans say is subjective.
Yes, I was mistaken about the SLIME integration. I only used a primitive REPL. The rest of your response is total garbage. Guile is a really good Scheme implementation, imo.
Depends what you mean by really good Scheme implementation.
Guile is a GNU project, which means that if you care about (say) Windows (gasp), you're shit out of luck.
The same used to be true about OSX 2-3 years ago, I haven't bothered to check again since then.
Coupled with the fact, that maybe 2-3? people are actively working on Guile (guess what platform they're focusing on), and that pretty much nobody is using Guile besides little toy projects, things are not looking good.
No, a really good Scheme implementation would be, Racket or Chicken. Hell, even Gambit is objectively better and more mature than Guile. I guess you're too blind to see that.
"Guile is a GNU project, which means that if you care about (say) Windows (gasp), you're shit out of luck."
Are you using StumpWM on windows?
I am addressing Guile being in my view one of the worst Scheme implementations out there, StumpWM has nothing to do with this. Being tied to, effectively, a single platform does.
Sure. I just think it's a little weird to demand portability from something whose raison d'être is as an extension language for its host OS, in a context where we were originally discussing an extension language for something that is likewise non-portable.
It's been years since I've used StumpWM, but I believe you can accomplish a similar setup using SLIME (http://www.emacswiki.org/emacs/StumpWM).
Oh, cool. It just takes a little bit more Elisp for a full SLIME environment. Thanks!
I liked StumpWM when I used it, but as a Schemer, I'm inclined to use/hack guile-wm.
Been using Stump for a few years. It's perfect for my development needs. I find it very hard to use Mac or Windows now that I'm used to all my custom shortcuts and functions.
I usually have my editors on workspace 1, local terminals on 2, dev chrome on 3, some other local terminal / API on 4, logging on 5, remote terminals on 6, personal chromium on 7 (gmail/slack/music), IRC on 10.
But anytime I can just ctrl-t-ctrl+c which gives me a full-screen terminal, split the screen in half with ctrl-t-ctrl-s with two applications side-by-side, usually two terminals.
To be honest, I haven't tweaked the stumpwm config in a while.. maybe in a year. But I remember the first few months was so cool to add all lisp functions to manipulate the window manager. I.e. select a word, press a key, it opens google and search for it.
I use StumpWM and I'm very happy with it - the lack of any chrome whatsoever maximises screen real estate and minimises distractions.
My setup is here:
https://github.com/duncan-bayne/mint-setup/tree/master/conf/...
Thank you for that file. I have thought about trying StumpWM. Your setup is going to be helpful.
Glad to be of help :) If you have any questions, ask away ... and be aware that the battery status support in there is an ungodly kludge.
Couldn't you simply parse the output of "acpi -b"?
There is also another project written in Common Lisp, The Deep Space Window Manager :
https://github.com/dss-project/dswm
Does someone have some experience with it ?
The README has the following statement :
"DSWM is a fork of StumpWM, so have most of all features, which have StumpWM, but it designed for better usability and better integration with emacs."
Tried it a few month ago, haven't noticed any actual superiority compared to StumpWM, besides StumpWM have active community and dswm seems to be developed mostly by 1 person.
Thank you for you feedback.
I've been using StumpWM for several years now; it's great!
There are some issues because the various desktop environments really don't want their in-house WMs replaced, and don't really document what needs to be done in order to just swap out the WM, leaving everything else. It's kinda sad really, and extremely anti-Unix.
Still, StumpWM is so pleasant and easy to use that it's worth the minor pain of getting my desktop environment working with it each time I update machines.
Highly recommended!
StumpWM's defaults can be very unusual, I remember the first time I used it was like the first time I tried to use Vim. But after using it for a while, it's become almost unthinkable to drop it for something else. This is in part due to the fact that Common Lisp is the language I know best, but Stump really is a very pleasant environment to work in.
I must admit to having wondered why there is not a greater use of Lisp in window managers. Lisp would seem the ideal language to use for tweaking a desktop. Xmonad (in Haskell) seems to have taken most of the attention of keyboard lovers and tweakers, but Lisp would seem to me to be a better fit.
Why not write the window manager itself in Haskell (e.g., xmonad [1]) to take advantage of Haskell's type system, and provide extension points to allow users to tweak the desktop environment in the language of their choice -- for example, Scheme [2] or Python [3]?
[1]: http://xmonad.org/
Why not write the product in language X and then make it extensible via language Y?
Well... For one it wouldn't be the emacs of window managers.
If you want to go the full mile, you should go the full mile. Trying to do half a mile subset and hoping it is the right subset gets tiresome pretty quickly.
I deeply respect them for doing it this way.
>Well... For one it wouldn't be the emacs of window managers.
Emacs is some primitives written in C wrapped by a massive amount of Elisp extensions.
Using StumpWM for quite some time. Someone already pointed that it causes minimum distractions while working. Also makes it really easy to hack it in any way you want. :)
Using minimalistic config myself: https://github.com/grepz/dotfiles/blob/master/.stumpwmrc
Brings back memories of the old sawfish as the GNOME WM.
I used to run ratpoisone, StumpWM's predecessor (it's written in C). The "inspiration" is pretty A+:
Re: SCWM, Pot and the GPL... [1]
I started using stumpwm but I have a small problem that's been annoying me.
I'm used to emacs, where if I kill a buffer while split, the killed buffer will be replace by a hidden buffer, or the frame will unsplit.
However, in stumpwm, sometimes I'll end a program while split, and I will be left with an ugly blank space where the program's window used to be. Then I have to manually unsplit and resplit to restore the layout I had before.
Am I doing something wrong? I'm looking up how to get around this. I think it'll involve
*destroy-window-hook*
Thanks.
I think I know what you mean, but it's just a key away from removing that "blank" screen (which is called a frame IIRC).
For me, (ctrl-t backspace) remove the current frame. I like the flexibility of Stumpwm where it differentiates between the space taken by an application and where it fits on the screen (Frame) vs the application.
The scenario you are describing happens if you have 2 frames while only one app running. Otherwise the next app would just fill that frame that is now available. Personally it doesn't bother me.. I'll just either remove the frame with (ctrl-t-backspace) and then my only app will now be full-screen on that first frame. Or I'll open another app in that empty frame, such as a terminal.
Thanks for the tip!
I've used StumpWM before and enjoyed it. It's pleasantly surprising to see how much development seems to have happened on it in the last year.
Does anyone have experience with both StumpWM and i3? How do they compare? I'm happy with i3, but am curious about other similar window managers.
I would say stick with i3 unless you are really a fan of lisp. I used StumpWM for years until I discovered i3, however a few months ago I switched back to StumpWM.
The floating layer in stump is quite frankly terrible. Pop up dialogs often act oddly. Yesterday I was updating ebooks in Calibre menus were appearing full screen and the progress dialog would grab focus and pop to the front on every tick. These are the types of issues that caused me to stop using it 4 or 5 years ago so unless you are willing to fix them yourself I wouldn't count on things improving.
That being said I much prefer the StumpWM tiling over i3. The tree structure that i3 uses is a bit odd. Stump is much more straightforward you have frames and windows. Windows are displayed inside frames and you can split and resize frames however you like. I never have to focus parent in order to split a frame vertically instead of horizontally as you might in i3.
Thanks! I'll stick with i3 even though I am a fan of lisp, because it did what I wanted with very little configuration.
I used to use StumpWM and clfsWM, but instabilities in CLX drove me to Openbox.