new blog: composable keybinds should be everywhere

src/blog/composable-keybinds-should-be-everywhere.djot

@@ -0,0 +1,55 @@
+---
+title = composable keybinds should be everywhere
+ctime = 2024-09-23T13:21:40Z
+TB_TITLE = not vim!
+---
+
+the title is a little clickbait\--it should really be "composable keybinds should be in a lot more places than just text editors", but that's a little long for a blog title.
+
+I started using vim when I started using linux basically. I can't remember why exactly I started\--was it because of the claim of "vim is crazy efficient" or "vim is everywhere" in an effort to be hip with the cool linux kids? not sure. in any case, I really enjoyed working with it! I never really got too deep into vim-fu\--trying to puzzle out the exact obscure editing commands that would minimize keystrokes and save like... maybe 0.5 seconds at most compared to no-brain doing "less optimal" keystrokes wasn't really my thing
+
+I switched to [kakoune](https://kakoune.org/) for my text editing work some months ago, but that's not the point of this post (debate the editor war on your own time). the point is, vim's composing-keybinding style stuck with me, and seeing that kakoune is an editor inspired heavily by vim, I wanted to try it as well! the way kakoune approached its model editing flow felt like a nice, fresh experiment compared to vim, which kept me around to using it and eventually just removing vim from my system as a whole
+
+the main takeaway is that I think composing keybinds is a bit... under-represented in the software sphere right now. we really only have it in text editors, and really only because vi existed all that time ago. and yet, for some use cases, I must wonder how keybindings could be if they were made "modal" or "composing", and whether they'd work better for the application's purpose, if not just for me
+
+## gimp (and other image editors)
+
+take gimp. it's an image editor. it edits images. there's a few different ways you can interact with an image in gimp:
+
+* tools, like a paintbrush, pencil, fill, etc.
+* filters, like a blur across the whole image, distortions, etc.
+* selections, like rectangle, circle, etc.
+* paths, like a curved path to fill in later or reference, text outline paths, etc.
+* and many more...
+
+the fact that one can group a bunch of related things screams composability to me. currently, I have `s` bound to the rectangular select tool and `Shift+e` bound to the ellipse tool, since `e` normally is taken up by the eraser. I have `v` for fuzzy select and `Shift+c` for color select, since `c` is for clone stamp and I just couldn't find any other key that fuzzy select could be on. instead of having `s` be meaningless on its own but rather a keybind specifically for rectangular selection, what if we had this schema:
+
+* `s` -> enter selection mode
+* `se` -> select ellipse
+* `sr` -> select rectangle
+* `ss` -> select scissors
+* `sf` -> select foreground
+* `sw` -> select wand
+* `sc` -> select color
+
+not only does this allow for semantically sensible keybinds, but it additionally compartmentalizes keybinds into their own quarters of the application, allowing for the keyboard keys to be free for other modes and keybinds. this means we can make something like...
+
+* `t` -> enter tool mode
+* `te` -> eraser tool
+* `tf` -> fill tool (gimp calls it "bucket fill", but whatever)
+* `tb` -> brush tool
+* `tB` -> pencil tool (as opposed to needing to use two hands/move a lot to reach `p`)
+* `tc` -> clone stamp tool
+* ...
+
+you can see the vision here right. because of having these separate "modes" to branch other keybinds off of, less cognitive overhead is spent trying to remember the obscure keybind you set a month ago or breaking your wrist to chord the correct keybind on one hand. yeah, maybe it'll be slower compared to someone who _does_ know their existing keybinds like the back of their hand, but the speed difference is negligible for something like gimp (and arguably the speed difference modal editors do with their "hyper optimized bindings" is greatly exaggerated)
+
+## other places
+
+I know blender has somewhat composable keybinds. some keybinds pop up a little menu that you can select from, but (I don't think) you can compose another keybind to select something in that menu without using arrow keys or whatever. can't remember\--someone who has used blender more than I can probably chime in on this more. but in any case, it'd be nice to see proper modal editing and/or composable keybinds there
+
+I've used pentadactyl on pale moon for many years now. I like being able to use `gt/gr` to go right and left in my tabs. I like `gg` and `G`. I like using `d` and `u` to scroll pages, `p/P` to paste a url, `t/T` to open, `o/O` to open, all the like. I'm not nearly an expert pentadactyl user\--some things in a web browser are just better to do with a mouse\--and the simple existence of "single/double key keybinds" isn't exactly "modal" or "composability" to its fullest, but it's a neat thing that I enjoy using and would like to see more
+
+## the conclusion paragraph
+
+yeah this was kinda just a no brainer hour-long writing spree about this so I could get my thoughts all on one page. I'd like to see composable keybinds and "modes" of a program be explored more outside text editors, because I feel like there are places where they can work well. of course, not everywhere, but not an insignificant amount of applications. I think it'd be cool