Apparently an anonymous hyperlink looks like `__something__`.
I had to find this by deleting parts of the document and building to
narrow it down until I had the line, because sphinx wouldn't give a
line number.
See #5696.
[ci skip]
This was:
- Some `` mismatches - it's "``something``", not "``something`".
- Some "explicit targets", which IMHO are quite a misfeature - `word
<link>`_ has to be unique, which I don't see a usecase for. Instead
use `word <link>`__, with a double-underscore at the end.
- One case of `||` which I just removed
See #5696.
[ci skip]
This both formats it as a code-block, and adds the synopsis of each
subcommand to the corresponding section again so you don't need to
scroll back-and-forth so much.
[ci skip]
Apparently there must indeed be a toctree somewhere in the document to
get the links to the other docs to show up.
Even a ":hidden:" toctree doesn't help - that just leads to an empty
toc in the sidebar (no idea yet where that's defined!).
I've added it to the end so it's not that weird "Commands" section in
the middle.
[ci skip]
The final test in `realpath.in` was based on the no-longer-valid
assumption that $PWD cannot be a symlink. Since the recent changes in
fish 3.0 to allow `cd`ing into "virtual" directories preserving symlinks
as-is, when `make test` was run from a path that contained a symlink
component, this test would fail the `pwd-resolved-to-itself` check.
As the test is not designed to initialize then cd into an absolute path
guaranteed to not be symbolic, so this final check is just wrong.
Directly access the job list without the intermediate job_iterator_t,
and remove functions that are ripe for abuse by modifying a local
enumeration of the same list instead of operating on the iterators
directly (e.g. proc.cpp iterates jobs, and mid-iteration calls
parser::job_remove(j) with the job (and not the iterator to the job),
causing an invisible invalidation of the pre-existing local iterators.
This has been driving nuts for years. The output of the diff emitted
when a test fails was always reversed, because the diff tool is called
with `${difftool} ${new} ${old}` so all the `-` and `+` contexts are
reversed, and the highlights are all screwed up.
The output of a `make test` run should show what has changed from the
baseline/expected, not how the expected differs from the actual. When
considered from both the perspective of intentional changes to the test
outputs and failed test outputs, it is desirable to see how the test
output has changed from the previously expected, and not the other way
around.
(If you were used to the previous behavior, I apologize. But it was
wrong.)
It's not _perfect_, but should hopefully ease the introduction a
teensy bit.
We use `timedatectl` because it's a reasonably simple command that
still uses subcommands and some generated candidates.
[ci skip]
This printed weird things like
```fish
$ functions -x
functions: Unknown option '-x'
(Type 'help functions' for related documentation)
```
Instead, let's make it
```fish
$ functions -x
functions: Unknown option '-x'
(Type 'help functions' for related documentation)
```
This was printed basically everywhere.
The user knows what they executed on standard input.
A good example:
```fish
set c (subme 513)
```
used to print
```
fish: Too much data emitted by command substitution so it was discarded
set -l x (string repeat -n $argv x)
^
in function 'subme'
called on standard input
with parameter list '513'
in command substitution
called on standard input
```
and now it is
```
fish: Too much data emitted by command substitution so it was discarded
set -l x (string repeat -n $argv x)
^
in function 'subme' with arguments '513'
in command substitution
```
See #5434.
Now:
```
cd: Unknown option '-r'
~/dev/fish-shell/share/functions/cd.fish (line 40):
builtin cd $argv
^
in function 'cd' with arguments '-r'
in function 'f'
in function 'd'
in function 'b' with arguments '-1q --wurst'
in function 'a'
called on standard input
```
See #5434.
This printed things like
```
in function 'f'
called on standard input
in function 'd'
called on standard input
in function 'b'
called on standard input
in function 'a'
called on standard input
```
As a first step, it removes the empty lines so it's now
```
in function 'f'
called on standard input
in function 'd'
called on standard input
in function 'b'
called on standard input
in function 'a'
called on standard input
```
See #5434.
