Make it an ordinary struct wrapping a vector, instead of a template.
This is in preparation for using it more widely, for matching bindings
as well as mouse CSI sequences.
Also add some mouse-disabling tests.
This runs in 100ms increments, so there's not a lot of harm in trying
longer - it should take the same time everywhere it succeeded before.
But I've reproduced failures on FreeBSD 13 on sr.ht, so there's at
least one platform where a total time of 1 second isn't enough.
Now we do 50 tries, which is 5 seconds.
This could have been one iteration off, e.g.
```fish
function on-winch --on-signal winch
echo $LINES
end
```
Resize the terminal, it'll print e.g.
24
then run `echo $LINES` interactively, it might have a different answer.
This isn't beautiful, but it works. A better solution might be to make
the termsize vars electric and just always update them on read?
When fish starts, it notices which pgroup owns the tty, and then it
restores that pgroup's tty ownership when it exits. However if fish does
not own the tty, then (on Mac at least) the tcsetpgrp call triggers a
SIGSTOP and fish will hang while trying to exit.
The first change is to ignore SIGTTOU instead of defaulting it. This
prevents the hang; however it risks re-introducing #7060.
The second change somewhat mitigates the risk of the first: only do the
restore if the initial pgroup is different than fish's pgroup. This
prevents some useless calls which might potentially steal the tty from
another process (e.g. in #7060).
This concerns the behavior when running an external command from a key
binding. The history is:
Prior to 5f16a299a7, fish would run these external commands in shell
modes. This meant that fish would pick up any tty changes from external
commands (see #2114).
After 5f16a299a7, fish would save and restore its shell modes around
these external commands. This introduced a regression where anything the
user typed while a bound external command was executing would be echoed,
because external command mode has ECHO set in c_lflag. (This can be
reproed easily with `bind -q 'sleep 1'` and then pressing q and typing).
So 5f16a299a7 was reverted in fd9355966.
This commit partially reverts fd9355966. It has it both ways: external
commands are launched with shell modes, but/and shell modes are restored
after the external command completes. This allows commands to muck with
the tty, as long as they can handle getting shell modes; but it does not
enable ECHO mode so it fixes the regression found in #7770.
Fixes#7770. Fixes#2114 (for the third time!)
This partially reverts commit fd9355966e.
Unfortunately this causes input coming in while bind functions are
running to show up on screen.
Since the cure is worse than the disease let's just stop doing it.
My guess is this needs to *only* be done while running an external
command.
Fixes#7770
Reintroduces #2114
Partially reverts 5f16a299a7
For reasons unclear to me, fish enables bold mode unconditionally if
the background is set.
However, this called a background "set" if it wasn't exactly the
"normal" color, whereas set_color --print-colors would set a color
of *none*.
We have three special non-color colors:
- "normal"
- "reset"
- "none"
All of these specify some form of absence of background color, so all
of them should be checked.
Fixes#7805
NetBSD's sleep quits when foregrounded sometimes. I'm not entirely
sure *why*, but this is reproducible with the default /bin/sh, so it's
not our fault.
Because this fails our tests, go back to using cat *there*, because we
can't use it on macOS - 4c9d01cab0.
This fails on FreeBSD on sr.ht and NetBSD on my own VM, but it works manually.
It also fails on macOS but I have no way to confirm.
I think it might be a problem in pexpect's platform support?
Either way, the test is valuable so just skip it there and solve it later.
This was lost in
6bdbe732e40c2e325aa15fcf0f28ad0dedb3a551..c7160d7cb4970c2a03df34547f357721cb5e88db.
Note that we only print a term-support flog message for now, the
warning seems a bit much.
Fixes#7709.
Prior to this change, `fish_private_mode` worked by just suppressing
history outright. With this change, `fish_private_mode` can be toggled on
and off. Commands entered while `fish_private_mode` is set are stored but
in memory only; they are not written to disk.
Fixes#7590Fixes#7589
Don't go into implicit interactive mode without ever executing
anything - not even `exit` or reacting to ctrl-d. That just renders
the shell useless and unquittable.
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.
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
Prior to this fix, when key binding is a script command (i.e. not a
readline command), fish would run that key binding using fish's shell
tty modes. Switch to using the external tty modes. This re-fixes
issue #2214.
With the upcoming fix to place the tty in external-proc mode, add a sleep
which resolves a race between emitting a newline and restoring it to shell
mode.
Prior to this change, when a process resumes because it is brought back
to the foreground, we would reset the terminal attributes to shell mode.
This fixed#2114 but subtly introduced #7483.
This backs out 9fd9f70346, re-introducing #2114 and re-fixing #7483.
A followup fix will re-fix #2114; these are broken out separately for
bisecting purposes.
Fixes#7483.
I *think* this might sometimes (on CI) be eating the prompt, so that the actual `prompt`
part of `expect_prompt` doesn't find anything.
On Github Actions we see things like:
```
Testing file pexpects/generic.py ... Failed to match pattern: prompt 5
generic.py:35: timeout from expect_prompt("echo .history.*")
[...]
OUTPUT +1.08 ms (Line 31): \rprompt 4>
INPUT +0.35 ms (Line 34): echo $history[1]\n
OUTPUT +1.58 ms (Line 35): echo $history[1]\r\necho $history[1]\r\n⏎ \r⏎ \r\rprompt 5>
```
so the prompt *is* printed, it's just not correctly matched.
Apparently on macOS SIGTSTP (from control-Z) causes `read()` to return
EINTR.
This means `cat | cat` will exit as soon as it's backgrounded and
brought back.
So instead we use `sleep`, which won't read(), and therefore is
impervious to these puny attacks.
See discussion in #7447.
The classic mistake: Some of these have a bit of a delay, but it's supposed to
be *under* the timeout, so it needs to be *shorter* not longer to
increase the slack.
We just had the following output on Github Actions:
INPUT +0.94 ms (Line 34): echo ghi jkl
INPUT +0.72 ms (Line 35): \x1b
INPUT +63.12 ms (Line 37): t\r
The default escape delay is 30ms, that had 60ms between an escape and
a tab, so it missed it.
So: We have to increase the delay for CI's benefit. Let's try with
80ms, because otherwise we'd have to bump up other timeouts and the
bind tests take long enough as it is.
Github Action's macOS builds are even more resource-starved (even tho
they use the same provider?) than
Travis, but Travis is unusable to us now, so....
In some cases the completion we come up with may be unexpected, e.g.
if you have files like
/etc/realfile
and
/etc/wrongfile
and enter "/etc/gile", it will accept "wrongfile" because "g" and
"ile" are in there - it's a substring insertion match.
The underlying cause was a typo, so it should be easy to go back.
So we do a bit of magic and let "cancel" undo, but only right after a
completion was accepted via complete or complete-and-search.
That means that just reflexively pressing escape would, by default, get you back to
the old token and let you fix your mistake.
We don't do this when the completion was accepted via the pager,
because 1. there's more of a chance to see the problem there and 2.
it's harder to redo in that case.
Fixes#7433.
We've heard news of this regressing, so let's add the test that should
have been there already (mea culpa!).
Because we now use POSIX_VDISABLE, this should also work in tandem
with ctrl-space (which sends NUL), but we can't test *that* because
some systems might not have POSIX_VDISABLE.
Ensure that the increment= param is set via keyword, not via positional arg.
This mistake was masking a bug where the "^a b c" match was not being tested,
because it was being set as the value for increment!
This switches the 'increment' param from "after" to "before." Instead
of expect_prompt saying if the next prompt will be incremented, each
call site says if it should have been incremented sinec the last prompt.
This makes history searches case-insensitive, unless the search string
contains an uppercase character.
This is what vim calls "smartcase".
Fixes#7273.
Since builtins don't actually have the streams connected, but instead
read input via the io_streams_t objects, this would just always say
what *fish's* fds were.
Instead, pass along some of the stream data to check those
specifically - nobody cares that `test`s fd 0 *technically* is stdin.
What they want to know is that, if they used another program in that
place, it would connect to the TTY.
This is pretty hacky - I abused static variables for this, but
since it's two bools and an int it's probably okay.
See #1228.
Fixes#4766.
With a commandline like
```
a b c d
```
and the cursor at the beginning, this would eat "a b", which isn't a
sensible bigword.
Bigword should be "a word, with optional leading whitespace".
This was caused by an overly zealous state-machine that always ate one
char and only *then* started eating leading whitespace.
Instead eat *a character*, and if it was whitespace go on eating
whitespace, and if it was a printable go straight to only eating
printables.
Fixes#7325.
This can easily lead to an infinite loop, if a variable handler
triggers a repaint and the variable is set in the prompt, e.g. some of
the git variables.
A simple way to reproduce:
function fish_mode_prompt
commandline -f repaint
end
Repainting executes the mode prompt, which triggers a repaint, which
triggers the mode prompt, ....
So we just set a flag and check it.
Fixes#7324.
