Results after 14908322a9, compared to 3.1.2:
math.fish
fish
rusage self:
user time: 916 ms
sys time: 39 ms
total time: 955 ms
max rss: 35028 kb
signals: 0
build/fish
rusage self:
user time: 769 ms
sys time: 60 ms
total time: 829 ms
max rss: 34868 kb
signals: 0
Benchmark #1: fish benchmarks/benchmarks/math.fish > /dev/null
Time (mean ± σ): 955.2 ms ± 32.5 ms [User: 897.2 ms, System: 57.9 ms]
Range (min … max): 896.3 ms … 1002.5 ms 10 runs
Benchmark #2: build/fish benchmarks/benchmarks/math.fish > /dev/null
Time (mean ± σ): 840.3 ms ± 21.5 ms [User: 784.4 ms, System: 54.8 ms]
Range (min … max): 802.4 ms … 869.0 ms 10 runs
Summary
'build/fish benchmarks/benchmarks/math.fish > /dev/null' ran
1.14 ± 0.05 times faster than 'fish benchmarks/benchmarks/math.fish > /dev/null'
1. This should be using our wcstod_l on platforms where we need
it (for some reason it wasn't picking it up on FreeBSD?)
2. This purports to have a "fast path". I like fast paths.
Locale-wise, we're only interested in one thing:
"." is the radix character when interpreting numbers
And for that it's enough to just use our c-locale, like elsewhere.
This saves a bunch of switching locale back and forth, and simplifies
the code.
Prior to this change, the functions in exec.cpp would return true or false
and it was not clear what significance that value had.
Switch to an enum to make this more explicit. In particular we have the
idea of a "pipeline breaking" error which should us to skip processes
which have not yet launched; if no process launches then we can bail out
to a different path which avoids reaping processes.
Trying to switch to a remote branch like "upstream/ver2" will error with "fatal: a branch is expected, got remote branch 'upstream/ver2'", so these completions should only print the branch name. There doesn't seem to be a function for printing just the branch names for remotes (branch names can have forward-slashes in them), so I have just left them out for now.
This would tell you a function was "Defined in - @ line 1" for every
function defined via `source`.
Really, ideally we'd figure out where the *source* call was, but that'
much more complicated, so we just give a comprehensible message.
This can use files/directories in a variety of ways, and it's
basically impossible to enumerate all of them - basically *any file*
could be mounted, if only there is a filesystem for it.
We still give the blockdevices and predefined mountpoints, so they can
still be used.
This matches what we do in --profile's output:
```
> source /home/alfa/.config/fish/config.fish
--> set -gx XDG_CACHE_HOME /home/alfa/.cache
--> set -gx XDG_CONFIG_HOME /home/alfa/.config
--> set -gx XDG_DATA_HOME /home/alfa/.local/share
```
instead of
```
+ source /home/alfa/.config/fish/config.fish
+++ set -gx XDG_CACHE_HOME /home/alfa/.cache
+++ set -gx XDG_CONFIG_HOME /home/alfa/.config
+++ set -gx XDG_DATA_HOME /home/alfa/.local/share
```
This increases a 100ms timeout to 200ms, because we've hit it on
Github Actions:
```
INPUT 3904.65 ms (Line 223): set -g fish_escape_delay_ms 100\n
OUTPUT +1.74 ms (Line 224): \rprompt 25>
INPUT +0.71 ms (Line 230): echo abc def
INPUT +0.57 ms (Line 231): \x1b
INPUT +0.57 ms (Line 232): t\r
OUTPUT +2.41 ms (Line 234): \r\ndef abc\r\n
OUTPUT +1.63 ms (Line 234): \rprompt 26>
INPUT +0.75 ms (Line 239): echo ghi jkl
INPUT +0.57 ms (Line 240): \x1b
INPUT +134.98 ms (Line 242): t\r
```
In other places it decreases sleeps where we just wait for a timeout to elapse, in which case we don't need much longer than the timeout.
Prior to this change, if fish were launched connected to a tty but not as
pgroup leader, it would attempt to become pgroup leader only if
--interactive is explicitly passed. But bash will unconditionally attempt
to become pgroup leader if launched interactively. This can result in
scenarios where fish is running interactively but in another pgroup. The
most obvious impact is that control-C will result in the pgroup leader
(not fish) exiting and make fish orphaned.
Switch to matching the bash behavior here - we will always try to become
pgroup leader if interactive.
Fixes#7060.
And again clang-format does something I don't like:
- if (found != end && std::strncmp(found->name, name, len) == 0 && found->name[len] == 0) return found;
+ if (found != end && std::strncmp(found->name, name, len) == 0 && found->name[len] == 0)
+ return found;
I *know* this is a bit of a long line. I would still quite like having
no brace-less multi-line if *ever*. Either put the body on the same
line, or add braces.
Blergh
At least on Arch Linux, pacmd and pulseaudio aren't necessarily available just because pactl is (pipewire is now a thing, and it installs libpulse but not pulseaudio)
When building from source, there is a warning:
../doc_src/cmds/string-match.rst:13: WARNING: Inline emphasis
start-string without end-string.
One fix appears to be putting a space after the epmhasized 'n' character,
e.g., `*n* th` instead of `*n*th`.
When globbing, we have a base directory (typically $PWD) and a path
component relative to that. As PWD is "virtual" it may be a symlink. Prior
to this change we would use wrealpath to resolve symlinks before opening
the directory during a glob, but this call to wrealpath consumed roughly
half of the time during globbing, and is conceptually unnecessary as
opendir will resolve symlinks for us.
Remove it. This may have funny effects if the user's PWD is an unlinked
directory, but it roughly doubles the speed of a glob like `echo ~/**`.
This adds the ability to limit how many expansions are produced. For
example if $big contains 10 items, and is Cartesian-expanded as
$big$big$big$big... 10 times, we would naviely get 10^10 = 10 billion
results, which fish can't actually handle. Implement this in
completion_receiver_t, which now can return false to indicate an overflow.
The initial expansion limit 'k_default_expansion_limit' is set as 512k
items. There's no way for users to change this at present.
This switches certain uses from just appending to a list to using
completion_receiver_t, in preparation for limiting how many completions
may be produced. Perhaps in time this could also be used for "streaming"
completions.
completion_receiver_t wraps a completion list; it will centralize logic
around adding completions and most importantly it will enforce that we
do not exceed our expansion limit.
