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.
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.
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 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.
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.
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.
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.
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.
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]?
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.
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. :)
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*
I just want stumpwm to take advantage of the whole screen at all times.
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.
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.
I wish guile-wm was under more active development, so maybe a few more hackers could help get the ball rolling.
https://github.com/mwitmer/guile-wm