Files
fish-shell/tests/checks/fish_config.fish

226 lines
8.2 KiB
Fish
Raw Normal View History

# RUN: %fish %s
# REQUIRES: command -v diff
2025-10-13 15:51:16 +02:00
fish_config prompt list | string match -r '^(?:acidhub|disco|nim)$'
# CHECK: acidhub
# CHECK: disco
# CHECK: nim
diff \
(fish_config prompt list | psub -s config-prompt-list) \
(fish_config prompt | psub -s config-prompt)
2025-10-14 10:18:00 +02:00
fish_config prompt show non-existent-prompt
fish_config prompt show default
# CHECK: {{\x1b\[4m}}default{{\x1b\[m}}
# CHECK: {{.*}}@{{.*}}>{{.*}}
type fish_mode_prompt
# CHECK: fish_mode_prompt is a function with definition
# CHECK: # Defined in {{.*}}functions/fish_mode_prompt.fish @ line 2
# CHECK: function fish_mode_prompt --description 'Displays the current mode'
# CHECK: # {{.*}}
# CHECK: fish_default_mode_prompt
# CHECK: end
2025-10-14 10:27:29 +02:00
function set-all-the-prompts
function fish_prompt
echo left-prompt
end
function fish_right_prompt
echo right-prompt
end
function fish_mode_prompt
echo mode-prompt
end
end
set-all-the-prompts
echo yes | fish_config prompt save >/dev/null
grep '\S' $__fish_config_dir/functions/{fish_prompt,fish_right_prompt,fish_mode_prompt}.fish
# CHECK: {{.*}}/functions/fish_prompt.fish:function fish_prompt
# CHECK: {{.*}}/functions/fish_prompt.fish: echo left-prompt
# CHECK: {{.*}}/functions/fish_prompt.fish:end
# CHECK: {{.*}}/functions/fish_right_prompt.fish:function fish_right_prompt
# CHECK: {{.*}}/functions/fish_right_prompt.fish: echo right-prompt
# CHECK: {{.*}}/functions/fish_right_prompt.fish:end
# CHECK: {{.*}}/functions/fish_mode_prompt.fish:function fish_mode_prompt
# CHECK: {{.*}}/functions/fish_mode_prompt.fish: echo mode-prompt
# CHECK: {{.*}}/functions/fish_mode_prompt.fish:end
2025-10-14 10:27:29 +02:00
echo yes | fish_config prompt save nim >/dev/null
grep -q nim@Hattori $__fish_config_dir/functions/fish_prompt.fish ||
echo 'failed to save prompt?'
not path is $__fish_config_dir/functions/fish_right_prompt.fish
or echo "fish_right_prompt.fish ought to be deleted"
2025-10-14 10:27:29 +02:00
cat $__fish_config_dir/functions/fish_mode_prompt.fish
# CHECK: function fish_mode_prompt
# CHECK: end
2025-10-14 10:27:29 +02:00
fish_config prompt choose nim
type fish_prompt fish_right_prompt fish_mode_prompt |
grep -EA1 '^function.*|.*\[nim@Hattori:~\].*'
# CHECK: function fish_prompt
# CHECK: # This prompt shows:
# CHECK: --
# CHECK: # ┬─[nim@Hattori:~]─[11:39:00]
# CHECK: # ╰─>$ echo here
# CHECK: --
# CHECKERR: type: Could not find 'fish_right_prompt'
# CHECK: function fish_mode_prompt
# CHECK:
2025-10-14 10:27:29 +02:00
fish_config prompt choose disco
type fish_prompt fish_right_prompt fish_mode_prompt |
grep -EA1 '^function.*|.*cksum$'
# CHECK: function fish_prompt
# CHECK: set -l last_status $status
# CHECK: --
# CHECK: if command -sq cksum
# CHECK: # randomized cwd color
# CHECK: --
# CHECK: function fish_right_prompt
# CHECK: set -g __fish_git_prompt_showdirtystate 1
# CHECK: --
# CHECK: function fish_mode_prompt {{.*}}
# CHECK: # {{.*}}
2025-10-14 10:27:29 +02:00
fish_config prompt choose default
type fish_prompt fish_right_prompt fish_mode_prompt |
grep '^function' -A1
# CHECK: function fish_prompt --description 'Write out the prompt'
# CHECK: set -l last_pipestatus $pipestatus
# CHECKERR: type: Could not find 'fish_right_prompt'
# CHECK: --
# CHECK: function fish_mode_prompt {{.*}}
# CHECK: # {{.*}}
2025-10-14 10:27:29 +02:00
type fish_mode_prompt
# CHECK: fish_mode_prompt is a function with definition
# CHECK: # Defined {{in .*/functions/fish_mode_prompt.fish @ line 2|via `source`}}
# CHECK: function fish_mode_prompt --description 'Displays the current mode'
# CHECK: # {{.*}}
# CHECK: fish_default_mode_prompt
# CHECK: end
fish_config theme choose non-existent-theme1
Use globals for color variables, react to light/dark mode Implicitly-universal variables have some downsides: - It's surprising that "set fish_color_normal ..." and "set fish_key_bindings fish_vi_key_bindings" propagate to other shells and persist, especially since all other variables (and other shells) would use the global scope. - they don't play well with tracking configuration in Git. - we don't know how to roll out updates to the default theme (which is problematic since can look bad depending on terminal background color scheme). It's sort of possible to use only globals and unset universal variables (because fish only sets them at first startup), but that requires knowledge of fish internals; I don't think many people do that. So: - Set all color variables that are not already set as globals. - To enable this do the following, once, after upgrading: copy any existing universal color variables to globals, and: - if existing universal color variables exactly match the previous default theme, and pretend they didn't exist. - else migrate the universals to ~/.config/fish/conf.d/fish_frozen_theme.fish, which is a less surprising way of persisting this. - either way, delete all universals to do the right thing for most users. - Make sure that webconfig's "Set Theme" continues to: - instantly update all running shells - This is achieved by a new universal variable (but only for notifying shells, so this doesn't actually need to be persisted). In future, we could use any other IPC mechanism such as "kill -SIGUSR1" or if we go for a new feature, "varsave" or "set --broadcast", see https://github.com/fish-shell/fish-shell/issues/7317#issuecomment-701165897 https://github.com/fish-shell/fish-shell/pull/8455#discussion_r757837137. - persist the theme updates, completely overriding any previous theme. Use the same "fish_frozen_theme.fish" snippet as for migration (see above). It's not meant to be edited directly. If people want flexibility the should delete it. It could be a universal variable instead of a conf snippet file; but I figured that the separate file looks nicer (we can have better comments etc.) - Ask the terminal whether it's using dark or light mode, and use an optimized default. Add dark/light variants to themes, and the "unknown" variant for the default theme. Other themes don't need the "unknown" variant; webconfig already has a background color in context, and CLI can require the user to specify variant explicitly if terminal doesn't advertise colors. - Every variable that is set as part of fish's default behavior gets a "--label=default" tacked onto it. This is to allow our fish_terminal_color_theme event handler to know which variables it is allowed to update. It's also necessary until we revert 7e3fac561d6 (Query terminal only just before reading from it, 2025-09-25) because since commit, we need to wait until the first reader_push() to get query results. By this time, the user's config.fish may already have set variables. If the user sets variables via either webconfig, "fish_config theme {choose,save}", or directly via "set fish_color_...", they'd almost always remove this label. - For consistency, make default fish_key_bindings global (note that, for better or worse, fish_add_path still remains as one place that implicitly sets universal variables, but it's not something we inject by default) - Have "fish_config theme choose" and webconfig equivalents reset all color variables. This makes much more sense than keeping a hardcoded subset of "known colors"; and now that we don't really expect to be deleting universals this way, it's actually possible to make this change without much fear. Should have split this into two commits (the changelog entries are intertwined though). Closes #11580 Closes #11435 Closes #7317 Ref: https://github.com/fish-shell/fish-shell/issues/12096#issuecomment-3632065704
2025-11-25 12:52:39 +01:00
__fish_apply_theme
# CHECKERR: No such theme: non-existent-theme1
# CHECKERR: Searched {{/\S* (/\S*|and `status list-files themes`)}}
# This still demos the current theme.
fish_config theme show non-existent-theme2
# CHECK: {{\x1b\[m}}{{\x1b\[4m}}Current{{\x1b\[m}}
# CHECK: /bright/vixens{{\x1b\[m}} jump{{\x1b\[m}} |{{\x1b\[m}} "fowl"{{\x1b\[m}} > quack{{\x1b\[m}} &{{\x1b\[m}} # This is a comment
# CHECK: {{\x1b\[m}}echo{{\x1b\[m}} 'Errors are the portal to discovery
# CHECK: {{\x1b\[m}}Th{{\x1b\[m}}is an autosuggestion
2025-10-13 15:51:16 +02:00
diff \
(fish_config theme list | psub -s config-theme-list) \
(fish_config theme | psub -s config-theme)
fish_config theme list | string match -r \
Use globals for color variables, react to light/dark mode Implicitly-universal variables have some downsides: - It's surprising that "set fish_color_normal ..." and "set fish_key_bindings fish_vi_key_bindings" propagate to other shells and persist, especially since all other variables (and other shells) would use the global scope. - they don't play well with tracking configuration in Git. - we don't know how to roll out updates to the default theme (which is problematic since can look bad depending on terminal background color scheme). It's sort of possible to use only globals and unset universal variables (because fish only sets them at first startup), but that requires knowledge of fish internals; I don't think many people do that. So: - Set all color variables that are not already set as globals. - To enable this do the following, once, after upgrading: copy any existing universal color variables to globals, and: - if existing universal color variables exactly match the previous default theme, and pretend they didn't exist. - else migrate the universals to ~/.config/fish/conf.d/fish_frozen_theme.fish, which is a less surprising way of persisting this. - either way, delete all universals to do the right thing for most users. - Make sure that webconfig's "Set Theme" continues to: - instantly update all running shells - This is achieved by a new universal variable (but only for notifying shells, so this doesn't actually need to be persisted). In future, we could use any other IPC mechanism such as "kill -SIGUSR1" or if we go for a new feature, "varsave" or "set --broadcast", see https://github.com/fish-shell/fish-shell/issues/7317#issuecomment-701165897 https://github.com/fish-shell/fish-shell/pull/8455#discussion_r757837137. - persist the theme updates, completely overriding any previous theme. Use the same "fish_frozen_theme.fish" snippet as for migration (see above). It's not meant to be edited directly. If people want flexibility the should delete it. It could be a universal variable instead of a conf snippet file; but I figured that the separate file looks nicer (we can have better comments etc.) - Ask the terminal whether it's using dark or light mode, and use an optimized default. Add dark/light variants to themes, and the "unknown" variant for the default theme. Other themes don't need the "unknown" variant; webconfig already has a background color in context, and CLI can require the user to specify variant explicitly if terminal doesn't advertise colors. - Every variable that is set as part of fish's default behavior gets a "--label=default" tacked onto it. This is to allow our fish_terminal_color_theme event handler to know which variables it is allowed to update. It's also necessary until we revert 7e3fac561d6 (Query terminal only just before reading from it, 2025-09-25) because since commit, we need to wait until the first reader_push() to get query results. By this time, the user's config.fish may already have set variables. If the user sets variables via either webconfig, "fish_config theme {choose,save}", or directly via "set fish_color_...", they'd almost always remove this label. - For consistency, make default fish_key_bindings global (note that, for better or worse, fish_add_path still remains as one place that implicitly sets universal variables, but it's not something we inject by default) - Have "fish_config theme choose" and webconfig equivalents reset all color variables. This makes much more sense than keeping a hardcoded subset of "known colors"; and now that we don't really expect to be deleting universals this way, it's actually possible to make this change without much fear. Should have split this into two commits (the changelog entries are intertwined though). Closes #11580 Closes #11435 Closes #7317 Ref: https://github.com/fish-shell/fish-shell/issues/12096#issuecomment-3632065704
2025-11-25 12:52:39 +01:00
'^(?:ayu|base16-default|coolbeans|default|none|'\
'tomorrow-night-bright|tomorrow)$'
# CHECK: ayu
# CHECK: base16-default
2025-10-13 15:51:16 +02:00
# CHECK: coolbeans
# CHECK: default
# CHECK: none
# CHECK: tomorrow-night-bright
# CHECK: tomorrow
2025-10-13 15:51:16 +02:00
Use globals for color variables, react to light/dark mode Implicitly-universal variables have some downsides: - It's surprising that "set fish_color_normal ..." and "set fish_key_bindings fish_vi_key_bindings" propagate to other shells and persist, especially since all other variables (and other shells) would use the global scope. - they don't play well with tracking configuration in Git. - we don't know how to roll out updates to the default theme (which is problematic since can look bad depending on terminal background color scheme). It's sort of possible to use only globals and unset universal variables (because fish only sets them at first startup), but that requires knowledge of fish internals; I don't think many people do that. So: - Set all color variables that are not already set as globals. - To enable this do the following, once, after upgrading: copy any existing universal color variables to globals, and: - if existing universal color variables exactly match the previous default theme, and pretend they didn't exist. - else migrate the universals to ~/.config/fish/conf.d/fish_frozen_theme.fish, which is a less surprising way of persisting this. - either way, delete all universals to do the right thing for most users. - Make sure that webconfig's "Set Theme" continues to: - instantly update all running shells - This is achieved by a new universal variable (but only for notifying shells, so this doesn't actually need to be persisted). In future, we could use any other IPC mechanism such as "kill -SIGUSR1" or if we go for a new feature, "varsave" or "set --broadcast", see https://github.com/fish-shell/fish-shell/issues/7317#issuecomment-701165897 https://github.com/fish-shell/fish-shell/pull/8455#discussion_r757837137. - persist the theme updates, completely overriding any previous theme. Use the same "fish_frozen_theme.fish" snippet as for migration (see above). It's not meant to be edited directly. If people want flexibility the should delete it. It could be a universal variable instead of a conf snippet file; but I figured that the separate file looks nicer (we can have better comments etc.) - Ask the terminal whether it's using dark or light mode, and use an optimized default. Add dark/light variants to themes, and the "unknown" variant for the default theme. Other themes don't need the "unknown" variant; webconfig already has a background color in context, and CLI can require the user to specify variant explicitly if terminal doesn't advertise colors. - Every variable that is set as part of fish's default behavior gets a "--label=default" tacked onto it. This is to allow our fish_terminal_color_theme event handler to know which variables it is allowed to update. It's also necessary until we revert 7e3fac561d6 (Query terminal only just before reading from it, 2025-09-25) because since commit, we need to wait until the first reader_push() to get query results. By this time, the user's config.fish may already have set variables. If the user sets variables via either webconfig, "fish_config theme {choose,save}", or directly via "set fish_color_...", they'd almost always remove this label. - For consistency, make default fish_key_bindings global (note that, for better or worse, fish_add_path still remains as one place that implicitly sets universal variables, but it's not something we inject by default) - Have "fish_config theme choose" and webconfig equivalents reset all color variables. This makes much more sense than keeping a hardcoded subset of "known colors"; and now that we don't really expect to be deleting universals this way, it's actually possible to make this change without much fear. Should have split this into two commits (the changelog entries are intertwined though). Closes #11580 Closes #11435 Closes #7317 Ref: https://github.com/fish-shell/fish-shell/issues/12096#issuecomment-3632065704
2025-11-25 12:52:39 +01:00
fish_config theme show default
# CHECK: {{\x1b\[m}}{{\x1b\[4m}}Current{{\x1b\[m}}
# CHECK: /bright/vixens{{\x1b\[m}} jump{{\x1b\[m}} |{{\x1b\[m}} "fowl"{{\x1b\[m}} > quack{{\x1b\[m}} &{{\x1b\[m}} # This is a comment
# CHECK: {{\x1b\[m}}echo{{\x1b\[m}} 'Errors are the portal to discovery
# CHECK: {{\x1b\[m}}Th{{\x1b\[m}}is an autosuggestion
Use globals for color variables, react to light/dark mode Implicitly-universal variables have some downsides: - It's surprising that "set fish_color_normal ..." and "set fish_key_bindings fish_vi_key_bindings" propagate to other shells and persist, especially since all other variables (and other shells) would use the global scope. - they don't play well with tracking configuration in Git. - we don't know how to roll out updates to the default theme (which is problematic since can look bad depending on terminal background color scheme). It's sort of possible to use only globals and unset universal variables (because fish only sets them at first startup), but that requires knowledge of fish internals; I don't think many people do that. So: - Set all color variables that are not already set as globals. - To enable this do the following, once, after upgrading: copy any existing universal color variables to globals, and: - if existing universal color variables exactly match the previous default theme, and pretend they didn't exist. - else migrate the universals to ~/.config/fish/conf.d/fish_frozen_theme.fish, which is a less surprising way of persisting this. - either way, delete all universals to do the right thing for most users. - Make sure that webconfig's "Set Theme" continues to: - instantly update all running shells - This is achieved by a new universal variable (but only for notifying shells, so this doesn't actually need to be persisted). In future, we could use any other IPC mechanism such as "kill -SIGUSR1" or if we go for a new feature, "varsave" or "set --broadcast", see https://github.com/fish-shell/fish-shell/issues/7317#issuecomment-701165897 https://github.com/fish-shell/fish-shell/pull/8455#discussion_r757837137. - persist the theme updates, completely overriding any previous theme. Use the same "fish_frozen_theme.fish" snippet as for migration (see above). It's not meant to be edited directly. If people want flexibility the should delete it. It could be a universal variable instead of a conf snippet file; but I figured that the separate file looks nicer (we can have better comments etc.) - Ask the terminal whether it's using dark or light mode, and use an optimized default. Add dark/light variants to themes, and the "unknown" variant for the default theme. Other themes don't need the "unknown" variant; webconfig already has a background color in context, and CLI can require the user to specify variant explicitly if terminal doesn't advertise colors. - Every variable that is set as part of fish's default behavior gets a "--label=default" tacked onto it. This is to allow our fish_terminal_color_theme event handler to know which variables it is allowed to update. It's also necessary until we revert 7e3fac561d6 (Query terminal only just before reading from it, 2025-09-25) because since commit, we need to wait until the first reader_push() to get query results. By this time, the user's config.fish may already have set variables. If the user sets variables via either webconfig, "fish_config theme {choose,save}", or directly via "set fish_color_...", they'd almost always remove this label. - For consistency, make default fish_key_bindings global (note that, for better or worse, fish_add_path still remains as one place that implicitly sets universal variables, but it's not something we inject by default) - Have "fish_config theme choose" and webconfig equivalents reset all color variables. This makes much more sense than keeping a hardcoded subset of "known colors"; and now that we don't really expect to be deleting universals this way, it's actually possible to make this change without much fear. Should have split this into two commits (the changelog entries are intertwined though). Closes #11580 Closes #11435 Closes #7317 Ref: https://github.com/fish-shell/fish-shell/issues/12096#issuecomment-3632065704
2025-11-25 12:52:39 +01:00
# CHECK: {{\x1b\[m\x1b\[4mdefault \(light color theme\)\x1b\[m}}
# CHECK: {{\x1b\[38;2;0;0;238m/bright/vixens\x1b\[m \x1b\[38;2;0;160;160mjump\x1b.*}}
# CHECK: {{.*}}
# CHECK: {{.*}}
# CHECK: {{\x1b\[m\x1b\[4mdefault \(dark color theme\)\x1b\[m}}
# CHECK: {{\x1b\[38;2;92;92;255m.*}}
# CHECK: {{.*}}
# CHECK: {{.*}}
# CHECK: {{\x1b\[m\x1b\[4mdefault \(unknown color theme\)\x1b\[m}}
# CHECK: {{\x1b\[m/bright/vixens\x1b\[m \x1b\[36mjump\x1b\[m.*}}
# CHECK: {{.*}}
# CHECK: {{.*}}
fish_config theme show ayu | string match -r '^.*ayu.*'
# CHECK: {{\x1b\[m}}{{\x1b\[4m}}ayu (light color theme){{\x1b\[m}}
# CHECK: {{\x1b\[m}}{{\x1b\[4m}}ayu (dark color theme){{\x1b\[m}}
mkdir $__fish_config_dir/themes
touch $__fish_config_dir/themes/custom-from-userconf.theme
Use globals for color variables, react to light/dark mode Implicitly-universal variables have some downsides: - It's surprising that "set fish_color_normal ..." and "set fish_key_bindings fish_vi_key_bindings" propagate to other shells and persist, especially since all other variables (and other shells) would use the global scope. - they don't play well with tracking configuration in Git. - we don't know how to roll out updates to the default theme (which is problematic since can look bad depending on terminal background color scheme). It's sort of possible to use only globals and unset universal variables (because fish only sets them at first startup), but that requires knowledge of fish internals; I don't think many people do that. So: - Set all color variables that are not already set as globals. - To enable this do the following, once, after upgrading: copy any existing universal color variables to globals, and: - if existing universal color variables exactly match the previous default theme, and pretend they didn't exist. - else migrate the universals to ~/.config/fish/conf.d/fish_frozen_theme.fish, which is a less surprising way of persisting this. - either way, delete all universals to do the right thing for most users. - Make sure that webconfig's "Set Theme" continues to: - instantly update all running shells - This is achieved by a new universal variable (but only for notifying shells, so this doesn't actually need to be persisted). In future, we could use any other IPC mechanism such as "kill -SIGUSR1" or if we go for a new feature, "varsave" or "set --broadcast", see https://github.com/fish-shell/fish-shell/issues/7317#issuecomment-701165897 https://github.com/fish-shell/fish-shell/pull/8455#discussion_r757837137. - persist the theme updates, completely overriding any previous theme. Use the same "fish_frozen_theme.fish" snippet as for migration (see above). It's not meant to be edited directly. If people want flexibility the should delete it. It could be a universal variable instead of a conf snippet file; but I figured that the separate file looks nicer (we can have better comments etc.) - Ask the terminal whether it's using dark or light mode, and use an optimized default. Add dark/light variants to themes, and the "unknown" variant for the default theme. Other themes don't need the "unknown" variant; webconfig already has a background color in context, and CLI can require the user to specify variant explicitly if terminal doesn't advertise colors. - Every variable that is set as part of fish's default behavior gets a "--label=default" tacked onto it. This is to allow our fish_terminal_color_theme event handler to know which variables it is allowed to update. It's also necessary until we revert 7e3fac561d6 (Query terminal only just before reading from it, 2025-09-25) because since commit, we need to wait until the first reader_push() to get query results. By this time, the user's config.fish may already have set variables. If the user sets variables via either webconfig, "fish_config theme {choose,save}", or directly via "set fish_color_...", they'd almost always remove this label. - For consistency, make default fish_key_bindings global (note that, for better or worse, fish_add_path still remains as one place that implicitly sets universal variables, but it's not something we inject by default) - Have "fish_config theme choose" and webconfig equivalents reset all color variables. This makes much more sense than keeping a hardcoded subset of "known colors"; and now that we don't really expect to be deleting universals this way, it's actually possible to make this change without much fear. Should have split this into two commits (the changelog entries are intertwined though). Closes #11580 Closes #11435 Closes #7317 Ref: https://github.com/fish-shell/fish-shell/issues/12096#issuecomment-3632065704
2025-11-25 12:52:39 +01:00
fish_config theme show | grep -E 'default|base16-default|custom-from-userconf'
# CHECK: {{.*}}default (light color theme){{\x1b\[m}}
# CHECK: {{.*}}default (dark color theme){{\x1b\[m}}
# CHECK: {{.*}}default (unknown color theme){{\x1b\[m}}
# CHECK: {{.*}}custom-from-userconf (unknown color theme){{\x1b\[m}}
# CHECK: {{.*}}base16-default (light color theme){{\x1b\[m}}
# CHECK: {{.*}}base16-default (dark color theme){{\x1b\[m}}
# Override the default theme with different colors.
__fish_data_with_file themes/none.theme \
cat >$__fish_config_dir/themes/default.theme
Use globals for color variables, react to light/dark mode Implicitly-universal variables have some downsides: - It's surprising that "set fish_color_normal ..." and "set fish_key_bindings fish_vi_key_bindings" propagate to other shells and persist, especially since all other variables (and other shells) would use the global scope. - they don't play well with tracking configuration in Git. - we don't know how to roll out updates to the default theme (which is problematic since can look bad depending on terminal background color scheme). It's sort of possible to use only globals and unset universal variables (because fish only sets them at first startup), but that requires knowledge of fish internals; I don't think many people do that. So: - Set all color variables that are not already set as globals. - To enable this do the following, once, after upgrading: copy any existing universal color variables to globals, and: - if existing universal color variables exactly match the previous default theme, and pretend they didn't exist. - else migrate the universals to ~/.config/fish/conf.d/fish_frozen_theme.fish, which is a less surprising way of persisting this. - either way, delete all universals to do the right thing for most users. - Make sure that webconfig's "Set Theme" continues to: - instantly update all running shells - This is achieved by a new universal variable (but only for notifying shells, so this doesn't actually need to be persisted). In future, we could use any other IPC mechanism such as "kill -SIGUSR1" or if we go for a new feature, "varsave" or "set --broadcast", see https://github.com/fish-shell/fish-shell/issues/7317#issuecomment-701165897 https://github.com/fish-shell/fish-shell/pull/8455#discussion_r757837137. - persist the theme updates, completely overriding any previous theme. Use the same "fish_frozen_theme.fish" snippet as for migration (see above). It's not meant to be edited directly. If people want flexibility the should delete it. It could be a universal variable instead of a conf snippet file; but I figured that the separate file looks nicer (we can have better comments etc.) - Ask the terminal whether it's using dark or light mode, and use an optimized default. Add dark/light variants to themes, and the "unknown" variant for the default theme. Other themes don't need the "unknown" variant; webconfig already has a background color in context, and CLI can require the user to specify variant explicitly if terminal doesn't advertise colors. - Every variable that is set as part of fish's default behavior gets a "--label=default" tacked onto it. This is to allow our fish_terminal_color_theme event handler to know which variables it is allowed to update. It's also necessary until we revert 7e3fac561d6 (Query terminal only just before reading from it, 2025-09-25) because since commit, we need to wait until the first reader_push() to get query results. By this time, the user's config.fish may already have set variables. If the user sets variables via either webconfig, "fish_config theme {choose,save}", or directly via "set fish_color_...", they'd almost always remove this label. - For consistency, make default fish_key_bindings global (note that, for better or worse, fish_add_path still remains as one place that implicitly sets universal variables, but it's not something we inject by default) - Have "fish_config theme choose" and webconfig equivalents reset all color variables. This makes much more sense than keeping a hardcoded subset of "known colors"; and now that we don't really expect to be deleting universals this way, it's actually possible to make this change without much fear. Should have split this into two commits (the changelog entries are intertwined though). Closes #11580 Closes #11435 Closes #7317 Ref: https://github.com/fish-shell/fish-shell/issues/12096#issuecomment-3632065704
2025-11-25 12:52:39 +01:00
fish_config theme show default ayu | grep -E 'default|ayu.*dark' -A1
# CHECK: {{\x1b\[m}}{{\x1b\[4m}}default (unknown color theme){{\x1b\[m}}
# CHECK: /bright/vixens{{.*}}
# CHECK: --
Use globals for color variables, react to light/dark mode Implicitly-universal variables have some downsides: - It's surprising that "set fish_color_normal ..." and "set fish_key_bindings fish_vi_key_bindings" propagate to other shells and persist, especially since all other variables (and other shells) would use the global scope. - they don't play well with tracking configuration in Git. - we don't know how to roll out updates to the default theme (which is problematic since can look bad depending on terminal background color scheme). It's sort of possible to use only globals and unset universal variables (because fish only sets them at first startup), but that requires knowledge of fish internals; I don't think many people do that. So: - Set all color variables that are not already set as globals. - To enable this do the following, once, after upgrading: copy any existing universal color variables to globals, and: - if existing universal color variables exactly match the previous default theme, and pretend they didn't exist. - else migrate the universals to ~/.config/fish/conf.d/fish_frozen_theme.fish, which is a less surprising way of persisting this. - either way, delete all universals to do the right thing for most users. - Make sure that webconfig's "Set Theme" continues to: - instantly update all running shells - This is achieved by a new universal variable (but only for notifying shells, so this doesn't actually need to be persisted). In future, we could use any other IPC mechanism such as "kill -SIGUSR1" or if we go for a new feature, "varsave" or "set --broadcast", see https://github.com/fish-shell/fish-shell/issues/7317#issuecomment-701165897 https://github.com/fish-shell/fish-shell/pull/8455#discussion_r757837137. - persist the theme updates, completely overriding any previous theme. Use the same "fish_frozen_theme.fish" snippet as for migration (see above). It's not meant to be edited directly. If people want flexibility the should delete it. It could be a universal variable instead of a conf snippet file; but I figured that the separate file looks nicer (we can have better comments etc.) - Ask the terminal whether it's using dark or light mode, and use an optimized default. Add dark/light variants to themes, and the "unknown" variant for the default theme. Other themes don't need the "unknown" variant; webconfig already has a background color in context, and CLI can require the user to specify variant explicitly if terminal doesn't advertise colors. - Every variable that is set as part of fish's default behavior gets a "--label=default" tacked onto it. This is to allow our fish_terminal_color_theme event handler to know which variables it is allowed to update. It's also necessary until we revert 7e3fac561d6 (Query terminal only just before reading from it, 2025-09-25) because since commit, we need to wait until the first reader_push() to get query results. By this time, the user's config.fish may already have set variables. If the user sets variables via either webconfig, "fish_config theme {choose,save}", or directly via "set fish_color_...", they'd almost always remove this label. - For consistency, make default fish_key_bindings global (note that, for better or worse, fish_add_path still remains as one place that implicitly sets universal variables, but it's not something we inject by default) - Have "fish_config theme choose" and webconfig equivalents reset all color variables. This makes much more sense than keeping a hardcoded subset of "known colors"; and now that we don't really expect to be deleting universals this way, it's actually possible to make this change without much fear. Should have split this into two commits (the changelog entries are intertwined though). Closes #11580 Closes #11435 Closes #7317 Ref: https://github.com/fish-shell/fish-shell/issues/12096#issuecomment-3632065704
2025-11-25 12:52:39 +01:00
# CHECK: {{\x1b\[m}}{{\x1b\[4m}}ayu (dark color theme){{\x1b\[m}}
Default theme variants specialized for light/dark mode Start by converting the "default" theme's colors to RGB, using XTerm colors since they are simple, see https://en.wikipedia.org/wiki/ANSI_escape_code#3-bit_and_4-bit. Then make the following changes: for both default-light and default-dark: - Reinstate fish_color_command/fish_color_keyword as blue since one of the reasons in 81ff6db62db (default color scheme: Make commands "normal" color, 2024-10-02) doesn't hold anymore. - bravely replace "fish_pager_color_selected_background -r" with something that hopefully matches better. Note we can't trivially use the fallback to "fish_color_search_match", since for unknown reasons, "fish_pager_color_selected_background" is only for background and the others are for foreground. for default-light: - brgreen (00ff00) looks bad on light background, so replace it with green (00cd00). This means that we no longer use two different shades of green in the default theme (which helps address the "fruit salad" mentioned 81ff6db62db). - yellow (cdcd00) looks bad on light background, make it darker (a0a000) - fish_pager_color_progress's --background=cyan (00cdcd) seems a bit too bright, make it darker - same for other uses of cyan (also for consistency) - this means fish_color_operator / fish_color_escape can use 00cdcd I guess. for default-dark: - use bright green (00ff00) for all greens - use bright blue (5c5cff) instead of regular blue for command/keyword - make autosuggestions a bit lighter (9f9f9f instead of 7f7f7f) - etc.. I think I made the two themes mostly symmetrical. Part of #11580
2025-11-25 12:52:39 +01:00
# CHECK: {{.*}}/bright/vixens{{.*}}
2025-10-14 10:00:27 +02:00
function print-sample-colors
echo "normal=$fish_color_normal"
echo "autosuggestion=$fish_color_autosuggestion"
end
echo >$__fish_config_dir/themes/custom-from-userconf.theme \
"fish_color_normal yellow"
{
# Since we're noninteractive, we have not loaded a theme yet.
print-sample-colors
# CHECK: normal=
# CHECK: autosuggestion=
Use globals for color variables, react to light/dark mode Implicitly-universal variables have some downsides: - It's surprising that "set fish_color_normal ..." and "set fish_key_bindings fish_vi_key_bindings" propagate to other shells and persist, especially since all other variables (and other shells) would use the global scope. - they don't play well with tracking configuration in Git. - we don't know how to roll out updates to the default theme (which is problematic since can look bad depending on terminal background color scheme). It's sort of possible to use only globals and unset universal variables (because fish only sets them at first startup), but that requires knowledge of fish internals; I don't think many people do that. So: - Set all color variables that are not already set as globals. - To enable this do the following, once, after upgrading: copy any existing universal color variables to globals, and: - if existing universal color variables exactly match the previous default theme, and pretend they didn't exist. - else migrate the universals to ~/.config/fish/conf.d/fish_frozen_theme.fish, which is a less surprising way of persisting this. - either way, delete all universals to do the right thing for most users. - Make sure that webconfig's "Set Theme" continues to: - instantly update all running shells - This is achieved by a new universal variable (but only for notifying shells, so this doesn't actually need to be persisted). In future, we could use any other IPC mechanism such as "kill -SIGUSR1" or if we go for a new feature, "varsave" or "set --broadcast", see https://github.com/fish-shell/fish-shell/issues/7317#issuecomment-701165897 https://github.com/fish-shell/fish-shell/pull/8455#discussion_r757837137. - persist the theme updates, completely overriding any previous theme. Use the same "fish_frozen_theme.fish" snippet as for migration (see above). It's not meant to be edited directly. If people want flexibility the should delete it. It could be a universal variable instead of a conf snippet file; but I figured that the separate file looks nicer (we can have better comments etc.) - Ask the terminal whether it's using dark or light mode, and use an optimized default. Add dark/light variants to themes, and the "unknown" variant for the default theme. Other themes don't need the "unknown" variant; webconfig already has a background color in context, and CLI can require the user to specify variant explicitly if terminal doesn't advertise colors. - Every variable that is set as part of fish's default behavior gets a "--label=default" tacked onto it. This is to allow our fish_terminal_color_theme event handler to know which variables it is allowed to update. It's also necessary until we revert 7e3fac561d6 (Query terminal only just before reading from it, 2025-09-25) because since commit, we need to wait until the first reader_push() to get query results. By this time, the user's config.fish may already have set variables. If the user sets variables via either webconfig, "fish_config theme {choose,save}", or directly via "set fish_color_...", they'd almost always remove this label. - For consistency, make default fish_key_bindings global (note that, for better or worse, fish_add_path still remains as one place that implicitly sets universal variables, but it's not something we inject by default) - Have "fish_config theme choose" and webconfig equivalents reset all color variables. This makes much more sense than keeping a hardcoded subset of "known colors"; and now that we don't really expect to be deleting universals this way, it's actually possible to make this change without much fear. Should have split this into two commits (the changelog entries are intertwined though). Closes #11580 Closes #11435 Closes #7317 Ref: https://github.com/fish-shell/fish-shell/issues/12096#issuecomment-3632065704
2025-11-25 12:52:39 +01:00
fish_config theme choose custom-from-userconf --color-theme=unknown
2025-10-14 10:00:27 +02:00
print-sample-colors
Use globals for color variables, react to light/dark mode Implicitly-universal variables have some downsides: - It's surprising that "set fish_color_normal ..." and "set fish_key_bindings fish_vi_key_bindings" propagate to other shells and persist, especially since all other variables (and other shells) would use the global scope. - they don't play well with tracking configuration in Git. - we don't know how to roll out updates to the default theme (which is problematic since can look bad depending on terminal background color scheme). It's sort of possible to use only globals and unset universal variables (because fish only sets them at first startup), but that requires knowledge of fish internals; I don't think many people do that. So: - Set all color variables that are not already set as globals. - To enable this do the following, once, after upgrading: copy any existing universal color variables to globals, and: - if existing universal color variables exactly match the previous default theme, and pretend they didn't exist. - else migrate the universals to ~/.config/fish/conf.d/fish_frozen_theme.fish, which is a less surprising way of persisting this. - either way, delete all universals to do the right thing for most users. - Make sure that webconfig's "Set Theme" continues to: - instantly update all running shells - This is achieved by a new universal variable (but only for notifying shells, so this doesn't actually need to be persisted). In future, we could use any other IPC mechanism such as "kill -SIGUSR1" or if we go for a new feature, "varsave" or "set --broadcast", see https://github.com/fish-shell/fish-shell/issues/7317#issuecomment-701165897 https://github.com/fish-shell/fish-shell/pull/8455#discussion_r757837137. - persist the theme updates, completely overriding any previous theme. Use the same "fish_frozen_theme.fish" snippet as for migration (see above). It's not meant to be edited directly. If people want flexibility the should delete it. It could be a universal variable instead of a conf snippet file; but I figured that the separate file looks nicer (we can have better comments etc.) - Ask the terminal whether it's using dark or light mode, and use an optimized default. Add dark/light variants to themes, and the "unknown" variant for the default theme. Other themes don't need the "unknown" variant; webconfig already has a background color in context, and CLI can require the user to specify variant explicitly if terminal doesn't advertise colors. - Every variable that is set as part of fish's default behavior gets a "--label=default" tacked onto it. This is to allow our fish_terminal_color_theme event handler to know which variables it is allowed to update. It's also necessary until we revert 7e3fac561d6 (Query terminal only just before reading from it, 2025-09-25) because since commit, we need to wait until the first reader_push() to get query results. By this time, the user's config.fish may already have set variables. If the user sets variables via either webconfig, "fish_config theme {choose,save}", or directly via "set fish_color_...", they'd almost always remove this label. - For consistency, make default fish_key_bindings global (note that, for better or worse, fish_add_path still remains as one place that implicitly sets universal variables, but it's not something we inject by default) - Have "fish_config theme choose" and webconfig equivalents reset all color variables. This makes much more sense than keeping a hardcoded subset of "known colors"; and now that we don't really expect to be deleting universals this way, it's actually possible to make this change without much fear. Should have split this into two commits (the changelog entries are intertwined though). Closes #11580 Closes #11435 Closes #7317 Ref: https://github.com/fish-shell/fish-shell/issues/12096#issuecomment-3632065704
2025-11-25 12:52:39 +01:00
# CHECK: normal=yellow --theme=custom-from-userconf
2025-10-14 10:00:27 +02:00
# CHECK: autosuggestion=
set -S fish_color_normal
Use globals for color variables, react to light/dark mode Implicitly-universal variables have some downsides: - It's surprising that "set fish_color_normal ..." and "set fish_key_bindings fish_vi_key_bindings" propagate to other shells and persist, especially since all other variables (and other shells) would use the global scope. - they don't play well with tracking configuration in Git. - we don't know how to roll out updates to the default theme (which is problematic since can look bad depending on terminal background color scheme). It's sort of possible to use only globals and unset universal variables (because fish only sets them at first startup), but that requires knowledge of fish internals; I don't think many people do that. So: - Set all color variables that are not already set as globals. - To enable this do the following, once, after upgrading: copy any existing universal color variables to globals, and: - if existing universal color variables exactly match the previous default theme, and pretend they didn't exist. - else migrate the universals to ~/.config/fish/conf.d/fish_frozen_theme.fish, which is a less surprising way of persisting this. - either way, delete all universals to do the right thing for most users. - Make sure that webconfig's "Set Theme" continues to: - instantly update all running shells - This is achieved by a new universal variable (but only for notifying shells, so this doesn't actually need to be persisted). In future, we could use any other IPC mechanism such as "kill -SIGUSR1" or if we go for a new feature, "varsave" or "set --broadcast", see https://github.com/fish-shell/fish-shell/issues/7317#issuecomment-701165897 https://github.com/fish-shell/fish-shell/pull/8455#discussion_r757837137. - persist the theme updates, completely overriding any previous theme. Use the same "fish_frozen_theme.fish" snippet as for migration (see above). It's not meant to be edited directly. If people want flexibility the should delete it. It could be a universal variable instead of a conf snippet file; but I figured that the separate file looks nicer (we can have better comments etc.) - Ask the terminal whether it's using dark or light mode, and use an optimized default. Add dark/light variants to themes, and the "unknown" variant for the default theme. Other themes don't need the "unknown" variant; webconfig already has a background color in context, and CLI can require the user to specify variant explicitly if terminal doesn't advertise colors. - Every variable that is set as part of fish's default behavior gets a "--label=default" tacked onto it. This is to allow our fish_terminal_color_theme event handler to know which variables it is allowed to update. It's also necessary until we revert 7e3fac561d6 (Query terminal only just before reading from it, 2025-09-25) because since commit, we need to wait until the first reader_push() to get query results. By this time, the user's config.fish may already have set variables. If the user sets variables via either webconfig, "fish_config theme {choose,save}", or directly via "set fish_color_...", they'd almost always remove this label. - For consistency, make default fish_key_bindings global (note that, for better or worse, fish_add_path still remains as one place that implicitly sets universal variables, but it's not something we inject by default) - Have "fish_config theme choose" and webconfig equivalents reset all color variables. This makes much more sense than keeping a hardcoded subset of "known colors"; and now that we don't really expect to be deleting universals this way, it's actually possible to make this change without much fear. Should have split this into two commits (the changelog entries are intertwined though). Closes #11580 Closes #11435 Closes #7317 Ref: https://github.com/fish-shell/fish-shell/issues/12096#issuecomment-3632065704
2025-11-25 12:52:39 +01:00
# CHECK: $fish_color_normal: set in global scope, unexported, with 2 elements
2025-10-14 10:00:27 +02:00
# CHECK: $fish_color_normal[1]: |yellow|
Use globals for color variables, react to light/dark mode Implicitly-universal variables have some downsides: - It's surprising that "set fish_color_normal ..." and "set fish_key_bindings fish_vi_key_bindings" propagate to other shells and persist, especially since all other variables (and other shells) would use the global scope. - they don't play well with tracking configuration in Git. - we don't know how to roll out updates to the default theme (which is problematic since can look bad depending on terminal background color scheme). It's sort of possible to use only globals and unset universal variables (because fish only sets them at first startup), but that requires knowledge of fish internals; I don't think many people do that. So: - Set all color variables that are not already set as globals. - To enable this do the following, once, after upgrading: copy any existing universal color variables to globals, and: - if existing universal color variables exactly match the previous default theme, and pretend they didn't exist. - else migrate the universals to ~/.config/fish/conf.d/fish_frozen_theme.fish, which is a less surprising way of persisting this. - either way, delete all universals to do the right thing for most users. - Make sure that webconfig's "Set Theme" continues to: - instantly update all running shells - This is achieved by a new universal variable (but only for notifying shells, so this doesn't actually need to be persisted). In future, we could use any other IPC mechanism such as "kill -SIGUSR1" or if we go for a new feature, "varsave" or "set --broadcast", see https://github.com/fish-shell/fish-shell/issues/7317#issuecomment-701165897 https://github.com/fish-shell/fish-shell/pull/8455#discussion_r757837137. - persist the theme updates, completely overriding any previous theme. Use the same "fish_frozen_theme.fish" snippet as for migration (see above). It's not meant to be edited directly. If people want flexibility the should delete it. It could be a universal variable instead of a conf snippet file; but I figured that the separate file looks nicer (we can have better comments etc.) - Ask the terminal whether it's using dark or light mode, and use an optimized default. Add dark/light variants to themes, and the "unknown" variant for the default theme. Other themes don't need the "unknown" variant; webconfig already has a background color in context, and CLI can require the user to specify variant explicitly if terminal doesn't advertise colors. - Every variable that is set as part of fish's default behavior gets a "--label=default" tacked onto it. This is to allow our fish_terminal_color_theme event handler to know which variables it is allowed to update. It's also necessary until we revert 7e3fac561d6 (Query terminal only just before reading from it, 2025-09-25) because since commit, we need to wait until the first reader_push() to get query results. By this time, the user's config.fish may already have set variables. If the user sets variables via either webconfig, "fish_config theme {choose,save}", or directly via "set fish_color_...", they'd almost always remove this label. - For consistency, make default fish_key_bindings global (note that, for better or worse, fish_add_path still remains as one place that implicitly sets universal variables, but it's not something we inject by default) - Have "fish_config theme choose" and webconfig equivalents reset all color variables. This makes much more sense than keeping a hardcoded subset of "known colors"; and now that we don't really expect to be deleting universals this way, it's actually possible to make this change without much fear. Should have split this into two commits (the changelog entries are intertwined though). Closes #11580 Closes #11435 Closes #7317 Ref: https://github.com/fish-shell/fish-shell/issues/12096#issuecomment-3632065704
2025-11-25 12:52:39 +01:00
# CHECK: $fish_color_normal[2]: |--theme=custom-from-userconf|
2025-10-14 10:00:27 +02:00
echo yes | fish_config theme save
set -S fish_color_normal
Use globals for color variables, react to light/dark mode Implicitly-universal variables have some downsides: - It's surprising that "set fish_color_normal ..." and "set fish_key_bindings fish_vi_key_bindings" propagate to other shells and persist, especially since all other variables (and other shells) would use the global scope. - they don't play well with tracking configuration in Git. - we don't know how to roll out updates to the default theme (which is problematic since can look bad depending on terminal background color scheme). It's sort of possible to use only globals and unset universal variables (because fish only sets them at first startup), but that requires knowledge of fish internals; I don't think many people do that. So: - Set all color variables that are not already set as globals. - To enable this do the following, once, after upgrading: copy any existing universal color variables to globals, and: - if existing universal color variables exactly match the previous default theme, and pretend they didn't exist. - else migrate the universals to ~/.config/fish/conf.d/fish_frozen_theme.fish, which is a less surprising way of persisting this. - either way, delete all universals to do the right thing for most users. - Make sure that webconfig's "Set Theme" continues to: - instantly update all running shells - This is achieved by a new universal variable (but only for notifying shells, so this doesn't actually need to be persisted). In future, we could use any other IPC mechanism such as "kill -SIGUSR1" or if we go for a new feature, "varsave" or "set --broadcast", see https://github.com/fish-shell/fish-shell/issues/7317#issuecomment-701165897 https://github.com/fish-shell/fish-shell/pull/8455#discussion_r757837137. - persist the theme updates, completely overriding any previous theme. Use the same "fish_frozen_theme.fish" snippet as for migration (see above). It's not meant to be edited directly. If people want flexibility the should delete it. It could be a universal variable instead of a conf snippet file; but I figured that the separate file looks nicer (we can have better comments etc.) - Ask the terminal whether it's using dark or light mode, and use an optimized default. Add dark/light variants to themes, and the "unknown" variant for the default theme. Other themes don't need the "unknown" variant; webconfig already has a background color in context, and CLI can require the user to specify variant explicitly if terminal doesn't advertise colors. - Every variable that is set as part of fish's default behavior gets a "--label=default" tacked onto it. This is to allow our fish_terminal_color_theme event handler to know which variables it is allowed to update. It's also necessary until we revert 7e3fac561d6 (Query terminal only just before reading from it, 2025-09-25) because since commit, we need to wait until the first reader_push() to get query results. By this time, the user's config.fish may already have set variables. If the user sets variables via either webconfig, "fish_config theme {choose,save}", or directly via "set fish_color_...", they'd almost always remove this label. - For consistency, make default fish_key_bindings global (note that, for better or worse, fish_add_path still remains as one place that implicitly sets universal variables, but it's not something we inject by default) - Have "fish_config theme choose" and webconfig equivalents reset all color variables. This makes much more sense than keeping a hardcoded subset of "known colors"; and now that we don't really expect to be deleting universals this way, it's actually possible to make this change without much fear. Should have split this into two commits (the changelog entries are intertwined though). Closes #11580 Closes #11435 Closes #7317 Ref: https://github.com/fish-shell/fish-shell/issues/12096#issuecomment-3632065704
2025-11-25 12:52:39 +01:00
# CHECK: $fish_color_normal: set in universal scope, unexported, with 2 elements
2025-10-14 10:00:27 +02:00
# CHECK: $fish_color_normal[1]: |yellow|
Use globals for color variables, react to light/dark mode Implicitly-universal variables have some downsides: - It's surprising that "set fish_color_normal ..." and "set fish_key_bindings fish_vi_key_bindings" propagate to other shells and persist, especially since all other variables (and other shells) would use the global scope. - they don't play well with tracking configuration in Git. - we don't know how to roll out updates to the default theme (which is problematic since can look bad depending on terminal background color scheme). It's sort of possible to use only globals and unset universal variables (because fish only sets them at first startup), but that requires knowledge of fish internals; I don't think many people do that. So: - Set all color variables that are not already set as globals. - To enable this do the following, once, after upgrading: copy any existing universal color variables to globals, and: - if existing universal color variables exactly match the previous default theme, and pretend they didn't exist. - else migrate the universals to ~/.config/fish/conf.d/fish_frozen_theme.fish, which is a less surprising way of persisting this. - either way, delete all universals to do the right thing for most users. - Make sure that webconfig's "Set Theme" continues to: - instantly update all running shells - This is achieved by a new universal variable (but only for notifying shells, so this doesn't actually need to be persisted). In future, we could use any other IPC mechanism such as "kill -SIGUSR1" or if we go for a new feature, "varsave" or "set --broadcast", see https://github.com/fish-shell/fish-shell/issues/7317#issuecomment-701165897 https://github.com/fish-shell/fish-shell/pull/8455#discussion_r757837137. - persist the theme updates, completely overriding any previous theme. Use the same "fish_frozen_theme.fish" snippet as for migration (see above). It's not meant to be edited directly. If people want flexibility the should delete it. It could be a universal variable instead of a conf snippet file; but I figured that the separate file looks nicer (we can have better comments etc.) - Ask the terminal whether it's using dark or light mode, and use an optimized default. Add dark/light variants to themes, and the "unknown" variant for the default theme. Other themes don't need the "unknown" variant; webconfig already has a background color in context, and CLI can require the user to specify variant explicitly if terminal doesn't advertise colors. - Every variable that is set as part of fish's default behavior gets a "--label=default" tacked onto it. This is to allow our fish_terminal_color_theme event handler to know which variables it is allowed to update. It's also necessary until we revert 7e3fac561d6 (Query terminal only just before reading from it, 2025-09-25) because since commit, we need to wait until the first reader_push() to get query results. By this time, the user's config.fish may already have set variables. If the user sets variables via either webconfig, "fish_config theme {choose,save}", or directly via "set fish_color_...", they'd almost always remove this label. - For consistency, make default fish_key_bindings global (note that, for better or worse, fish_add_path still remains as one place that implicitly sets universal variables, but it's not something we inject by default) - Have "fish_config theme choose" and webconfig equivalents reset all color variables. This makes much more sense than keeping a hardcoded subset of "known colors"; and now that we don't really expect to be deleting universals this way, it's actually possible to make this change without much fear. Should have split this into two commits (the changelog entries are intertwined though). Closes #11580 Closes #11435 Closes #7317 Ref: https://github.com/fish-shell/fish-shell/issues/12096#issuecomment-3632065704
2025-11-25 12:52:39 +01:00
# CHECK: $fish_color_normal[2]: |--theme=custom-from-userconf|
2025-10-14 10:00:27 +02:00
Use globals for color variables, react to light/dark mode Implicitly-universal variables have some downsides: - It's surprising that "set fish_color_normal ..." and "set fish_key_bindings fish_vi_key_bindings" propagate to other shells and persist, especially since all other variables (and other shells) would use the global scope. - they don't play well with tracking configuration in Git. - we don't know how to roll out updates to the default theme (which is problematic since can look bad depending on terminal background color scheme). It's sort of possible to use only globals and unset universal variables (because fish only sets them at first startup), but that requires knowledge of fish internals; I don't think many people do that. So: - Set all color variables that are not already set as globals. - To enable this do the following, once, after upgrading: copy any existing universal color variables to globals, and: - if existing universal color variables exactly match the previous default theme, and pretend they didn't exist. - else migrate the universals to ~/.config/fish/conf.d/fish_frozen_theme.fish, which is a less surprising way of persisting this. - either way, delete all universals to do the right thing for most users. - Make sure that webconfig's "Set Theme" continues to: - instantly update all running shells - This is achieved by a new universal variable (but only for notifying shells, so this doesn't actually need to be persisted). In future, we could use any other IPC mechanism such as "kill -SIGUSR1" or if we go for a new feature, "varsave" or "set --broadcast", see https://github.com/fish-shell/fish-shell/issues/7317#issuecomment-701165897 https://github.com/fish-shell/fish-shell/pull/8455#discussion_r757837137. - persist the theme updates, completely overriding any previous theme. Use the same "fish_frozen_theme.fish" snippet as for migration (see above). It's not meant to be edited directly. If people want flexibility the should delete it. It could be a universal variable instead of a conf snippet file; but I figured that the separate file looks nicer (we can have better comments etc.) - Ask the terminal whether it's using dark or light mode, and use an optimized default. Add dark/light variants to themes, and the "unknown" variant for the default theme. Other themes don't need the "unknown" variant; webconfig already has a background color in context, and CLI can require the user to specify variant explicitly if terminal doesn't advertise colors. - Every variable that is set as part of fish's default behavior gets a "--label=default" tacked onto it. This is to allow our fish_terminal_color_theme event handler to know which variables it is allowed to update. It's also necessary until we revert 7e3fac561d6 (Query terminal only just before reading from it, 2025-09-25) because since commit, we need to wait until the first reader_push() to get query results. By this time, the user's config.fish may already have set variables. If the user sets variables via either webconfig, "fish_config theme {choose,save}", or directly via "set fish_color_...", they'd almost always remove this label. - For consistency, make default fish_key_bindings global (note that, for better or worse, fish_add_path still remains as one place that implicitly sets universal variables, but it's not something we inject by default) - Have "fish_config theme choose" and webconfig equivalents reset all color variables. This makes much more sense than keeping a hardcoded subset of "known colors"; and now that we don't really expect to be deleting universals this way, it's actually possible to make this change without much fear. Should have split this into two commits (the changelog entries are intertwined though). Closes #11580 Closes #11435 Closes #7317 Ref: https://github.com/fish-shell/fish-shell/issues/12096#issuecomment-3632065704
2025-11-25 12:52:39 +01:00
fish_config theme choose default --color-theme=unknown
2025-10-14 10:00:27 +02:00
print-sample-colors
Use globals for color variables, react to light/dark mode Implicitly-universal variables have some downsides: - It's surprising that "set fish_color_normal ..." and "set fish_key_bindings fish_vi_key_bindings" propagate to other shells and persist, especially since all other variables (and other shells) would use the global scope. - they don't play well with tracking configuration in Git. - we don't know how to roll out updates to the default theme (which is problematic since can look bad depending on terminal background color scheme). It's sort of possible to use only globals and unset universal variables (because fish only sets them at first startup), but that requires knowledge of fish internals; I don't think many people do that. So: - Set all color variables that are not already set as globals. - To enable this do the following, once, after upgrading: copy any existing universal color variables to globals, and: - if existing universal color variables exactly match the previous default theme, and pretend they didn't exist. - else migrate the universals to ~/.config/fish/conf.d/fish_frozen_theme.fish, which is a less surprising way of persisting this. - either way, delete all universals to do the right thing for most users. - Make sure that webconfig's "Set Theme" continues to: - instantly update all running shells - This is achieved by a new universal variable (but only for notifying shells, so this doesn't actually need to be persisted). In future, we could use any other IPC mechanism such as "kill -SIGUSR1" or if we go for a new feature, "varsave" or "set --broadcast", see https://github.com/fish-shell/fish-shell/issues/7317#issuecomment-701165897 https://github.com/fish-shell/fish-shell/pull/8455#discussion_r757837137. - persist the theme updates, completely overriding any previous theme. Use the same "fish_frozen_theme.fish" snippet as for migration (see above). It's not meant to be edited directly. If people want flexibility the should delete it. It could be a universal variable instead of a conf snippet file; but I figured that the separate file looks nicer (we can have better comments etc.) - Ask the terminal whether it's using dark or light mode, and use an optimized default. Add dark/light variants to themes, and the "unknown" variant for the default theme. Other themes don't need the "unknown" variant; webconfig already has a background color in context, and CLI can require the user to specify variant explicitly if terminal doesn't advertise colors. - Every variable that is set as part of fish's default behavior gets a "--label=default" tacked onto it. This is to allow our fish_terminal_color_theme event handler to know which variables it is allowed to update. It's also necessary until we revert 7e3fac561d6 (Query terminal only just before reading from it, 2025-09-25) because since commit, we need to wait until the first reader_push() to get query results. By this time, the user's config.fish may already have set variables. If the user sets variables via either webconfig, "fish_config theme {choose,save}", or directly via "set fish_color_...", they'd almost always remove this label. - For consistency, make default fish_key_bindings global (note that, for better or worse, fish_add_path still remains as one place that implicitly sets universal variables, but it's not something we inject by default) - Have "fish_config theme choose" and webconfig equivalents reset all color variables. This makes much more sense than keeping a hardcoded subset of "known colors"; and now that we don't really expect to be deleting universals this way, it's actually possible to make this change without much fear. Should have split this into two commits (the changelog entries are intertwined though). Closes #11580 Closes #11435 Closes #7317 Ref: https://github.com/fish-shell/fish-shell/issues/12096#issuecomment-3632065704
2025-11-25 12:52:39 +01:00
# CHECK: normal=normal --theme=default
# CHECK: autosuggestion=brblack --theme=default
2025-10-14 10:00:27 +02:00
set -S fish_color_normal
Use globals for color variables, react to light/dark mode Implicitly-universal variables have some downsides: - It's surprising that "set fish_color_normal ..." and "set fish_key_bindings fish_vi_key_bindings" propagate to other shells and persist, especially since all other variables (and other shells) would use the global scope. - they don't play well with tracking configuration in Git. - we don't know how to roll out updates to the default theme (which is problematic since can look bad depending on terminal background color scheme). It's sort of possible to use only globals and unset universal variables (because fish only sets them at first startup), but that requires knowledge of fish internals; I don't think many people do that. So: - Set all color variables that are not already set as globals. - To enable this do the following, once, after upgrading: copy any existing universal color variables to globals, and: - if existing universal color variables exactly match the previous default theme, and pretend they didn't exist. - else migrate the universals to ~/.config/fish/conf.d/fish_frozen_theme.fish, which is a less surprising way of persisting this. - either way, delete all universals to do the right thing for most users. - Make sure that webconfig's "Set Theme" continues to: - instantly update all running shells - This is achieved by a new universal variable (but only for notifying shells, so this doesn't actually need to be persisted). In future, we could use any other IPC mechanism such as "kill -SIGUSR1" or if we go for a new feature, "varsave" or "set --broadcast", see https://github.com/fish-shell/fish-shell/issues/7317#issuecomment-701165897 https://github.com/fish-shell/fish-shell/pull/8455#discussion_r757837137. - persist the theme updates, completely overriding any previous theme. Use the same "fish_frozen_theme.fish" snippet as for migration (see above). It's not meant to be edited directly. If people want flexibility the should delete it. It could be a universal variable instead of a conf snippet file; but I figured that the separate file looks nicer (we can have better comments etc.) - Ask the terminal whether it's using dark or light mode, and use an optimized default. Add dark/light variants to themes, and the "unknown" variant for the default theme. Other themes don't need the "unknown" variant; webconfig already has a background color in context, and CLI can require the user to specify variant explicitly if terminal doesn't advertise colors. - Every variable that is set as part of fish's default behavior gets a "--label=default" tacked onto it. This is to allow our fish_terminal_color_theme event handler to know which variables it is allowed to update. It's also necessary until we revert 7e3fac561d6 (Query terminal only just before reading from it, 2025-09-25) because since commit, we need to wait until the first reader_push() to get query results. By this time, the user's config.fish may already have set variables. If the user sets variables via either webconfig, "fish_config theme {choose,save}", or directly via "set fish_color_...", they'd almost always remove this label. - For consistency, make default fish_key_bindings global (note that, for better or worse, fish_add_path still remains as one place that implicitly sets universal variables, but it's not something we inject by default) - Have "fish_config theme choose" and webconfig equivalents reset all color variables. This makes much more sense than keeping a hardcoded subset of "known colors"; and now that we don't really expect to be deleting universals this way, it's actually possible to make this change without much fear. Should have split this into two commits (the changelog entries are intertwined though). Closes #11580 Closes #11435 Closes #7317 Ref: https://github.com/fish-shell/fish-shell/issues/12096#issuecomment-3632065704
2025-11-25 12:52:39 +01:00
# CHECK: $fish_color_normal: set in global scope, unexported, with 2 elements
2025-10-14 10:00:27 +02:00
# CHECK: $fish_color_normal[1]: |normal|
Use globals for color variables, react to light/dark mode Implicitly-universal variables have some downsides: - It's surprising that "set fish_color_normal ..." and "set fish_key_bindings fish_vi_key_bindings" propagate to other shells and persist, especially since all other variables (and other shells) would use the global scope. - they don't play well with tracking configuration in Git. - we don't know how to roll out updates to the default theme (which is problematic since can look bad depending on terminal background color scheme). It's sort of possible to use only globals and unset universal variables (because fish only sets them at first startup), but that requires knowledge of fish internals; I don't think many people do that. So: - Set all color variables that are not already set as globals. - To enable this do the following, once, after upgrading: copy any existing universal color variables to globals, and: - if existing universal color variables exactly match the previous default theme, and pretend they didn't exist. - else migrate the universals to ~/.config/fish/conf.d/fish_frozen_theme.fish, which is a less surprising way of persisting this. - either way, delete all universals to do the right thing for most users. - Make sure that webconfig's "Set Theme" continues to: - instantly update all running shells - This is achieved by a new universal variable (but only for notifying shells, so this doesn't actually need to be persisted). In future, we could use any other IPC mechanism such as "kill -SIGUSR1" or if we go for a new feature, "varsave" or "set --broadcast", see https://github.com/fish-shell/fish-shell/issues/7317#issuecomment-701165897 https://github.com/fish-shell/fish-shell/pull/8455#discussion_r757837137. - persist the theme updates, completely overriding any previous theme. Use the same "fish_frozen_theme.fish" snippet as for migration (see above). It's not meant to be edited directly. If people want flexibility the should delete it. It could be a universal variable instead of a conf snippet file; but I figured that the separate file looks nicer (we can have better comments etc.) - Ask the terminal whether it's using dark or light mode, and use an optimized default. Add dark/light variants to themes, and the "unknown" variant for the default theme. Other themes don't need the "unknown" variant; webconfig already has a background color in context, and CLI can require the user to specify variant explicitly if terminal doesn't advertise colors. - Every variable that is set as part of fish's default behavior gets a "--label=default" tacked onto it. This is to allow our fish_terminal_color_theme event handler to know which variables it is allowed to update. It's also necessary until we revert 7e3fac561d6 (Query terminal only just before reading from it, 2025-09-25) because since commit, we need to wait until the first reader_push() to get query results. By this time, the user's config.fish may already have set variables. If the user sets variables via either webconfig, "fish_config theme {choose,save}", or directly via "set fish_color_...", they'd almost always remove this label. - For consistency, make default fish_key_bindings global (note that, for better or worse, fish_add_path still remains as one place that implicitly sets universal variables, but it's not something we inject by default) - Have "fish_config theme choose" and webconfig equivalents reset all color variables. This makes much more sense than keeping a hardcoded subset of "known colors"; and now that we don't really expect to be deleting universals this way, it's actually possible to make this change without much fear. Should have split this into two commits (the changelog entries are intertwined though). Closes #11580 Closes #11435 Closes #7317 Ref: https://github.com/fish-shell/fish-shell/issues/12096#issuecomment-3632065704
2025-11-25 12:52:39 +01:00
# CHECK: $fish_color_normal[2]: |--theme=default|
# CHECK: $fish_color_normal: set in universal scope, unexported, with 2 elements
2025-10-14 10:00:27 +02:00
# CHECK: $fish_color_normal[1]: |yellow|
Use globals for color variables, react to light/dark mode Implicitly-universal variables have some downsides: - It's surprising that "set fish_color_normal ..." and "set fish_key_bindings fish_vi_key_bindings" propagate to other shells and persist, especially since all other variables (and other shells) would use the global scope. - they don't play well with tracking configuration in Git. - we don't know how to roll out updates to the default theme (which is problematic since can look bad depending on terminal background color scheme). It's sort of possible to use only globals and unset universal variables (because fish only sets them at first startup), but that requires knowledge of fish internals; I don't think many people do that. So: - Set all color variables that are not already set as globals. - To enable this do the following, once, after upgrading: copy any existing universal color variables to globals, and: - if existing universal color variables exactly match the previous default theme, and pretend they didn't exist. - else migrate the universals to ~/.config/fish/conf.d/fish_frozen_theme.fish, which is a less surprising way of persisting this. - either way, delete all universals to do the right thing for most users. - Make sure that webconfig's "Set Theme" continues to: - instantly update all running shells - This is achieved by a new universal variable (but only for notifying shells, so this doesn't actually need to be persisted). In future, we could use any other IPC mechanism such as "kill -SIGUSR1" or if we go for a new feature, "varsave" or "set --broadcast", see https://github.com/fish-shell/fish-shell/issues/7317#issuecomment-701165897 https://github.com/fish-shell/fish-shell/pull/8455#discussion_r757837137. - persist the theme updates, completely overriding any previous theme. Use the same "fish_frozen_theme.fish" snippet as for migration (see above). It's not meant to be edited directly. If people want flexibility the should delete it. It could be a universal variable instead of a conf snippet file; but I figured that the separate file looks nicer (we can have better comments etc.) - Ask the terminal whether it's using dark or light mode, and use an optimized default. Add dark/light variants to themes, and the "unknown" variant for the default theme. Other themes don't need the "unknown" variant; webconfig already has a background color in context, and CLI can require the user to specify variant explicitly if terminal doesn't advertise colors. - Every variable that is set as part of fish's default behavior gets a "--label=default" tacked onto it. This is to allow our fish_terminal_color_theme event handler to know which variables it is allowed to update. It's also necessary until we revert 7e3fac561d6 (Query terminal only just before reading from it, 2025-09-25) because since commit, we need to wait until the first reader_push() to get query results. By this time, the user's config.fish may already have set variables. If the user sets variables via either webconfig, "fish_config theme {choose,save}", or directly via "set fish_color_...", they'd almost always remove this label. - For consistency, make default fish_key_bindings global (note that, for better or worse, fish_add_path still remains as one place that implicitly sets universal variables, but it's not something we inject by default) - Have "fish_config theme choose" and webconfig equivalents reset all color variables. This makes much more sense than keeping a hardcoded subset of "known colors"; and now that we don't really expect to be deleting universals this way, it's actually possible to make this change without much fear. Should have split this into two commits (the changelog entries are intertwined though). Closes #11580 Closes #11435 Closes #7317 Ref: https://github.com/fish-shell/fish-shell/issues/12096#issuecomment-3632065704
2025-11-25 12:52:39 +01:00
# CHECK: $fish_color_normal[2]: |--theme=custom-from-userconf|
2025-10-14 10:00:27 +02:00
Use globals for color variables, react to light/dark mode Implicitly-universal variables have some downsides: - It's surprising that "set fish_color_normal ..." and "set fish_key_bindings fish_vi_key_bindings" propagate to other shells and persist, especially since all other variables (and other shells) would use the global scope. - they don't play well with tracking configuration in Git. - we don't know how to roll out updates to the default theme (which is problematic since can look bad depending on terminal background color scheme). It's sort of possible to use only globals and unset universal variables (because fish only sets them at first startup), but that requires knowledge of fish internals; I don't think many people do that. So: - Set all color variables that are not already set as globals. - To enable this do the following, once, after upgrading: copy any existing universal color variables to globals, and: - if existing universal color variables exactly match the previous default theme, and pretend they didn't exist. - else migrate the universals to ~/.config/fish/conf.d/fish_frozen_theme.fish, which is a less surprising way of persisting this. - either way, delete all universals to do the right thing for most users. - Make sure that webconfig's "Set Theme" continues to: - instantly update all running shells - This is achieved by a new universal variable (but only for notifying shells, so this doesn't actually need to be persisted). In future, we could use any other IPC mechanism such as "kill -SIGUSR1" or if we go for a new feature, "varsave" or "set --broadcast", see https://github.com/fish-shell/fish-shell/issues/7317#issuecomment-701165897 https://github.com/fish-shell/fish-shell/pull/8455#discussion_r757837137. - persist the theme updates, completely overriding any previous theme. Use the same "fish_frozen_theme.fish" snippet as for migration (see above). It's not meant to be edited directly. If people want flexibility the should delete it. It could be a universal variable instead of a conf snippet file; but I figured that the separate file looks nicer (we can have better comments etc.) - Ask the terminal whether it's using dark or light mode, and use an optimized default. Add dark/light variants to themes, and the "unknown" variant for the default theme. Other themes don't need the "unknown" variant; webconfig already has a background color in context, and CLI can require the user to specify variant explicitly if terminal doesn't advertise colors. - Every variable that is set as part of fish's default behavior gets a "--label=default" tacked onto it. This is to allow our fish_terminal_color_theme event handler to know which variables it is allowed to update. It's also necessary until we revert 7e3fac561d6 (Query terminal only just before reading from it, 2025-09-25) because since commit, we need to wait until the first reader_push() to get query results. By this time, the user's config.fish may already have set variables. If the user sets variables via either webconfig, "fish_config theme {choose,save}", or directly via "set fish_color_...", they'd almost always remove this label. - For consistency, make default fish_key_bindings global (note that, for better or worse, fish_add_path still remains as one place that implicitly sets universal variables, but it's not something we inject by default) - Have "fish_config theme choose" and webconfig equivalents reset all color variables. This makes much more sense than keeping a hardcoded subset of "known colors"; and now that we don't really expect to be deleting universals this way, it's actually possible to make this change without much fear. Should have split this into two commits (the changelog entries are intertwined though). Closes #11580 Closes #11435 Closes #7317 Ref: https://github.com/fish-shell/fish-shell/issues/12096#issuecomment-3632065704
2025-11-25 12:52:39 +01:00
echo yes | fish_config theme save default
2025-10-14 10:00:27 +02:00
set -S fish_color_normal
# CHECK: $fish_color_normal: set in universal scope, unexported, with 1 elements
2025-10-14 10:00:27 +02:00
# CHECK: $fish_color_normal[1]: |normal|
}
fish_config theme dump badarg
# CHECKERR: Too many arguments