functions -v --details is indecipherable when used interactively

[floam]

The output should be more in line with status or set --show, and be human readable. We can probably only improve this if we are outputting to a TTY because of compatibility reasons now.

For example, line number: 9 would be less confusing than just 9 in this output:

$ functions --details -v _
/usr/local/share/fish/functions/_.fish
autoloaded
9
scope-shadowing
Fallback alias for the gettext command

... I had a hard time guessing what it meant.

When given a function name that cannot be found, a non-zero exit status should probably occur and an error printed to stderr, rather than this mess:

$ functions --details -v foo
n/a
n/a
0
n/a
n/a

Also, autoloaded/not-autoloaded is ambiguous and could be better described. I had initially assumed this would tell me if the function had already been autoloaded or if it has not yet been autoloaded from the filename printed, and that n/a meant the function was explicitly defined somewhere.

In reality calling --details causes any function that can be autoloaded to be loaded and it was reporting if it was loaded that way vs. explicitly defined.

A better approach to making this easy to parse would be allowing --details to take an optional argument rather than relying on fixed indicies:

$ functions --details=description _
Fallback alias for the gettext command
$ functions --details=line _
9

[zanchey]

My understanding is that functions --details was designed for consumption by tools rather than being human-readable, so I really like the --details=description approach.

Autoloading functions probably needs to be considered as a separate issue.

[Delapouite]

functions --details=description foo would be handy to implement the demand of "explaining the token under the cursor with Alt+W" described here #2083

That is using the return value at the top of the __fish_whatis_current_token function https://github.com/fish-shell/fish-shell/blob/master/share/functions/__fish_whatis_current_token.fish