Source sys and data configs

[davispuh]

Source config files from paths like /etc/fish/*.fish for sysadmins and /usr/share/fish/*.fish for distributions/vendors.
This basically implements #1956

[faho]

Please see my comment in #1956.

One thing you don't do here is the precedence system - files in $__fish_sysconfdir should override files in $__fish_datadir (I'd say they should even if they are empty or unreadable) and those in $XDG_CONFIG_HOME/fish should take precedence over both.

Another is that this doesn't implement "vendor" directories for eagerly loaded files (to put their event handlers in).

The third point is it doesn't handle the lazy-loaded ("function") part at all.

Now, I'm not saying that my proposal is the end-all-be-all, but this is certainly a lot simpler. In my opinion, it's too simple.

[davispuh]

I agree with all what you said, but currently we don't have anything working so I thought I'll make this quickly while someone implements it properly :P That issue have been open since Feb and no one have come up with code.

It's so simple, because it was really quick to implement this and get something working atleast. Of course I agree that proper implementation would be better but I don't know when I'll have time for that.

[faho]

I see where you're coming from, I just don't think a simple stop-gap solution helps in this case. For one, this is an interface for other projects to rely on - so if they start using the stop-gap, we must either keep things that way or ask others to switch again.

For a competing mock-proposal, see #2498.

[krader1961]

I'm happy to see a concrete implementation to further the discussion but don't think this should be merged in its present state. One of the reasons I decided to abandon zsh was that too many changes like this one were adopted without a discussion of the pros and cons of the proposed solution and the alternatives. The seductive pull of "this solution isn't optimal but it sorta kinda works and no better solution has been presented" needs to be resisted other than as a way to drive the discussion forward.

[zanchey]

I definitely prefer the approach in #2498, so I'm going to close this for now - but thanks for getting the conversation moving!