Related problem

Related #13670

Goal: The environment variables visible to the user and internal configuration state should match.

It seems to me that an 893-line config (plus 101-line env) is overwhelming to many users, possibly even leaving a bad first impression to some. Regardless, it seems far more "cumbersome" than it should be.

Right now, a user has essentially two choices:

1. Accept an 893-line config.nu and add to it (either in the file or through other files). In this case, the $env.config will be populated with the defaults that are in that file, with overrides by the user. The user can introspect the default values by observing, e.g., $env.config.table.mode.

   This is currently the only way to achieve the "Goal" above.

2. Run with their own minimal config, but lose the ability to introspect the internal state, other than by reading through config nu --default and comparing what they've changed.

(config.nu example used here, but env.nu behaves the same)

Describe the solution you'd like

Internal defaults are obviously essential, but they don't all need to be exposed in the user's configuration files. For example, see almost every other shell config ;-)

My thoughts:

• Get rid of the prompt to create config.nu and env.nu. Do it automatically if and only if the user is running for the first time (see Only ask user if they want to create a config.nu and env.nu one time #13669) and the $nu.default-config-dir doesn't exist.

  • Corollary: If the user deletes either file after first-run, don't regenerate them (a Fish-shell pet peeve I have ;-)

• Always load default_env.nu and default_config.nu unless the user has started with nu --no-config-file/-n.

  • Yes, this includes when running with nu --config <file> or nu --env-config <file> so that the defaults are populated in memory.

• Only write a minimal config.nu and env.nu that look something like:

  # Use config.nu to override default $env.config settings,
  # define (or import) custom commands, or run any other
  # startup tasks.
  # 
  # This file is loaded after env.nu and before login.nu
  # To examine the defaults, run:
  # config nu --default | nu-highlight

  # Use env.nu to add or override environment variables.
  # This file is loaded before config.nu and login.nu
  # To examine the defaults, run:
  # config env --default | nu-highlight

Advantages:

• Users who want to put everything in config.nu can always just generate it with config nu --default | save config.nu (and with env.nu)
• I think that loading default_env.nu would also get rid of the hacky "must treat PATH as string in config" issue, since the $env.ENV_CONVERSIONS would already be in place by the time any user-written code is parsed.
• Should be pretty much no impact to startup time since the default_config.nu et. al. is the same size and parsing-time as the one that is written to disk by default now.
  • (From thread below) Even if a user duplicates the default config and env on-disk, the parsing and eval time is negligible - only a hair over 1ms on my system.

Describe alternatives you've considered

No response

Additional context and details

Note: About the only reason to not load the default_config.nu/default_env.nu when the user specifies --no-config-file is for performance reasons and testing. If this idea was implemented, it would be nice to have a separate --no-user-config that still loaded default_*.nu but not the on-disk, user files.