Victoria Dye <vdye@xxxxxxxxxx> writes: > I'm also still worried about cluttering scalar's UX with options that toggle > use of its internally-configured options and features. One of the big > selling points for including scalar in the upstream project ([2], [3]) was > its ability to "intelligently" configure all of the settings a user would > need to optimize a large repository *without* a user needing to know what > any of those options are/what they mean. These settings are inherently > subject to change (due to use of experimental features); exposing a feature > toggle entrenches that setting permanently within scalar and makes a user > aware of implementation details that were intended to be hidden. At a high > level, it pushes scalar towards simply being an "opinionated" 'git > config'-configurator, which was a model I explicitly tried to move away from > while upstreaming last year. I personally do not think "opinionated configurator" is a bad model at all. And "this does not seem to work here, so let's silently disable it, as the user does not want to hear about minute details" is a valid opinion to have for such a tool. I too share the aversion to command line option for this one. Disabled periodic task support is most likely system-wide, and passing --no-whatever every time you touch a new repository on the same system does not make much sense. Thanks.
