Move settings file to app config folder and add commands to modify

[alexdewar]

Description

This has been bugging me for a while, so I've had a go at it, even though it's low priority.

Currently the program settings are loaded from a settings.toml file in the CWD, if one exists, but this isn't ideal -- users should be able to change directory without the program settings changing!

There are standard places to store program config files (differing between OSes), so we should use this as a place to store the settings file instead. However, in doing this, it may make it harder for users to figure out where they should be creating their settings file etc., so I think it makes sense to add some helper commands to make this easier.

I've added a settings edit command, which allows users to edit the program settings. If the settings file doesn't exist, a placeholder file with the options commented out will be created. I'm using this crate to open the file with an appropriate text editor and I think whatever default heuristics it uses should be fine. I'd be interested to know what happens if you try it on your own systems though!

Besides that, I've also added some other commands that should be self explanatory.

Closes #255.

Type of change

• Bug fix (non-breaking change to fix an issue)
• New feature (non-breaking change to add functionality)
• Refactoring (non-breaking, non-functional change to improve maintainability)
• Optimization (non-breaking change to speed up the code)
• Breaking change (whatever its nature)
• Documentation (improve or add documentation)

Key checklist

• All tests pass: $ cargo test
• The documentation builds and looks OK: $ cargo doc

Further checks

• Code is commented, particularly in hard-to-understand areas
• Tests added that prove fix is effective or that feature works

[codecov]

Codecov Report

❌ Patch coverage is 11.49425% with 77 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.18%. Comparing base (204082b) to head (1ffefac).
⚠️ Report is 28 commits behind head on main.

Files with missing lines	Patch %	Lines
src/cli/settings.rs	0.00%	60 Missing ⚠️
src/settings.rs	58.82%	7 Missing ⚠️
src/lib.rs	0.00%	6 Missing ⚠️
src/cli.rs	0.00%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #860      +/-   ##
==========================================
- Coverage   86.67%   85.18%   -1.49%     
==========================================
  Files          48       50       +2     
  Lines        5244     5300      +56     
  Branches     5244     5300      +56     
==========================================
- Hits         4545     4515      -30     
- Misses        481      565      +84     
- Partials      218      220       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull Request Overview

This PR moves the settings file location from the current working directory to a platform-appropriate config directory and adds CLI commands to manage the settings file. The change improves user experience by making settings persistent regardless of the working directory.

• Relocates settings.toml from CWD to OS-specific config directory (e.g., ~/.config/muse2/settings.toml)
• Adds new settings CLI subcommands for editing, deleting, showing path, and dumping default settings
• Updates documentation to reflect the new settings management workflow

Reviewed Changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/lib.rs	Adds get_muse2_config_dir() function to determine platform-specific config directory
src/settings.rs	Updates settings loading to use config directory instead of CWD, adds path helper function
src/cli/settings.rs	Implements new CLI subcommands for settings file management
src/cli.rs	Replaces DumpDefaultSettings command with new Settings subcommand group
docs/user_guide.md	Updates documentation to show new settings management workflow
Cargo.toml	Adds dependencies for directory resolution (dirs) and file editing (edit)

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[alexdewar]

I've found a bug (on main, sadly), so I'm putting this into draft for now.

[alexdewar]

Everything should be working now, so this is good to review.

[dalonsoa]

I cannot test it today - wrong laptop :P - but will do so first thing tomorrow.

Otherwise, it looks OK. I just have a minor comment.

[dalonsoa]

I would call this View to see the current settings in the terminal, which would be the default ones if there are no custom settings configured. If you want, you can add a ViewDefault, which always shows the default values, regardless what the current settings are.

[alexdewar]

Good idea! I've named them show and show-default instead.

[dalonsoa]

Works well. In my case, in MacOS, the edit command opens pico - who knows why, because that is ancient.

[alexdewar]

Works well. In my case, in MacOS, the edit command opens pico - who knows why, because that is ancient.

Interesting. Well, at least it picked something usable... If you set the EDITOR environment variable to something else, it should use that instead (other programs like git use this as a fallback when trying to guess what editor to use).

[tsmbland]

This is cool! edit opens vscode for me. Apart from what Diego suggested which I agree with, two points:

• settings path gives a path even if there's no settings file - is this intentional?
• All the parameters are commented out when I first open the settings file, but I think this is a bit unclear and unnecessary

[alexdewar]

This is cool! edit opens vscode for me. Apart from what Diego suggested which I agree with, two points:

• settings path gives a path even if there's no settings file - is this intentional?

Yep. I thought it was useful to tell the user where the settings file should live, even if it's not there. But I suppose we could also print an error saying the file isn't present (preferably also including the file path).

• All the parameters are commented out when I first open the settings file, but I think this is a bit unclear and unnecessary

This is a pretty common thing to do with placeholder config files. If the user wants to change something explicitly they can just uncomment whatever line they want and at least then we know that any option that's been set was done on purpose. If they were all uncommented by default, that means that if we change the default value in a later version of MUSE2 (or even make the old default value invalid), then the user will get potentially strange behaviour if they have ever run muse2 settings edit.

[tsmbland]

This is cool! edit opens vscode for me. Apart from what Diego suggested which I agree with, two points:

• settings path gives a path even if there's no settings file - is this intentional?

Yep. I thought it was useful to tell the user where the settings file should live, even if it's not there. But I suppose we could also print an error saying the file isn't present (preferably also including the file path).

I'd probably go with the latter but totally your call

• All the parameters are commented out when I first open the settings file, but I think this is a bit unclear and unnecessary

This is a pretty common thing to do with placeholder config files. If the user wants to change something explicitly they can just uncomment whatever line they want and at least then we know that any option that's been set was done on purpose. If they were all uncommented by default, that means that if we change the default value in a later version of MUSE2 (or even make the old default value invalid), then the user will get potentially strange behaviour if they have ever run muse2 settings edit.

Good point. I didn't think about that. In that case, I would just add a note in the file explaining that the comments show the defaults at the time of file creation (not necessarily the current defaults), and to uncomment any parameters that they want to change

[alexdewar]

I'd probably go with the latter but totally your call

I'm happy with that. I'll fix up.

Good point. I didn't think about that. In that case, I would just add a note in the file explaining that the comments show the defaults at the time of file creation (not necessarily the current defaults), and to uncomment any parameters that they want to change

Sure. The more documentation the better 😄