𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍

       🅸 🅰🅼 🆃🅷🅴 🅻🅰🆆. 
 𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍 𝖋𝖊𝖆𝖙𝖍𝖊𝖗𝖘𝖙𝖔𝖓𝖊𝖍𝖆𝖚𝖌𝖍 

Ceterum Lemmi necessitates reactiones

  • 49 Posts
  • 5.19K Comments
Joined 3 years ago
cake
Cake day: August 26th, 2022

help-circle

  • Kyria is a solid alternative. I was seduced away from it by the Piantor Pro and forgot about it, but the Halcyon Kyria looks perfect. I probably wouldn’t use those outer thumb keys much, but it doesn’t hurt they’re there, and there are plenty of more well-positioned thumb keys from which to choose.

    I’d like more stagger on the body section than the birdy44 has, which looks like almost none; it has pinky stagger, but other than that no columnar stagger. The integrated track pads are lovely, though!

    KLOR has the same thumb key positioning - the “m” key is too far in - you have to tuck your thumb to get it under your index, which is over the “m” key. It’s the same layout as the Piantor. I was hoping for a thumb cluster positioned more naturally under the resting thumb, with less horizontal thumb movement, like the ErgoDox (and siblings).




  • It’s unique only in the combination of features.

    • No configuration file, at all. When hlwm starts, it runs ${XDG_CONFIG_HOME}/herbstluftwm/autostart, which can be anything but it’s usually a shell script making a lot of calls to herstclient which do all of the configuration. So there’s no configuration syntax, and all WM configuration and control can be done exactly the same on the command line. No exceptions. bspwm does the same; I think niri and river on Wayland do this, too
    • It’s tiled and keyboard controllable is, again, a first-class citizen.
    • It has a sane tree model, with no weird exceptions. This is one area bspwm fails, although I grant this is subjective.
    • It’s stable.
    • It’s fast and small. You never see it in top, sorting either by CPU or memory.
    • It supports

    It’s that hlwm has them all. Very subjectively, I find the client syntax to be intuitive, rich, and full featured. It has good and consistent monitor detection. It has a variety of common built-in layout, but custom layouts are easily scripted with bash (or anything that can call the client). It has an event listening model, for writing layouts, or anything else you might want to do - again, the interface to this is a command line client. I find not having bespoke languages, non-Turing-complete configs, or being forced into a specific language is increasingly important to me for things I rarely, but deeply when I do - change.

    It does build-in hotkey configuration (via the command line), unlike bspwm which farms this out to something like sxhkd. There’s nothing forcing you to use the built-in hotkey management, and in fact when I first switched I from bspwm I used sxhkd. Doing it within hlwm did have the advantage of eliminating yet another configuration file (for sxhkd), and made hotkey configuration just another purely command-line operation. No multistep edit & reloading. When you have CLI-first, you can make changes without worrying that you’ll screw something up that prevents a clean reboot. You make changes, test then, and then if you like it you make a permanent change to autostart (or some subscript).

    This is orthogonal to how I manage firewalls: I always make manual changes with nft on the cli and IFF everything works after extensive testing, then I persist the changes to the /etc/nftables.conf.

    There are many tiling WMs, but far fewer that make command line C&C fully competent in all ways. It narrows down field considerably.

    bspwm is a close second, but I have trouble with the bspwm tree model, and especially how monitors and tags are represented. There are also some extremely caustic prominent members of the bspwm community. But, really, it’s the model weirdness that had me switch.

    River seems to be the closest in model, C&C, and capabilities to hlwm, and is probably where I’ll end up. I need to confirm that all of the DPI issues I last had with Wayland a few months ago are fixed, and that everything I need runs, and that I’m not adding a ton of overhead to run common things (extra layers, emulators, whatever). The gap between “can” and “does well”; between “possible” and “efficient” has IME been a Wayland weakness.

    TL;DR: for features and idiom, on X bspwm has fair overlap with hlwm. For Wayland, River seems to be a good alternative.

    Edit: Niri commentary removed; it does have configuration files, and they’re in kdl.















  • Every day?

    • Herbstluftwm, the window manager. I used i3 for a decade, then bspwm for a few months, then landed on hlwm which I’ve been happily using for over a year. I don’t foresee changing until I’m forced to switch to Wayland. I’ve used almost every window manager and DE available for Linux and Solaris. Hlwm has things I can no longer live without:
      • It’s entirely configuration-file-less, which means the CLI client is the first class citizen for C&C.
      • It’s tiled and keyboard controllable is, again, a first-class citizen
      • It has a sane tree model, with no weird exceptions
      • It’s stable
      • It’s fast and small. You never see it in top, sorting either by CPU or memory
    • Zsh, the shell, in which I run 90% of my applications (the regular exceptions being the Luakit browser and Factorio, the game. everything else is CLI or a TUI). Zsh is bash backwards compatible, and it has a bunch of extra convenience syntax that makes scripting more powerful, pushing out the border where switching to a real programming language is necessary. I have lived in sh, bash, and csh over my life, and I’ve tried fish and a number of others; the rich data model for process communication is compelling, but I’ve always discovered it lacking, so on zsh I remain.
    • Tmux, the terminal multiplexer, which is (almost) invariably the first child of every terminal (rio -e 'tmux attach -t#'). Because terminals crash, because it survives session restarts, because it lets me log in remotely and continue what I started in my desktop, and because it works over ssh and having a consistent multiplexer environment across machines is nice. I used sceen for years before discovering tmux, and have tried almost every other terminal multiplexer; and none add any significant value for me over tmux.
    • Helix, the editor in which I spend most of my time. Because I started with emacs and used it for years before switching to vim. Then I used vim for decades before switching to Kakoune. Then I used Kakoune for about 2 years before switching to helix. Kakoune was too much like Emacs for my taste: heavy on chording, light on modality. Helix is much more like vim: lighter on chording, more mode-driven. Chording aggravates my carpel tunnel, and I’m more comfortable in modal editors. I switched from vim because the plugins necessary to be a competent development environment got insane, and my vim was starting to take as long to start up as emacs, which was unacceptable. Also, LSP integration was super flaky and broke every six months; it’s what initially drove me to Kakoune.

    I’m currently using Rio as my terminal. It has bugs, but it’s actively developed and regularly releases will fix one more thing. It has both ligature and sixel support, and it’s wildly fast and far, far less memory intensive than either kitty or ghostty, which are both pretty fat. I am not including it in “the list” because some remaining bugs are pretty big, like randomly crashing when it gets resized or sees some sequence of asci escape codes. It’s not much of an issue because I run everything in tmux, and it crashes less with every release, but I hesitate to recommend it until it’s more stable.