Historically, Sphinx was required when building "standalone" builds,
else they would have no man pages.
This means that commit 0709e4be8b (Use standalone code paths by
default, 2025-10-26) broke man pages for users who build from a
tarball where non-standalone builds would use prebuilt docs.
Add a hack to use prebuilt docs again.
In future, we'll remove prebuilt docs, see #12052.
Looks like macOS packages didn't have docs??
I noticed via our Cargo warning about sphinx-build.
macOS has a variety of pythons installed:
bash-3.2$ type -a python python3
python is /Library/Frameworks/Python.framework/Versions/Current/bin/python
python3 is /opt/homebrew/bin/python3
python3 is /usr/local/bin/python3
python3 is /Library/Frameworks/Python.framework/Versions/Current/bin/python3
python3 is /usr/bin/python3
by default, "uv --no-managed-python" uses python3 (homebrew), but
"python" (and "pip") use the other one. Make uv use the same as
our scripts. Not all uv commands support "--python" today, so set
UV_PYTHON.
Use the pinned versions of Sphinx + dependencies, for reproducibility
and correctness. (Specifically, this gives us proper OSC 8
hyperlinks when /bin/sphinx-build is affected by a packaging bug,
see https://github.com/orgs/sphinx-doc/discussions/14048)
Ideally we want to credit reported-by/helped-by etc. but we'd need
to ask the GitHub API for this information.
Also we should use %(trailers) if possible.
HistoryIdentifier was an over-engineered way of annotating history items
with the paths that were found to be valid, for autosuggestion hinting.
It wasn't persisted to the file. Let's just get rid of this.
Use fstat() instead of lseek() to determine history file size.
Pass around the file_id instead of recomputing it.
This saves a few syscalls; no behavior change is expected.
Historically,
- our "man" wrapper prepends /usr/share/fish/man to $MANPATH
- "__fish_print_help" only operates on /usr/share/fish/man, to it
accesses that directly
However standalone builds -- where /usr/share/fish/man may not exist
-- have complicated things; we temporarily materialize a fake man
directory.
Reuse __fish_print_help instead of duplicating this.
Part of #12037
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.
We always try to prepend our man path to $MANPATH before calling man.
But this is not necessary when we're gonna display the output of
"status get-file man/man1/abbr.1".
Overriding man pages can cause issues like
https://github.com/fish-shell/fish-shell/issues/11472https://gitlab.com/man-db/man-db/-/merge_requests/15
which by themselves are maybe not enough reason to avoid exporting
MANPATH, but given that embedded man pages might become the only
choice in future (see #12037), we should reduce the scope of our
custom MANPATH.
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.
These were added automatically when we used the `--strict` flag with
gettext commands. We stopped using this flag, but existing empty
comments are not automatically deleted, so it is done here manually.
Closes#12038
Also use the correct OSC number.
Note that this only works on few terminals (such as iTerm2). Not sure
if it's worth for us to have this feature but I guess multiple users
have requested it.
The section on build_tools/style.fish was stale. That tool does not
automagically format unstaged changes or the last commit's changes
anymore. Relying on such tools is bad practice anyway, people should
configure their editor to fix the style violations at the source.
Replace "before committing" with neutral phrasing.
Remove the redundant mention of "cargo fmt" and "clippy". Use of
clippy goes without saying for Rust projects. Instead, add another
mention of "build_tools/checks" which also does clippy as well as
translation update checks (which are commonly needed).
Drop the "testing with CMake" part since it's a legacy thing and
basically never needed, especially by new faces.
Use semantic line breaks in the paragraphs starting at "When in doubt".
- this is not specific to fish and only relevant to people who push
directly to master
- we don't push directly to master as often anymore
- I don't think we used it much in practice (when we should have).
- a good portion of contributions is pushed with jj which probably
does this differently
Let's remove it even though this is a nice piece of documentation.
I guess we could add it back to doc_internal/ if we have the capacity
to maintain it.
ja: the motivation for our own crate is
1. the tempfile crate is probably overkill for such a small
piece of functionality (given that we already assume Unix)
2. we want to have full control over the few temp files we
do create
Closes#12028
Since the parent commit, these tests fail repeatedly in macOS GitHub
Actions CI: complete-group-order.py, nullterm.py, scrollback.py and
set_color.py. They run fine in isolation.
We'll fix the flaky system tests soon (#11815) but until then, remove
parallelism from macOS CI.
Unlike other shells, fish tries to make it easy to work with multiline
commands. Arguably, it's often better to use a full text editor but
the shell can feel more convenient.
Spreading long commands into multiple lines can improve readability,
especially when there is some semantic grouping (loops, pipelines,
command substitutions, quoted parts). Note that in Unix shell, every
quoted string can span multiple lines, like Python's triple quotes,
so the barrier to writing a multiline command is quite low.
However these commands are not autosuggested. From
1c4e5cadf2 (commitcomment-150853293)
> the reason we don't offer multi-line autosuggestion is that they
> can cause the command line to "jump" to make room for the second
> and third lines, if you're at the bottom of your terminal.
This jumping (as done by nushell for example) might be surprising,
especially since there is no limit on the height of a command.
Let's maybe avoid this jumping by rendering only however many lines
from the autosuggestion can fit on the screen without scrolling.
The truncation is hinted at by a single ellipsis ("…") after the
last suggested character, just like when a single-line autosuggestion
is truncated. (We might want to use something else in future.)
To implement this, query for the cursor position after every command,
so we know the y-position of the shell prompt within the terminal
window (whose height we already know).
Also, after we register a terminal window resize, query for the cursor
position before doing anything else (until we od #12004, only height
changes are relevant), to prevent this scenario:
1. move prompt to bottom of terminal
2. reduce terminal height
3. increase terminal height
4. type a command that triggers a multi-line autosuggestion
5. observe that it would fail to truncate properly
As a refresher: when we fail to receive a query response, we always
wait for 2 seconds, except if the initial query had also failed,
see b907bc775a (Use a low TTY query timeout only if first query
failed, 2025-09-25).
If the terminal does not support cursor position report (which is
unlikely), show at most 1 line worth of autosuggestion. Note that
either way, we don't skip multiline commands anymore. This might make
the behavior worse on such terminals, which are probably not important
enough. Alternatively, we could use no limit for such terminals,
that's probably the better fallback behavior. The only reason I didn't
do that yet is to stay a little bit closer to historical behavior.
Storing the prompt's position simplifies scrollback-push and the mouse
click handler, which no longer need to query. Move some associated
code to the screen module.
Technically we don't need to query for cursor position if the previous
command was empty. But for now we do, trading a potential optimization
for andother simplification.
Disable this feature in pexpect tests for now, since those are still
missing some terminal emulation features.
