Use Emacs-like configuration

[Frewacom]

Replace the current configuration method with an Emacs-like configuration, just like in dwl-guile.

[ReilySiegel]

For what my opinion is worth, I don't see why an emacs-style configuration is a particular benefit over the standard records-based configuration that most guix services (both home and system) use.

With a record based configuration, it is easy to figure out which options are available in-editor by jumping to the definition of the record. With an emacs-style configuration, you have to employ some combination of searching online documentation and grepping the codebase for definitions. When setting up dwl-guile, it took me a while to find the tap-to-click? option, because it was not documented in the manpage, and github's search did not return the part of the code where it was defined in a search for "tap", "tapping", or similar searches. Eventually, I found the option by reading the commit log, as I was in the process of opening an issue requesting a feature that already existed. If the configuration was specified as a guix record instead, this whole search could have been avoided by a simple jump-to-definition.

Further, I think the record-based config style lends itself more naturally to derivative services and extensions. Let's say that I wanted to create a derivative service that handles everything battery-related: run a daemon that sends a notification on low battery, and display the status of the battery in dtao. That way, I could add one service to my devices which are battery powered, and exclude it from devices which are not. With an emacs style configuration, assuming the interface would be similar to set-rules in dwl-guile, how I would go about doing this is not clear, as it seems repeated calls to set-rules would override previous calls. I might resort to creating variable containing a list of rules which extensions could add to, and then call set-rules in the init hook after all config has been loaded, but this tightly couples extensions to the base service (if I change the name of the variable in my base config, I would have to change it everywhere), and is basically a domain specific re-implementation of guix's existing service-extension mechanism.

[Frewacom]

The main benefits from my side is that I do not need to keep the home service record up-to-date with the code, as well as improving the hackability by making it easier to update the config dynamically using e.g. the REPL. Imo, it also makes it easier/possible to configure without forcing you to use the home service.

With a record based configuration, it is easy to figure out which options are available in-editor by jumping to the definition of the record. With an emacs-style configuration, you have to employ some combination of searching online documentation and grepping the codebase for definitions.

Yes, I agree. This was one of the reasons as to why I added dwl:list-options and dwl:list-keys. to dwl-guile, though it does not actually show any description for each entry. They are of course just available once you have actually gotten everything setup, so they might not be super useful.

how I would go about doing this is not clear, as it seems repeated calls to set-rules would override previous calls

I might have missunderstood, but you can call set-rules (an all the other set-* functiions) multiple times without overriding the previous calls, as long as the rule(s) you are adding have a unique id/title. If a rule you are adding have the same id and title as an already existing rule, it will override the properties of that existing rule, otherwise it will add it as a new rule.

Let's say that I wanted to create a derivative service that handles everything battery-related: run a daemon that sends a notification on low battery, and display the status of the battery in dtao. That way, I could add one service to my devices which are battery powered, and exclude it from devices which are not.

Wouldn't a separate configuration be generated for each device, resulting in just one instance of the battery service for each device?

Thanks for you input! If you have any suggestions on how to improve the configuration in dwl-guile (other than to revert back to using a record 😄), let me know.

[ReilySiegel]

I might have missunderstood, but you can call set-rules (an all the other set-* functiions) multiple times without overriding the previous calls, as long as the rule(s) you are adding have a unique id/title. If a rule you are adding have the same id and title as an already existing rule, it will override the properties of that existing rule, otherwise it will add it as a new rule.

Thanks for pointing this out. I was under the assumption that multiple calls of set-* functions overwrote the previous calls destructively, the same way calling set! on a variable would. I also completely missed the dwl:list-options variable, which was of course right in front of my face on the documentation.

[Frewacom]

I might have missunderstood, but you can call set-rules (an all the other set-* functiions) multiple times without overriding the previous calls, as long as the rule(s) you are adding have a unique id/title. If a rule you are adding have the same id and title as an already existing rule, it will override the properties of that existing rule, otherwise it will add it as a new rule.

Thanks for pointing this out. I was under the assumption that multiple calls of set-* functions overwrote the previous calls destructively, the same way calling set! on a variable would. I also completely missed the dwl:list-options variable, which was of course right in front of my face on the documentation.

Yeah, I think the set-* naming scheme can be easily misunderstood. Maybe something like define-rules or add-rules could be a better alternative?

[ReilySiegel]

I think add-rules would probably be the most clear.