Add completion for dconf

[radomirbosak]

dconf works with a key-value database organized in a tree-like structure. I would be helpful to have completions for the key paths.

e.g.

$ dconf read /org/<TAB>

would suggest

gnome/
gtk/
gnucash/

which can be obtained by running

$ dconf list /org/

[krader1961]

Patches are welcomed, @radomirbosak. We're happy to answer questions if you need help getting started but a good starting point is to review some of the existing command completion scripts.

[faho]

I had a few minutes of free time and an itch to write some completions, so I fixed it. Sorry 😅.

Anyway, it turns out that dconf list results in a very weird experience - you'd do

$ dconf read <TAB>
$ dconf read /org/<TAB>
$ dconf read /org/gnome/<TAB>

and so on just to end up with dconf read /org/gnome/terminal/legacy/schema-version.

Using dump gets around that.

[radomirbosak]

Wow, that was fast! Thanks @faho . 👍

I still think though that it makes more sense if the dconf completion was like the file/dir path completion in fish - to complete only one directory at a time.

Consider this scenario: let's say my key which I am looking for is somewhere under /org/gnome/. I don't know which directory I should follow after that, but I would probably recognize it if I saw its name. But after typing

dconf read /org/gnome/<TAB>

I get a lot of keys from /org/gnome/desktop/ which are irrelevant for me and I have to scroll down a lot to reach e.g. /org/gnome/shell/* keys. With dconf list-type completion I would get to choose only from

settings-daemon/
shell/
nautilus/
system/
evince/
evolution-data-server/
desktop/
eog/
terminal/
nm-applet/
evolution/
Totem/
software/

where its (obviously) easier to find the shell subdir

However, I must say that also the full-path completion style has its benefits - if you know the filename/part of the path you can search much easier:

$ dconf /<TAB><KEY_DOWN>location
search: location    
/org/gnome/shell/extensions/openweather/geolocation-provider  /org/gtk/settings/file-chooser/location-mode
/org/gnome/system/location/enabled

I can't say I have a strong opinion about this, but I think the dir-by-dir-type completion is more intuitive for users (as it is used for file/dir path completions). Writing long paths is IMHO well covered by suggestions if the user wants to use them more than once.

Maybe it would be best if both completion styles were available. (I'm not sure how.)

[faho]

It's probably worth noting that I'm not running gnome, so the only thing I have using dconf is gnome-terminal and mate-terminal, which I sometimes use for testing. That means I have a total of 20 keys and don't know how this would feel if I had more. How many keys do you have on gnome?

However, I must say that also the full-path completion style has its benefits - if you know the filename/part of the path you can search much easier:

It's actually even quicker to just type dconf read location<TAB> - we have "fuzzy" (really "infix") completion, so the current token can also appear in the middle.

I still think though that it makes more sense if the dconf completion was like the file/dir path completion in fish - to complete only one directory at a time.

The main issue I have there is that the first part is almost always "/org/", so you end up typing a lot, since you either do "dconf read /<TAB>, pick '/org/', pick the first actually interesting part" or "dconf read /org/<TAB>".

Additionally, I actually started out using dconf list, but that stuff is sooo picky with regard to a trailing "/" (there must always be exactly one) that it was annoying and so I tried a different route. The current code is much easier. Though it's also possible I was just overthinking it.

Maybe it would be best if both completion styles were available. (I'm not sure how.)

This is one of those cases where we should just pick one. If anyone really prefers another, they can override the completion.