3 ms·

I used this for a few years, and loved it -- it's my favorite of all the tiling window managers I've tried, for conceptual simplicity, extensibility, and ease o

by girzel 10y ago

I used this for a few years, and loved it -- it's my favorite of all the tiling window managers I've tried, for conceptual simplicity, extensibility, and ease of use. It was dog-slow, though, and often couldn't keep up with my commands. I switched to i3 (and sway when I'm feeling adventurous) and have enjoyed that. Making window splits still isn't as brain-dead simple as it was in StumpWM, though. Maybe I'll try the new release and see if it goes any faster.

geoka9 10y ago
Have you tried ratpoison? Same author, but in C, so it's fast.
yellowapple 10y ago
One consideration might be which Lisp you're using. SBCL is known for its speed compared to other CL implementations, for example, so using it (especially now that it's the one recommended Lisp to use with StumpWM) might help considerably. I personally don't notice any significant performance issues, even on old single-core 32-bit hardware.
- girzel 10y ago
  I was using SBCL! Here's an old mailing list thread about it. It often took StumpWM a second or two to notice that I'd typed the prefix key. https://lists.nongnu.org/archive/html/stumpwm-devel/2014-03/msg00043.html https://lists.nongnu.org/archive/html/stumpwm-devel/2014-03/...
  - lokedhs 10y ago
    While I have no idea what caused your problems at the time, I can assure you that it's nothing like that today. There is zero delay anywhere in it, and it's as fast it can be (in other words, I don't know of anything in it that, if made faster, would even be noticeable)
  - yellowapple 10y ago
    Come to think of it, I recall some performance issues that supposedly existed if SBCL was compiled with threading support. It's since been resolved, though, as far as I can tell.
    - girzel 10y ago
      I went far enough down the rabbit hole to conclude that the source of the trouble was threading. If that's been fixed, then I'm going to give stump another shot right now.
      - girzel 10y ago
        I did, and it's lickety-split. I'm home!
- lispm 10y ago
  Many Lisp implementations are in the speed range of SBCL. When you look at such an application, the super optimized part of the code is not that large. Equally, if not more, important is the robustness of the runtime system against all kinds of errors, the speed and responsiveness of the memory management system and the speed of compiled code which runs with full safety checks. Also if a Lisp system would use much of CLOS, the speed of the CLOS implementation and the library one writes with CLOS becomes important. If there are speed problems in an application like Stumpwm with the current Lisp systems, it is definitely not the raw micro-bench speed that's a problem, but more likely something else (architecture, threading, GC, event handling, bugs, ...).
mmgutz 10y ago
As user of i3 and not having tried StumpWM what makes splitting windows easier in StumpWM?
- girzel 10y ago
  No one's looking at this page anymore, but I happened to have the tab open and think it's an interesting question... StumpWM handles windows a little differently than i3. In Stump, every new window simply piles on top of the existing windows. There's no stacked/tabbed/split layouts to switch from. You switch windows with a fuzzy-matching text-completion thing. When you want a split, you give a "split" command, either vertical or horizontal. The top-most (ie visible) window goes into the new split, and the next window down the stack becomes visible in the leftover space. Removing a split is another single command. Pulling a different window into a split is another single command. Almost the only times I want to split windows is where I need to look at something side-by-side really quickly, for whatever reason. In Stump that's one command to split, and another to remove the split. In i3, it's "create a split container", "move to another window", "move this window into the split container", do what you need to do, then "move this window up/out of the split container", then "move the original window up/out of the split container". I regularly get tangled up in the various containers, and have a hard time getting out of them. I freely admit I may be doing it wrong, but I haven't yet figured out how to do it right.

by girzel 10y ago

geoka9 10y ago

Have you tried ratpoison? Same author, but in C, so it's fast.

yellowapple 10y ago

One consideration might be which Lisp you're using. SBCL is known for its speed compared to other CL implementations, for example, so using it (especially now that it's the one recommended Lisp to use with StumpWM) might help considerably. I personally don't notice any significant performance issues, even on old single-core 32-bit hardware.

girzel 10y ago
I was using SBCL! Here's an old mailing list thread about it. It often took StumpWM a second or two to notice that I'd typed the prefix key. https://lists.nongnu.org/archive/html/stumpwm-devel/2014-03/msg00043.html https://lists.nongnu.org/archive/html/stumpwm-devel/2014-03/...
- lokedhs 10y ago
  While I have no idea what caused your problems at the time, I can assure you that it's nothing like that today. There is zero delay anywhere in it, and it's as fast it can be (in other words, I don't know of anything in it that, if made faster, would even be noticeable)
- yellowapple 10y ago
  Come to think of it, I recall some performance issues that supposedly existed if SBCL was compiled with threading support. It's since been resolved, though, as far as I can tell.
  - girzel 10y ago
    I went far enough down the rabbit hole to conclude that the source of the trouble was threading. If that's been fixed, then I'm going to give stump another shot right now.
    - girzel 10y ago
      I did, and it's lickety-split. I'm home!
lispm 10y ago
Many Lisp implementations are in the speed range of SBCL. When you look at such an application, the super optimized part of the code is not that large. Equally, if not more, important is the robustness of the runtime system against all kinds of errors, the speed and responsiveness of the memory management system and the speed of compiled code which runs with full safety checks. Also if a Lisp system would use much of CLOS, the speed of the CLOS implementation and the library one writes with CLOS becomes important. If there are speed problems in an application like Stumpwm with the current Lisp systems, it is definitely not the raw micro-bench speed that's a problem, but more likely something else (architecture, threading, GC, event handling, bugs, ...).

mmgutz 10y ago

As user of i3 and not having tried StumpWM what makes splitting windows easier in StumpWM?

girzel 10y ago
No one's looking at this page anymore, but I happened to have the tab open and think it's an interesting question... StumpWM handles windows a little differently than i3. In Stump, every new window simply piles on top of the existing windows. There's no stacked/tabbed/split layouts to switch from. You switch windows with a fuzzy-matching text-completion thing. When you want a split, you give a "split" command, either vertical or horizontal. The top-most (ie visible) window goes into the new split, and the next window down the stack becomes visible in the leftover space. Removing a split is another single command. Pulling a different window into a split is another single command. Almost the only times I want to split windows is where I need to look at something side-by-side really quickly, for whatever reason. In Stump that's one command to split, and another to remove the split. In i3, it's "create a split container", "move to another window", "move this window into the split container", do what you need to do, then "move this window up/out of the split container", then "move the original window up/out of the split container". I regularly get tangled up in the various containers, and have a hard time getting out of them. I freely admit I may be doing it wrong, but I haven't yet figured out how to do it right.