This would fail the FreeBSD tests whenever we merge or push multiple
times in quick succession.
Basically:
- Commits up to ABCDEF are pushed, which triggers a CI run
- Cirrus starts up, but takes a while - it knows to use commit ABCDEF
- More commits are pushed up to 123456
- Cirrus does a shallow clone, only has 123456
- Cirrus tries to check out ABCDEF, but doesn't know it - instant failure
Instead, let's use 100 commits, which should be enough
We require 3.19
This also makes skipped tests visible, which showed that the
print-help test was never run because the REQUIRES line was off.
In sh-mode, bash's `command -v` returns true if *all* commands exist.
The special input functions self-insert, self-insert-not-first, and
and or used to be handled by inputter_t::readch, but they aren't
anymore with `commandline -f`.
I am unsure if these *would* have worked, I can't come up with a use.
So, for now, do nothing instead of panicking.
This would crash if you ran `commandline -f backward-jump`.
The C++ version would read a char (but badly), this doesn't anymore.
So, at least instead of crashing, just do nothing.
One issue with fish_add_path at the moment is that it is sometimes a bit too intransparent.
You'll try to add a path, but it won't appear - was that because it wasn't a directory,
or because it doesn't exist, or because it was already included?
If it isn't usable after, did fish_add_path not add it because of something or did something *else* remove it?
So we give more explanations - "skipping this because it's a file", "not setting anything because no paths are left to add", ...
fish_add_path can be used either interactively, in the commandline,
or in config.fish. That's its greatest strength, it's a very
DWIM-style command.
One of the compromises that entails, however, is that it can't really
be very loud about what it does. If it skips a path, it can't write a
warning because it might be used in config.fish.
But it *can* if it's used interactively. So we try to detect that case
and enable verbose mode automatically.
That means if you do
```fish
fish_add_path /opt/mytool/bin/mytool
```
it may tell you "Skipping path because it is a file instead of a
directory:".
The check isn't perfect, it goes through status current-command and
isatty, but it should be good for most cases (and be false in config.fish).
The prompt regex for pexpect was:
```
return re.compile(
r"""(?:\r\n?|^) # beginning of line
(?:\x1b[\d[KB(m]*)* # optional colors
(?:\x1b[\?2004h) # Bracketed paste
(?:\x1b[>4;1m) # XTerm's modifyOtherKeys
(?:\x1b[>5u) # CSI u with kitty progressive enhancement
(?:\x1b=) # set application keypad mode, so the keypad keys send unique codes
(?:\[.\]\ )? # optional vi mode prompt
"""
+ (r"prompt\ %d>" % counter) # prompt with counter
+ r"""
(?:\x1b[\d\[KB(m]*)* # optional colors
""",
re.VERBOSE,
)
```
This has a terrible bug: an accidentally unescaped bracket here:
(?:\x1b[>4;1m) # XTerm's modifyOtherKeys
^
This bracket then extends throughout the entire regex, and is
accidentally terminated here:
(?:\x1b[\d\[KB(m]*)* # optional colors
^
Thus the whole regex is busted; in particular the prompt counters are
not being tested correctly.
A second issue is that these escape sequences are not emitted before the
first prompt, so correcting the regex will cause every test to fail.
Fix this by ignoring all of the escape sequences and merely look for
the "prompt %d>" portion.
THIS DELIBERATELY CAUSES TEST FAILURES.
The tests were already broken and falsely reported as passing.
These will be fixed in followup commits.
Good news is that the tests should become way more reliable after
this is fixed - hopefully no more introducing random sleep() calls.
This doesn't pull its weight. Block size is not a particularly big
problem,
and this both complicates the code a bit and would arbitrarily cause issues
if a fish script exceeded 65k lines.
This reverts commit edd6533a14.
This doesn't have any effect on the size of the struct (due to alignment
requirements and padding) but reduces the complexity by turning
Block::wants_pop_env into an emergent property dependent on the type rather than
something we have to manually manage.
We only increment it and check if it's non-zero, we never decrement or check the
actual count. As such, change it to a bool and bring the size of `Block` down
from 32 to 24 bytes.
We almost never access any of this and having it stored directly in the `Block`
struct increases its size (reducing how many we can fit in L1 and L2, and
increasing memory copy traffic).
Gets rid of BlockData::None so we can avoid allocating a Box at all when we have
no data (at the cost of yet-another-wrapper-type), which is the usual case.
This has a few advantages,
* We now statically assert that all fields used by a particular block type are
correctly initialized (i.e. you can't assign the function name but forget to
assign its arguments),
* Conversely, we can match directly on `BlockData` and be guaranteed that the
fields we want to access are initialized and present,
* We reduce the number of assertions, effectively "unwrapping" only once based
off the block type instead of each time we try to access a conditional field,
* We reduce the size of the `Block` struct by coalescing fields that cannot
co-exist, bringing it down from 104 bytes to 88 bytes.
It would be nice to make all of `Block` itself an enum, but it currently
requires `Copy` and we take advantage of that to copy it around everywhere.
Putting these fields directly in `Block` directly would mean a lot more memory
traffic just checking block types.
There's no need for two separate block types when one is merely a variant of the
other. This may have been required under C++ but thanks to sum types (rust's
enums) we don't need to do that any more.
The value completions were rendered almost entirely useless due to the forced
inclusion of file completions at all tokens, including in the head/command
position thanks to the use of `__fish_complete_subcommand` which doesn't
understand the semantics of `env` and expects something like `ssh`. But we don't
need it at all.
