I don't know if anyone has installed mandoc/groff but not man.
Since 4.1 we officially require "man" as dependency (hope that works
out; we're missing some standardization, see #12037). Remove the
fallback with the old mandoc/nroff logic. This makes the next commit
slightly simpler -- which is not enough reason by itself, but we want
to do this anyway at some point.
These are code clones, apart from the fact that __fish_print_help
doesn't have the '{' case, because alt-h/f1 will never find that.
But adding it doesn't really hurt because it's unlikely that the user
will have a manpage for '{'. Extract a function.
We use absence of "$__fish_data_dir[1]" as criteria to use the
"standalone" code paths that use "status list-files/get-file" instead
of $__fish_data_dir.
However, third party software seems slow to react to such breaking
changes, see https://github.com/ajeetdsouza/zoxide/issues/1045
So keep $__fish_data_dir for now to give plugins more time.
This commit makes us ignore $__fish_data_dir on standalone builds
even if defined; a following commit will actually define it again.
I guess the approach in b815fff292 (Set $__fish_data_dir to empty
for embed-data builds, 2025-04-01) made sense back when we didn't
anticipate switching to standalone builds by default yet.
Since 0fea1dae8c (__fish_print_help: Make formatting more man-like,
2024-10-03), there is barely any difference left between "man abbr"
and "abbr -h".
The main difference is that it looks almost like man but is actually
nroff/mandoc and less. This means it doesn't support environment
variables like MANWIDTH and possibly others.
Let's use full "man" for now.
This matches what "git foo --help" does so it's widely accepted.
Keep around a fallback for a while, in case users/packagers fail to
install the new "man" dependency.
In future, "abbr -h" (as opposed to "abbr --help") could show a more
concise version, not sure.
Closes#11786
__fish_print_help supports printing an error message above the
documentation.
This is currently only used by extremely rare edge cases, namely:
eval "break"
eval "continue --unknown"
fish -c 'sleep 10&; bg %1'
Let's remove this feature to enable us to use man directly (#11786).
In case a completion needs a function from another script, run
`complete -C"foo "` to load it, so the full autoloading logic is used.
Otherwise these things break if the path is off. E.g. cargo's version
will fail if you override the cargo completion in
~/.config/fish/completions without also overriding the rustup
completions.
In other cases, fix for empty $__fish_data_dir, which will be coming in the next commit
Unlike other builtins, "{" is a separate token, not a keyword-string
token.
Allow the left brace token as command string; produce it when parsing
"{ -h"/"{ --help" (and nowhere else). By using a decorated statement,
we reuse logic for redirections etc.
Other syntax elements like "and" are in the builtin list, which
- adds highlighting logic
- adds it to "builtin --names"
- makes it runnable as builtin
(e.g. "builtin '{'" would hypothetically print the man page)
These don't seem very important (highlighting for '{' needs to match
'}' anyway).
Additionally, making it a real builtin would mean that we'd need to
deactivate a few places that unescape "{" to BRACE_BEGIN.
Let's not add it to the built in list. Instead, simply synthesize
builtin_generic in the right spot.
I'm assuming we want "{ -h" to print help, but '"{" -h' to run an
external command, since the latter is historical behavior. This works
naturally with the above fake builtin approach which never tries to
unescape the left brace.
UnLike other aliases (":.["), ! is special in the grammar but in the
few cases like "! -h" where we parse it as decorated statement they
are equals. Add it to the built in list, so the help argument works.
It can still be overridden, so this should not break anything.
1. Leave the indentation
2. Leave the "NAME" header - without the first line would be
unindented
3. Leave the "SYNOPSIS" header
We use $MANPAGER here, so it should be formatted like a manpage.
The alternative is to write special docs for this use-case, which
would be shorter and point towards the full man page.
Fixes#10625
This makes it easier to get *any pager* in the number of places we do.
Unfortunately:
1. It can't just execute the pager because that might block
2. We can't really set the necessary options for less here
so they still need to be set outside.
This
Fixes#10074
by falling back to `cat` in that case. We could also decide to abort
instead of using a non-pager, but for history that's probably fine.
This is nroff/groff being broken. It turns "→" into "â". This is even if we select `-Tutf8` and friends.
So, if mandoc exists, we prefer that, and otherwise, run preconv on
the file first (if it exists).
Really, what we would need to to is tell nroff to pass `-KUTF-8` to
groff, but that doesn't appear to be possible.
The less -F / --quit-if-one-screen option is buggy before v530. To work
around this, pass --no-init less versions older than 530.
The --no-init option was previously passed; it was removed in d15a51897d
for mouse support. Unfortunately it looks like we can't have mouse
support and --quit-if-one-screen on macOS shipped less (version 487).
It's worth fixing this because otherwise history and help is just not
printed on stock macOS.
Relevant is https://unix.stackexchange.com/questions/107315/less-quit-if-one-screen-without-no-initFixes#8157.
Commit d15a51897 ("Rationalize $LESS uses") switched a "less" flag
from -r (interpret all control characters)
to -R (interpret only color codes)
Somehow this changed the output of "fish -c 'command -h'" to include
weird characters:
DESCRIPTION^O
command^O forces the shell to execute the program COMMANDNAME^O and ignore any functions or builtins with the same name.
Probably this was the reason why I originally used -r over -R. Anyway,
-R is safer and it looks like we can just remove the "ul" preprocessing
since "less" will interpret bold/underline just fine.
Stop using "--no-init"/"-X" because we have no actual reason to and it
may break mouse initialization on my best friend macOS.
Use --RAW-CONTROL-CHARS, the capital version that only lets through
specific escape sequences, not *everything* - we shouldn't have
anything weird here, but less heavily discourages the other version.
Allow a user's $LESS to override.
Fixes#7997.
Prior to this commit "builtin -h" would silently fail when no
documentation is installed. This happens when running fish without
installing it, or when the docs are not installed.
See #7824
"function --argument" is not a thing, it's "--argument-names". This only
accidentally works because our getopt is awful and allows abbreviated
long options.
Similarly, one argparse test used "--d" instead of "-d" or "--def".
Every builtin or function shipped with fish supports flag -h or --help to
print a slightly condensed version of its manpage.
Some of those help messages are longer than a typical screen;
this commit pipes the help to a pager to make it easier to read.
As in other places in fish we assume that either $PAGER or "less" is a
valid pager and use that.
In three places (error messages for bg, break and continue) the help is
printed to stderr instead of stdout. To make sure the error message is
visible in the pager, we pass it to builtin_print_help, every call of which
needs to be updated.
Fixes#6227
This runs build_tools/style.fish, which runs clang-format on C++, fish_indent on fish and (new) black on python.
If anything is wrong with the formatting, we should fix the tools, but automated formatting is worth it.
Using bare vars is more efficient because it makes the builtin `math`
expression cache more useful. That's because if you prefix each var with
a dollar-sign then the fish parser expands it before `math` is run.
Something like `math x + 1` can be cached since the expression is the
same each time it is run. But if you do `math $x + 1` and x==1 then you're
effectively executing `math 1 + 1`. And if x==2 the next time then you're
running `math 2 + 1`. Which makes the expression cache much less effective.
This augments the previous change for issue #3346 by adding an error
message when an invalid integer is seen. This change is likely to be
controversial so I'm not going to squash it into the previous change.
