Note that this is primarily a syntactical choice -- there isn't _currently_ much in the configuration language that actually resembles the functionality from regular lisp languages. I've been thinking quite a bit about how I could make use of the s-expression based syntax to turn yuck into a more feature-rich, actual lisp language, without completely going out-of-scope ^^
I saw the Janet language mentioned a few times on HN recently and it looks like a nice flavor of lisp that’s also embeddable. Maybe that would be useful for EWW?
I haven’t used Janet much other than going through the beginning of this book here, but here’s the link to a good book and the Rust bindings of you want to check it out.
I've been following eww's development on the sidelines for a while. I wondered if you considered making it callable as a library, for some scripting language (e.g. python or lua or something), rather than growing your own bespoke language? To me it seems you risk people demanding more and more features in the "configuration language", and it turns into a (bad) fully Turing complete programming language before you notice. Like in the configuration complexity clock[1].
I've definitely considered it, and I do see the points of yuck either becoming a bad, turing complete lisp, or being just,... not powerful enough. However, I have two main counterpoints to the idea of turning it into a library for some scripting language like lua:
- The original goal of eww was to be two-dimensional polybar with support for full visuals and CSS, rather than just colored text. This means that my target audience, at least initially, was also more the polybar crowd than the awesomeWM crowd. Eww aims to be usable without really needing to know how to program, and aims to provide declarative UI description language that reduces complexity of state management and logic as much as possible. This is, arguably, a goal I've at least somewhat reached -- primarily given the fact that eww DID grow quite fast, and did enable lots of people to do more interesting UI designs than other projects (such as AwesomeWM) did. "Widgets for everyone" is a tagline I don't wanna leave, and thus requiring users to do full-on scripting is not something I'd wanna do easily.
- if you remove yuck and it's state management architecture from eww, you'll be left with quite little. Thus, there would at that point be little added value over existing GTK wrappers. The thing that makes eww appealing (at least IMO) is that it does simplify lots of the most commonly needed things down to a very simple state and UI structure, and provides a great iteration-cycle with great error messages. This would be very hard to keep when turning it into a regular, more imperative library
