Rationale for and/or story behind lisp-like config syntax?

[riotrah]

Hey there!

This project is crazy sick for what appears to be a mostly one-person show.

I was just curious what the story or reasoning was for arriving at a lispy syntax for config. I've been using clojure at work (my first lisp ever, of course) and I've become absolutely enamored with it.

( despite the frustration dynamic typing induces when making non-trivial changes in huge codebases).

But s-exps are a very interesting choice I feel for someone who's admitted to also being new to them, and for a project whose own source is in rust. I know that one of my favorite features of clj/lisps is metaprogramming and homoiconicity, which has made making linters, codemods and reflection tools trivial - stuff I'd never thought I could do without tons of reading and use of free time at least. I imagine that's a reason for kanata's use of them? And also, how did you even think of lisps for this, versus something like python or js or static yaml files or something? Was there a prior art or mistakes made along the way that led you to seek a better syntax/language, etc?

Either way, thanks!

[jtroo]

Short answer: kmonad did it, haha

Long answer: I wanted a configuration language that could express the features that projects like QMK can express via writing C code. I wasn't initially looking to write kanata, I was actually hoping kmonad would satisfy all my use cases. After I discovered that kmonad didn't fit my taste, in my quest to get something working as fast as possible, I picked something proven to work (kmonad), easy to parse (because I'm lazy), and that was a S-expression based config.

The kanata cfg language is solely intended to be a configuration language and not a turing-complete language. It exists solely to configure a keyberon layout state machine, which is more prior art I relied on to get started quicker.

Kmonad seems like it's trying to do more advanced stuff for configuration with Dhall, which is interesting.

[gerhard-h]

@jtroo

After I discovered that kmonad didn't fit my taste,

I wonder what you didn't like about kmonad?
I came from QMK but home row shift always had timing issues, and after one year on 40% I wanted my number and function key row back.

I swiched from kmonad to kanata because there where

• less non-US windows issues (AltGr)
• and the option in kanata to not interfere with keys not on defsrc (AltGr again).
• a leader key feature (wich I don't use in the end)
• Interception driver option (wich - so far - I never tried)

In retrospect I'm not sure this reasons are that valid.
And only thereafter I discovered kanata could do even more of the stuff I was used to from my QMK board.

But none of this reasons seems to have been your motivation to start kanata, or was it?

[jtroo]

The reasons I built kanata are the ones I listed in the comparison doc.

I use home row layer-changing with tap-holds so the first two points (no TAPPING_TERM equivalent, weird shift timing issues), were pretty problematic for me. I first tried poking around the Haskell code to see if there were easy fixes, but I don't know Haskell well enough so I gave up on that. Maybe it would have been a good reason to start learning Haskell, but I also had issues compiling on Windows, though I eventually succeeded. Haskell also has, from my reading, well-known stability and breaking change issues due to it being focused on being a research language, so from a practical perspective I'm not too interested in learning it.

For the mouse buttons point, I frequently click mouse buttons with my keyboard. When I use a trackpad (like on a laptop) or a trackball (like I use when using my split keyboard), I find clicking mouse buttons with one hand and moving the mouse with the other hand to be quite nice.