Feature request: consider adding a $fish_theme_path variable to support multiple directories for themes

[mattmc3]

Similar to fish_function_path and fish_complete_path, it would be helpful to have a fish_theme_path variable. This variable would be a list indicating where fish_config theme <cmd> would find its *.theme files.

This would allow Fish theme authors (like dracula and TokyoNight) to more easily migrate to using *.theme files. Fisher, a very popular fish plugin manager, now supports themes, but with limitations due to the lack of this functionality.

[faho]

The issue with a $fish_theme_path variable is that it won't be available to the web interface, and getting it in there is awkward.

Couldn't fisher just symlink the theme files?

(tbh I'm not entirely clear on what $fisher_path is and why one would want to set it to something different from the default, so I'm probably just lacking context here)

[mattmc3]

Couldn't fisher just symlink the theme files?

The current solution is to just use symlinks, yes. But that's different than how functions, completions, and conf.d are handled.

tbh I'm not entirely clear on what $fisher_path is and why one would want to set it to something different from the default, so I'm probably just lacking context here

The idea isn't unique to Fisher. It's simply to separate configs you write from configs others write. Essentially keeping your personal config separate (and thus less cluttered). Fisher makes use of $fish_complete_path and $fish_functions_path to accomplish this by letting you do this:

set -q fisher_path || set -U fisher_path $__fish_config_dir/.fisher
set fish_function_path $fish_function_path[1] $fisher_path/functions $fish_function_path[2..]
set fish_complete_path $fish_complete_path[1] $fisher_path/completions $fish_complete_path[2..]

The issue with a $fish_theme_path variable is that it won't be available to the web interface, and getting it in there is awkward.

Interesting! I already assumed the web interface did NOT pick up what you had in your themes directory because it doesn't show up in mine (running fish_config on Fish 3.6 latest). I only see my local themes when I run the command line interface for fish_config - ie: fish_config theme list or fish_config theme choose xyz.

If the thought is that this needs supported on the web interface, can you confirm it's supposed to work that way now (ie: is there a problem on my end, or a Fish bug)? If the intended behavior is what I'm experiencing (only default themes show in the web interface of fish_config), then is it really much of a problem if this new variable is CLI only?

EDIT: apparently I had XDG_CONFIG_HOME set, but not exported (-U, not -Ux), so when fish_config ran its web interface, XDG_CONFIG_HOME was not found. I think we're good on that side question now.

[faho]

can you confirm it's supposed to work that way now (ie: is there a problem on my end, or a Fish bug)?

It does work like that on my end, yes, and I wrote it like that.

[mattmc3]

Also, I'm still scratching my head a bit on the web interface not understanding a $fish_theme_path, because it's definitely showing me all the functions in my $fish_function_path.

[faho]

It does that by asking fish to enumerate the functions (by running functions). Because we control function names, that's easy. To get all the themes we'd have to ask it to list all the themes, but then we run into the usual problem with unix paths (they're terrible). It's not impossible, but annoying and awkward, and I would prefer not to do it.

[mattmc3]

Thank you for the added context. It's really helpful. Let me do some more digging and see if there's a solution that makes sense given these constraints. One other simple alternative to accomplish getting themes from multiple places - allow subdirectories in themes. That would mean symlinks could be at the subdirectory level rather than individual .theme files, and then it's just globbing on $__fish_conf_dir/themes/**/*.theme. There'd be a small performance penalty, but not terrible.