Configuration overhaul (#30)

[Seeker04]

Configuration overhaul:

• Settings are no longer compiled in, only loaded during runtime
• Settings can be changed dynamically (with set/2 and add/2)
• Any setting can be omitted, because everything has a default value
• Default settings are installed to /etc/plwm/config.pl
• reload_config/0 re-reads config file
• dump_settings/1 dumps current setting values to a file
• Config files must NOT use module declarations (settings are in the global namespace)
• bar_class/2 became bar_classes/1 taking a list (all settings must have arity 1 and be deterministic)

Closes #30.

[Seeker04]

I wrote a summary in the PR description on what changed from a user perspective. Existing configs should work if 1.) the module declaration is removed from the top, 2.) bar_class/2 is turned to bar_classes/1.

@xelxebar Hi! Would you mind having a look at this? The diff is quite large, so I don't necessarily expect a full code review, but insights on the design change, maybe a quick check how it works.

I left changing the fifo setting as a TODO in the code. Once this gets merged, we can progress further with #101.

[xelxebar]

Solid work! You went deep. I looked through the whole diff and see that removing optcnf_then_else checks everywhere simplifies a lot of the code. On the usage end, default values let us shorten the custom config a ton, and being able to test out new settings without a restart is beautiful.

One thing I just though of, it'd be nice if we could also append to default list values inside the config. Most of my key bindings are default, but I've modified a couple and added a few. It feel unnecessary that I have to set the entire key list in my config.

Is there a reason we have list-valued settings at all? Maybe it would be simpler to store all settings as predicates with atomic values and use findall/3 etc. to convert to a list as needed?

Anyway, very excellent work. I'm consistently impressed by your commitment to thorough documentation.

[Seeker04]

Solid work! You went deep. I looked through the whole diff and see that removing optcnf_then_else checks everywhere simplifies a lot of the code. On the usage end, default values let us shorten the custom config a ton, and being able to test out new settings without a restart is beautiful.

Thank you, I'm glad you like it!

Is there a reason we have list-valued settings at all? Maybe it would be simpler to store all settings as predicates with atomic values and use findall/3 etc. to convert to a list as needed?

I think, having lists is a tad simpler than making some settings non-deterministic (i.e. have multiple solutions). Also, this:

keymap(super         + j  ->  shift_focus(down)).
keymap(super         + k  ->  shift_focus(up)).
keymap(super + shift + j  ->  move_focused(down)).
keymap(super + shift + k  ->  move_focused(up)).

imo looks a little redundant compared to:

keymaps([
  super +         j  ->  shift_focus(down),
  super +         k  ->  shift_focus(up),
  super + shift + j  ->  move_focused(down),
  super + shift + k  ->  move_focused(up)
]).

Though I agree, the first is more Prolog-y:)

One practical advantage of the former I see is that the keymap definitions could be broken up, maybe even to separate files consulted from config.pl. Though I'm not sure anyone would really want to separate these so much...

One thing I just though of, it'd be nice if we could also append to default list values inside the config. Most of my key bindings are default, but I've modified a couple and added a few. It feel unnecessary that I have to set the entire key list in my config.

This is perfectly reasonable.

In fact, you can do half of this already on this branch: keep the default keybindings but add custom ones on top. One way to achieve this is to add a start hook like this to your config:

hooks([
  start -> (
    add(keymaps, "AudioRaiseVolume"  ->  shellcmd("pactl set-sink-volume 0 +5%")),
    add(keymaps, "AudioLowerVolume"  ->  shellcmd("pactl set-sink-volume 0 -5%")),
    add(keymaps, "AudioMute"         ->  shellcmd("pactl set-sink-mute 0 toggle"))
  )
]).

But indeed there's no way right now to remove or modify singular keymaps from the existing. The good news is that I think, keymaps/1 is the only setting that would demand this kind of logic, because all other list based settings are empty by default (other than hooks/1, but I'm already planning on removing those two dummy hooks anyway).

Though I'm not sure what would be a prudent solution for this... If someone defines keymaps/1 it should definitely redefine and not merge with the defaults. So I think, we'd need a "remove" and maybe a "modify" predicate specifically for keymaps/1 for an easy interface to altering the defaults.

Or maybe keymaps/1 could be an exception indeed by being non-deterministic as you suggested. Then we could freely retract and assertz to it...

I'd prefer a simpler solution to both, but I don't see any other from the top of my head. I need to ponder on this a little.

Thank you for checking this so quickly, and let me know if you have any suggestions!

[Seeker04]

One thing I just though of, it'd be nice if we could also append to default list values inside the config. Most of my key bindings are default, but I've modified a couple and added a few. It feel unnecessary that I have to set the entire key list in my config.

@xelxebar Okay, it turned out much simpler than I originally expected.

When registering a keymap, I first remove the previous action mapped to that key combo (if any). So overwriting is possible now. Also, I allow none now as an action, so users can also delete mappings by overwriting to this nop action.

Here I added an example.

[xelxebar]

@Seeker04 Well, that was simple! I love it.