frames-only-mode VS river

For (2), there's frames only mode that is commonly used by tiling wm users. I think this is the one: https://github.com/davidshepherd7/frames-only-mode

Another tip to make it even better: enable frames-only-mode to let the (tiling) window manager handle the layout for you. With a completion framework like Ivy or Helm, it becomes incredibly flexible and productive.

What about https://github.com/davidshepherd7/frames-only-mode ? I like this on a tiling window manager, though I do still need to tweak the settings a bit (like mu4e with org-msg likes to have an extra frame after sending a message for some reason).

That Emacs is still going to create new windows automatically for special buffers like help, man pages, or when running *-other-window functions. You can also make Emacs create only frames instead of windows, see: https://github.com/davidshepherd7/frames-only-mode https://www.reddit.com/r/emacs/comments/9ih3fo/frameoriented_workflow/ frames-only-mode is awesome but there where some cases where it didn't do what I wanted (it reuses help buffers even when they are not in the same workspace). I found this solution to do just what I wanted with minimum effort but as always YMMV.

Looks good! I'm curious how I might use this with something like frames-only-mode https://github.com/davidshepherd7/frames-only-mode; or similar. Seems like this would help with these buffers coming up at disrupting the current window layout (window as in window manager) and then killing them. Feels like it would work quite well together....

Btw, check out frames-only-mode; I've been using it for quite some time together with popwin (for when I do want a popup-like window inside of Emacs instead of a whole new frame) and it works really well!

More info on the wiki https://github.com/riverwm/river/wiki

Here is the related github issue

If you can get past some minor wayland related annoyances, river is pretty easy imo, you can write a config in whatever format you want, it just needs to be an executable file, the most common type is a shell script. The actual configuration happens by calling the riverctl program from the file, which from what I've heard is a similar method compared to bspwm.

Coming from awesome you may find river more to your liking than sway.

River crashed everytime I closed Chromium. The developer fixed it in 5 minutes :)

I've written a plugin that implements the river-layout-v3 wayland protocol in Hyprland. This means you can run something like rivertile, river-luatile, rivercarro or kile as a layout provider.

Author here. And yeah, as of 0.6.0 it supports master stack - I just called it stack main. I was in fact inspired by river: https://github.com/riverwm/river. River is really promising but is still in very early development. Sway on the other hand has been around for a long time and I, for now, prefer that stability.

In my very specific case, I'd probably start by taking a look at how animations were previously implemented in river, and then I'd pay careful attention to that transform matrix at the end. I'm not super crazy about the implementation using timers to drive it (versus interpolating where the transform should be across a deadline), but I guess they were going for smoothness.

riverwm wayland compositor