Feature: Allow-list support

[vasi]

Is your feature request related to a problem? Please describe.

There are three keyboard shortcuts that I currently want to change in KDE 6. I can do that using the kglobalshortcutsrc file, which is great!

But that file is quite large, and grows every time a KDE component thinks of a new thing that users might want a shortcut for. On a brand new installation, with few added KDE apps, I see 262 lines.

The ways I can see to deal with this don't satisfy me. Either I end up with a large config file; or a large set of ignores; or I lose the ability to add changes. See discussion under "alternatives" below.

Describe the solution you'd like

There's a couple options here. I've listed my favorite first,

1. Magic ignore unspecified directive

This directive would indicate that all keys not specified in the src.ini file should be ignored. A user could just include this one directive, put the three keys they care about in their src.ini, and they've happily ignored all irrelevant config.

I honestly would use this on most of my KDE config files.

2. include directive

This would basically be the inverse of ignore. If a user specifies:

include "sectionA" "keyA"
include section "sectionB"
include regex "sectionC" "prefix.*"

Then all .ini items that don't match any of those are assumed to be ignored. For simplicity's sake, we should probably error if a config has both include and ignore entries, since otherwise it gets confusing to reason about what takes priority.

With this option, my src.ini file would only contain the three specific lines I care about, and my modify_ script would contain an include directive for each of them. It's a bit harder to use than the magic ignore unspecified, but it might be good to be less magic.

Describe alternatives you've considered

Alternative 1: Just store the whole file in my src.ini

This is the most obvious thing to do, but I find it pretty awkward:

• My three important changes are hidden among hundreds of lines of things I don't care about.
• Every time KDE adds a new action that can have a global shortcut, the file is listed as a chezmoi diff.

Alternative 2: Liberal use of ignore

I'd store a minimal src.ini with just my changes, and use ignore section and ignore to make everything else be ignored. This is less irrelevant config, but still:

• I have a bunch of ignore lines that I don't really care about.
• I may have to modify my ignores when new actions are added to KDE, though less often than above.

Alternative 3: Combine set and ignore regex

The following config almost works for my needs:

ignore regex ".*" ".*"
set "section" "key" "value"

Only the keys I care about are listed, and chezmoi diff does what I expect and lists any changes. The problems are:

• chezmoi_modify_manager add does not do what I want. It yields an empty src.ini, because everything was ignored; and does not list any changes.
• Even if it did work, it's quite unintuitive. The set directive is documented as "primarily useful together with chezmoi templates", so it wasn't at all obvious that I should try this.

[VorpalBlade]

This seems like a reasonable request to me. I need some time to think of the design though (not only for the user interface, but also the internal algorithm).

Some idel musings about possible other ways to do this:

• Ignore unspecified should take a regular expression matching the section name. This would be strictly more flexible (and you could accomplish your goal with a simple .*)
• I'm wondering (and I'm not sure it currently works this way) about:
  • Plain regex ignore of everything
  • An empty src.ini
  • Using the set directive for things you want to change.
    This would not require adding new features, but I'm not sure about the evaluation order. It might even work currently!

[vasi]

• I'm wondering (and I'm not sure it currently works this way) about:

  • Plain regex ignore of everything
  • An empty src.ini
  • Using the set directive for things you want to change. This would not require adding new features, but I'm not sure about the evaluation order. It might even work currently!

I tried this, and mentioned it above. It does almost work, but it doesn't allow syncing anything back from the destination to the source (ie: chezmoi_modify_manager add).

[VorpalBlade]

How do you imagine add should work with your ignore unspecified? This is, perhaps surprisingly, likely to be the trickier of the two "modes" to implement, because add doesn't actually look at the .src.ini file, only the directives and the system state. I was assuming add would simply be unsupported with ignore unspecified.

[vasi]

My mental model for how add works now is that it applies the ignores to the target file to produce the src.ini. Is that right?

So for ignore unspecified, it would have to read the src.ini to find out which keys to include, and then apply that to the target on add. I do agree it makes implementation trickier.

[VorpalBlade]

Is that right?

The algorithms are documented at a high level. It has been a while since I did anything with this code myself, so I'm going to point you at that page rather than trust my own memory.

Perhaps (as you also wrote while I was writing this), it could parse the .src.ini file to get a collection of (section, key) and use that as a filter. That would be simpler than trying to make a version of the merging algorithm for this direction. Filtering is currently so much simpler.

Downside: You would loose comments and formatting in your src.ini. It would just be the filtered sections and keys copied verbatim from the system state. Perhaps something you can live with?

[VorpalBlade]

Note to self (or whoever implements this): In fact, handling of blank lines and comments need some consideration and tests to ensure that something sensible happen in both merge and filter directions.

There are currently data-driven tests for merges, but none for adding. With this change I think the add algorithm becomes complex enough to warrant these style of tests as well.