A bigger feature missing in most GUIs is that I can't tell what has changed from the defaults. On the other hand, most text configuration files contain only what has changed from default, which is exactly what I want to know.
I would say the biggest problem with text configuration files is that you can't ever be sure what the default is.
The problem is that:
1. Config files need _visible_ defaults
2. Config files need to show current values
3. _Config files need comments_
4. Config files need to be small or they get unreadable
Doing all four is tricky. Postfix gets close:
postconf will show you all config entries. Add -d to get defaults instead. Or try -n to show settings which have been changed.
Even with Postfix you have the big file/comments problem, so what you do is refer to a copy of the original main.cf file, or one stored in the docs under /usr/share/doc/postfix for a thorough explanation of all settings and keep a bare minimum config file with comments in /etc/postfix.
> I would say the biggest problem with text configuration files is that you can't ever be sure what the default is.
Arguably defaults are always there, whether configurable or not. Thus you cannot claim to be familiar with an application unless you know how it behaves in its default configuration (whether that is in a GUI or a text file).
I think this is fundamental and not an issue that configuration (text, GUI or otherwise) needs to deal with.
> 1. Config files need _visible_ defaults
I agree, but I don't see that this should be in the config file. I do think that there should be a way to see what these are. Your postconf example is perfect for this.
Like you, I'm in favour of keeping the bare minimum config file only. Comments should only describe something local about the site (just like "i += 1 # add one to i" is wrong). Documentation of configuration variables should be somewhere else.
> Arguably defaults are always there, whether configurable or not. Thus you cannot claim to be familiar with an application unless you know how it behaves in its default configuration (whether that is in a GUI or a text file).
I don't agree with this part. The best way of learning about a program is to play with it. Knowing how a program is expected to behave is key, and without defaults you don't.
Even if someone knows the defaults, they will change.
The problem of making the defaults transparent has been solved a long time a go.
Standard convention for a lot of software is to have one config file (for instance often with the extension .dist) with all the default settings, and lots of comments about them, and a local config which is the one you edit.