As seen in GitHub Actions:
132/193 Test #17: check-completions.fish ...................***Failed 16.28 sec
checks/check-completions.fish..Failure:
There were no remaining checks left to match stdout:1:
OUTPUT from /home/runner/work/fish-shell/fish-shell/share/completions/pulumi.fish: warning: A new version of Pulumi is available. To upgrade from version '3.154.0' to '3.156.0', visit https://pulumi.com/docs/install/ for manual instructions and release notes.
This makes several changes:
- All panes in the current session are now show, instead of just the
current window.
- Instead of using window names when referring to panes (e.g.
"fish-dev.1"), we now use either window indicies ("3.1") or absolute
pane ids (%12). This is mainly because several windows often share the
same window name, e.g. many of my panes are automatically named "fish"
if they are currently running the shell and nothing else.
I put the window names in the descriptions. Because fish uses the
descriptions for completions, completing `fish-dev` is still helpful.
- I include the pane name into the description for a similar reason,
truncated to 15 chars.
- The panes are now ordered carefully, with panes in this window listed
first, then panes are ordered by window, and finally panes are listed
by their id (which does not change when panes are moved between windows)
Example output after `tmux selectp -t <TAB>` for a session with a few
windows. Note that windows 0, 1, and 4 are all named
`fish`. A pane in the current window can be accessed in 3 ways: `3`,
`2.3`, or `%57`.
```
0 (%4 [fish-dev] ~/d/fish-shell <active pane>) 3.1 (%58 [fish] man tmux ~/.c/f...)
1 (%8 [fish-dev] hwatch "jj.logs... <active win.>) 4.0 (%1 [sshd] tmux rename-win...)
2 (%15 [fish-dev] /U/i/d/fish-she... <active win.>) %1 (4.0 [sshd] tmux rename-win...)
3 (%57 [fish-dev] ~/d/fish-shell <active win.>) %4 (2.0 [fish-dev] ~/d/fish-shell <active pane>)
0.0 (%100 [fish] ~) %8 (2.1 [fish-dev] hwatch "jj.logs... <active win.>)
1.0 (%11 [fish] ~/d/_/nixpkgs) %11 (1.0 [fish] ~/d/_/nixpkgs)
1.1 (%38 [fish] ~/.c/f/completi...) %15 (2.2 [fish-dev] /U/i/d/fish-she... <active win.>)
2.0 (%4 [fish-dev] ~/d/fish-shell <active pane>) %38 (1.1 [fish] ~/.c/f/completi...)
2.1 (%8 [fish-dev] hwatch "jj.logs... <active win.>) %41 (3.0 [fish] ~/.c/f/conf.d)
2.2 (%15 [fish-dev] /U/i/d/fish-she... <active win.>) %57 (2.3 [fish-dev] ~/d/fish-shell <active win.>)
2.3 (%57 [fish-dev] ~/d/fish-shell <active win.>) %58 (3.1 [fish] man tmux ~/.c/f...)
3.0 (%41 [fish] ~/.c/f/conf.d) %100 (0.0 [fish] ~)
```
Compared to before:
```
0 (pane) 2 (pane) 0:fish-dev.0 (session:window.pane) 0:fish-dev.2 (session:window.pane) fish-dev (window)
1 (pane) 3 (pane) 0:fish-dev.1 (session:window.pane) 0:fish-dev.3 (session:window.pane)
```
Note that the "before" version describes the same 3 panes several times
in a row, and all the entries involving "fish-dev" are suspect since
there could be another "fish-dev" window (or, more likely, this window
and others could all be named "fish").
Closes#11115
There are some minor updates.
Also, the syntax seems to have changed in tmux 2.4 in 2017,
ef68debc8d/CHANGES (L1484)
Notably, many of the key table commands now use `-T` in place of
the correct `-t`, and the list of key binding tables has changed.
Our versions look like
4.0.0
4.0b1
4.0.1-535-abfef-dirty
But packagers may want to add more information here, and we don't
really care. Note that we no longer ever set the version to "unknown"
since 5abd0e46f5.
Supersedes #11173
Commit 29dc307111 (Insert some completions with quotes instead of backslashes,
2024-04-13) breaks some workflows. Given
touch '[test] file1'
touch '[test] file2'
ls tes<Tab>
we insert completions quoted, which is inconvenient when using globs.
This implicit quoting feature is somewhat minor. But quotes look nicer,
so let's try to keep them. Either way, users can ask for it by starting a
token with «"».
Use quoting only when we insert unique completions.
Closes#11271
This effectively disables "--help", replacing it with just a stand-in
string.
The upshot is that it makes the test suite immune to whether or not it
can find the documentation - until now it needed to *not* find it,
which is weird.
(also it saves some useless lines)
Fixes#11270
Looks like the github actions image now has ninja installed.
This causes a failure; we effectively do
$ (
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo
)
$ make VERBOSE=1
[...]
cd build; cmake .. -G "Ninja" \
-DCMAKE_INSTALL_PREFIX="/usr/local" -DCMAKE_EXPORT_COMPILE_COMMANDS=1
Re-run cmake no build system arguments
CMake Error: Error: generator : Ninja
Does not match the generator used previously: Unix Makefiles
Either remove the CMakeCache.txt file and CMakeFiles directory or choose a different binary directory.
"make" fails because it runs from top-level, with GNUMakefile's logic to
use -GNinja if available. This is at odds with the direct cmake invocation,
which defaults to -G'Unix Makefiles'.
We shouldn't mix direct cmake invocation and the top-level Makefiles, so
run make from the build directory instead.
While at it, update some test invocations missed in 8d6fdfd9de
(Remove cmake "test" target, 2025-02-02). This should
help avoid missing test failure output in CI, see
https://github.com/fish-shell/fish-shell/issues/11116#issuecomment-2629406479
(cherry picked from commit b0be53ed6a)
The new cursor-end-mode "inclusive" (which is active in Vi mode) is causing
many issues.
One of them is because cancel-commandline wants to move to the end of the
command line before printing "^C". Since "inclusive" cursor mode prevents
the cursor from moving past the last character, that one will be overwritten
with a "^". Hack around this.
Closes#11261
(cherry picked from commit b08ff33291)
The new cursor-end-mode "inclusive" (which is active in Vi mode) is causing
many issues.
One of them is because cancel-commandline wants to move to the end of the
command line before printing "^C". Since "inclusive" cursor mode prevents
the cursor from moving past the last character, that one will be overwritten
with a "^". Hack around this.
Closes#11261
Running
fish_vi_key_bindings
fish_default_key_bindings
ought to maintain cursor shape, at least in the default configuration,
so let's do that.
Fixes 9ef76860e6 (Default Vi cursor shapes for insert/replace mode, 2024-10-26).
Looks like the github actions image now has ninja installed.
This causes a failure; we effectively do
$ (
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo
)
$ make VERBOSE=1
[...]
cd build; cmake .. -G "Ninja" \
-DCMAKE_INSTALL_PREFIX="/usr/local" -DCMAKE_EXPORT_COMPILE_COMMANDS=1
Re-run cmake no build system arguments
CMake Error: Error: generator : Ninja
Does not match the generator used previously: Unix Makefiles
Either remove the CMakeCache.txt file and CMakeFiles directory or choose a different binary directory.
"make" fails because it runs from top-level, with GNUMakefile's logic to
use -GNinja if available. This is at odds with the direct cmake invocation,
which defaults to -G'Unix Makefiles'.
We shouldn't mix direct cmake invocation and the top-level Makefiles, so
run make from the build directory instead.
While at it, update some test invocations missed in 8d6fdfd9de
(Remove cmake "test" target, 2025-02-02). This should
help avoid missing test failure output in CI, see
https://github.com/fish-shell/fish-shell/issues/11116#issuecomment-2629406479
Since commit 0627c9d9af (Render control characters as Unicode Control Pictures,
2020-08-29), we render control character in the commandline as "␇" etc.
They can be inserted via either history search, or bindings such as
bind ctrl-g "commandline -i \a"
That commit incorrectly assumes that the prompt is rendered the same way as
the command line (which goes through "ScreenData" etc).
This is wrong -- prompt text is written to stdout as-is, and a prompt that
outputs \t (tab) or \a (BEL) is valid. The wrong assumption means that we
overestimate the width of prompts containing control characters.
(For some reason, after switching from Vi insert to Vi normal mode, we seem
to get the width right which means the command line jumps around)
Let's revert to the old width computation for any prompt text.
Closes#11252
(cherry picked from commit 4d81cf8af4)
Since commit 0627c9d9af (Render control characters as Unicode Control Pictures,
2020-08-29), we render control character in the commandline as "␇" etc.
They can be inserted via either history search, or bindings such as
bind ctrl-g "commandline -i \a"
That commit incorrectly assumes that the prompt is rendered the same way as
the command line (which goes through "ScreenData" etc).
This is wrong -- prompt text is written to stdout as-is, and a prompt that
outputs \t (tab) or \a (BEL) is valid. The wrong assumption means that we
overestimate the width of prompts containing control characters.
(For some reason, after switching from Vi insert to Vi normal mode, we seem
to get the width right which means the command line jumps around)
Let's revert to the old width computation for any prompt text.
Closes#11252
For unknown reasons this assertion fails. This means that 1b9b893169 (After
reading corrupted history entry, keep reading older entries, 2024-10-06)
is not fully working. Go back to historical behavior for now.
Closes#11236
(cherry picked from commit 4f80e5cb54)
See f2dde229aa (Revert changes to restore cursor position after undo,
2025-03-05).
I think there are two problems with tmux when doing a final redraw of a
larger-than-screen commandline. One is easy to trigger independent of
f2dde229aa. The other is reproduced by the broken output in the tmux test
removed by that commit. Should root-cause them later.
Use a hack for now; this also happens to fix the broken output in tmux.
For unknown reasons this assertion fails. This means that 1b9b893169 (After
reading corrupted history entry, keep reading older entries, 2024-10-06)
is not fully working. Go back to historical behavior for now.
Closes#11236
Midnight Commander 4.8.33 knows how to read the CSI u encoding of ctrl-o
(which is the only key it reads while the shell is in control). But it fails
to when numlock or capslock is active. Let's disable the kitty keyboard
protocol again until mc indicates that this is fixed.
Closes#10640
The other issue talked about in that issue is an unrelated mc issue, see
https://github.com/MidnightCommander/mc/issues/4597#issuecomment-2705900024
