[Feature] Re-organized settings menu + new UI for settings configuration

[grenkoca]

Description

As of v1.25.2, this is the menu presented during settings:

While effective for now, having everything listed as top-level elements to select will limit extensibility and user-customization as user-configurable settings grow.

I think it would be wise to re-organize into a settings interface with sub-menus:

                                                                 
 /settings                                                       
  │                                                              
  ├─ Appearance                                                  
  │  ├── Theme - Change color scheme                             
  │  ├── Title Shape - Customize box title styles                
  │  ├── Nanocoder Shape - Change welcome banner font            
  │  └── ...                                                     
  │                                                              
  ├─ Behavior                                                    
  │  ├── Paste Threshold - Set single-line paste character limit 
  │  ├── Notifications - Desktop notification preferences        
  │  └── ...                                                     
  │                                                              
  ├─ Provider & MCP Overrides                                    
  │  └── ...                                                     
  │                                                              
  ...                                                            
                                                                 

Use Case

Currently, there are 5 user-configurable settings via TUI, but 20+ configurations listed in the documentation. Reorganizing them into a tree structure will i) allow a foolproof method of customizing nanocoder without directly modifying the .json files, and ii) allow future scaling and addition of configurable settings

Proposed Solution

These changes will enable a richer user configuration:

1. Rather than the user typing /settings to customize 5 parameters, have it display a nested directory structure. First level will be broad categories (appearance, behavior, MCPs, etc.). When the user selects one, it opens a sub-menu with more specific settings in that category.
2. Add text-input for certain settings. Multiple-choice options are reasonable for some settings (e.g. banner font), but allowing the user to manually input text for non-enumerated settings (single-line paste threshold, default context size, etc.) is a more viable choice for numeric values and custom filepaths.
3. Along with (2.), add input validation for parameters

Alternatives Considered

• Keeping the /settings as-is
• Implement nested structure without text input for parameters

Additional Context

• I have searched existing issues to ensure this is not a duplicate
• This feature aligns with the project's goals (local-first AI assistance)

Implementation Notes (optional)

There are two main questions that I use input on:

1. Which parameters from docs/configuration/index.md will we enable interactive user configuration for? Are there any we want to exclude?
2. How do we want to group the parameters?

Currently I'm thinking an initial grouping of

1. Appearance
2. Input
3. Providers
4. MCPs
5. WebSearch
6. Advanced

Where Advanced contains options that either are intended for Nanocoder developers (Logging, modifying feature .md files, etc.) or could break the nanocoder configuration (model parameters, environment overrides, etc.)

This is motivated by wanting to implement a handful of new customization features. Namely, i) custom input keybinds, ii) manual editing of theme colors, iii) plugin management, but I'll open those as standalone feature and pull requests. For now, I think it's important to re-organize the settings menu to enable user configuration and extensibility.

I'm happy to implement this, but wanted to get folks' input before making decisions about organization and design philosophy

[grenkoca]

Additional thought: there are some straggling, stand-alone entry points. Namely:

• /setup-config
• /setup-mcp
• /setup-providers
• /ide
• /copilot-login and ./codex-login
• /tune

These are all either one-time configuration commands or just infrequently used. We should consider migrating their entry points to /settings while preserving their UIs. As a design philosophy, maybe migrate everything that requires interactive setup to /settings, and otherwise reserve slash-commands for dedicated workflow actions such as compact, export, etc.

[will-lamerton]

I agree with this - I think it's a good idea! Are you volunteering to work on this or should I assign myself? :)

[grenkoca]

Yep! I'm happy to work on it, but I wanted to solicit input before making design choices.

[will-lamerton]

Yep! I'm happy to work on it, but I wanted to solicit input before making design choices.

I think your break down make a lot of sense. Distilling everything into settings reduces the need for orphan commands and the need to edit config/preference files directly!

I would say anything that requires a need to be written into preferences or agent.config has a case to be in settings.

The only addition I would says is to make it easy to traverse settings so if you choose MCPs for example, you should be able to traverse back to top-level settings instead of getting lost in the MCP wizard :)