`git add` may have to go through literal megabytes of file information
because of tons of untracked files.
So, if the repository is set to not show untracked files (because it's
too slow for the prompt), let's fall back on regular file completions.
(the alternative is to go back to `while read`, but that takes much
longer in repositories of a sensible size)
Fixes#11095
This was copied from C++ code but we have overflow checks, which
forces us to actually handle errors.
While at it, add some basic error logging.
Fixes#11092
Today we might
1. enable modifyOtherKeys
2. get a reply indicating the kitty keyboard protocol is supported
3. because of 2, we never turn off modifyOtherKeys again
Let's get rid of this weird issue by enabling either modifyOtherKeys
or the kitty enhancements only after we know whether the kitty protocol
is supported.
This means we need to call terminal_protocols_enable_ifn() before every
call to readch() until the querying is done. Fortunately, this is
already in place in read_normal_chars(); there are other places that
call readch() but none of those is executed until querying has completed.
At startup we query for
- the cursor position (CSI 6 n)
- kitty keyboard protocol support (CSI ? u)
- terminfo capabilities via XTGETTCAP
Since we don't wait for responses, those can leak into child processes.
Some child processes like fzf cannot decode DCS replies. Plug the
leak by ending each round of querying by asking for the Primary Device
Attribute, and resume input processing only after a response has been
received, (or ctrl-c as an escape hatch).
This is a nice simplification. Tested with the lowest common
denominator (putty, Terminal.app and st).
Fixes#11079
The st terminal wrongly parses CSI ? u as DECRC. A fix has been
proposed upstream. Let's also work around it I guess (not to mention
that querying in the first place is also sort of a workaround).
This reverts commit ebdc3a0393db08d3647070a35cf8e37274b42d42.
Not discussed, includes a new thing that queries the terminal for the client OS
when what is really needed is just a `uname` - which would also work on Terminal.app.
Revert "README for this fork"
This reverts commit 97db461e7f19c51e84fbf0dcb10fb25e0f582870.
Revert "Allow foo=bar global variable assignments"
This reverts commit 45a2017580ceb1ef2d79100b6cbf65d1db3c7fa5.
Revert "Interpret () in command position as subshell"
This reverts commit 0199583435c3b584b90769d50252d16105349671.
Revert "Allow special variables $?,$$,$@,$#"
This reverts commit 4a71ee12883a720408419a53482818177a834ec7.
Revert "Allow $() in command position"
This reverts commit 4b99fe2288da07ea1d0bc79ac0c829b65fee230a.
Revert "Turn off full LTO"
This reverts commit b1213f1385ad07578ca4db5f4fa7cb6371cb3be9.
Revert "Back out "bind: Remove "c-" and "a-" shortcut notation""
This reverts commit f43abc42f91adf43bb2dfc65b29dd4f838ea21cf.
Revert "Un-hide documentation of non-fish shell builtins"
This reverts commit 485201ba2e326a0c711c003290d6f6eb2e247012.
Unlike other builtins, "{" is a separate token, not a keyword-string
token.
Allow the left brace token as command string; produce it when parsing
"{ -h"/"{ --help" (and nowhere else). By using a decorated statement,
we reuse logic for redirections etc.
Other syntax elements like "and" are in the builtin list, which
- adds highlighting logic
- adds it to "builtin --names"
- makes it runnable as builtin
(e.g. "builtin '{'" would hypothetically print the man page)
These don't seem very important (highlighting for '{' needs to match
'}' anyway).
Additionally, making it a real builtin would mean that we'd need to
deactivate a few places that unescape "{" to BRACE_BEGIN.
Let's not add it to the built in list. Instead, simply synthesize
builtin_generic in the right spot.
I'm assuming we want "{ -h" to print help, but '"{" -h' to run an
external command, since the latter is historical behavior. This works
naturally with the above fake builtin approach which never tries to
unescape the left brace.
