functions --details does not return source file path after initial funcsave

[neilyio]

I write a lot of custom fish scripts to help me edit/test fish functions, so I rely pretty heavily on functions --details <function-name> to tell me where a function is defined. I understand that a return string of stdin is expected when you freshly define a function at the command line, as there's no file path yet. But I was a little surprised that's still the case after running funcsave.

It's possible this is the behavior we want, because technically that function was defined though stdin, not by reading a source file. But in script pipelines like mine, where I like to automate creation/editing of fish functions, it means that I can't always have a consistent way to get a function's filepath.

A workaround for this is to run function --details in a subshell, which returns the correct filepath because the subshell loads the newly-saved function from its source file. But I'm not sure this is particularly intuitive. With my workaround, the proper filepath could be retrieved like this:

echo (fish -c "functions --details <function-name>")

Here's a short session demonstrating the behavior I see. My system info is at the top if it's helpful to anyone.

~/Desktop ❯❯❯ echo $TERM
alacritty
~/Desktop ❯❯❯ uname -a
Darwin Neils-MacBook-Air.local 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul  5 22:22:52 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T8103 arm64
~/Desktop ❯❯❯
~/Desktop ❯❯❯
~/Desktop ❯❯❯
~/Desktop ❯❯❯ fish --version
fish, version 3.6.1
~/Desktop ❯❯❯ function deleteme
              end
~/Desktop ❯❯❯ functions --details deleteme
stdin
~/Desktop ❯❯❯ funcsave deleteme
funcsave: wrote ~/.config/fish/functions/deleteme.fish
~/Desktop ❯❯❯ functions --details deleteme
stdin

[faho]

The easiest thing to do is probably to source the function again after funcsave:

funcsave foo; and source ~/.config/fish/functions/foo.fish

That will redefine "foo" and thereby reset the filename.

An alternative is to see if you get "stdin", and then check if an autoload file exists:

set -l path (functions --details $name)
if test "$path" = stdin
    set -l p (path filter -rf $fish_function_path/$name.fish)[1]
    and set path $p
end

It's possible this is the behavior we want, because technically that function was defined though stdin, not by reading a source file.

This is really the important point - it wasn't defined in that file, that's not where it comes from.

In particular if you get the function from somewhere else and then decide to funcsave... which location wins? If you have a function in config.fish, and you funcsave it, was it defined in config.fish or is it now defined in the autoload file?

I think that what we have now is consistent and not wrong, so I'm not inclined to change it.

I would be up for adding a --reload option to funcsave to automate that source part - the path that funcsave uses won't always be in ~/.config/fish/functions.