github-mirror/fish-shell
2
0
Fork 0
mirror of https://github.com/fish-shell/fish-shell.git synced 2024-12-19 05:13:44 +08:00
Code Issues Actions 4 Packages Projects Releases Wiki Activity
2dbaf10c36
fish-shell/tests/checks/tmux-multiline-prompt.fish

62 lines
1.6 KiB
Fish
Raw Normal View History

Avoid erasing OSC 133 prompt start marker with clr_eol For multi-line prompts, we start each leading line with a clr_eol. Immediately before printing these prompt lines we emit the OSC 133 prompt start marker. Some terminals such as tmux interpret make clr_eol delete such markers, hence prompt navigation is broken. Fix this by printing the marker only after clr_eol. The scenario where this triggers is quite odd. I haven't looked into why the problem doesn't exist if I remove the recursive repaint request. See https://github.com/tmux/tmux/issues/4183 Closes #10776
2024-10-13 00:19:13 +08:00
#RUN: %fish %s
Disable tmux OSC 133 prompt marking test also on cirrus' old alpine tmux -V prints "tmux next-3.4" there.
2024-10-13 03:04:27 +08:00
#REQUIRES: command -v tmux && ! tmux -V | grep -qE '^tmux (next-3.4|3\.[0123][a-z]*($|[.-]))'
Also refresh TTY timestamps after external commands from bindings Commit ba67d20b7 (Refresh TTY timestamps after nextd/prevd, 2024-10-13) wasn't quite right because it also needs to fix it for arbitrary commands. While at it, do this only when needed: 1. It seems to be only relevant for multiline prompts. Note that we can wait until after evaluation to check if the prompt is multiline, because repaint events go through the queue, see 5ba21cd29 (Send repaint requests through the input queue again, 2024-04-19). 2. When the binding doesn't execute any external command, we probably don't need to fix up whatever the user printed. If they actually wanted to show output and print another prompt, they should currently use "__fish_echo", to properly support multiline prompts. Bindings should produce no other output. What distinguishes external programs is that they can trigger this issue even if they don't produce any output that remains visible in fish, namely by using the terminal's alternate screen. Would be nice if we could get rid of __fish_echo; I'm not yet sure how. Fixes #10800
2024-10-21 16:25:13 +08:00
#REQUIRES: command -v less
Avoid erasing OSC 133 prompt start marker with clr_eol For multi-line prompts, we start each leading line with a clr_eol. Immediately before printing these prompt lines we emit the OSC 133 prompt start marker. Some terminals such as tmux interpret make clr_eol delete such markers, hence prompt navigation is broken. Fix this by printing the marker only after clr_eol. The scenario where this triggers is quite odd. I haven't looked into why the problem doesn't exist if I remove the recursive repaint request. See https://github.com/tmux/tmux/issues/4183 Closes #10776
2024-10-13 00:19:13 +08:00
isolated-tmux-start
isolated-tmux send-keys '
function fish_prompt
printf "prompt-line-1\\nprompt-line-2> "
commandline -f repaint
end
' Enter
Fix tmux-multiline-prompt test on some systems The fast input would race with tmux redrawing the screen, so sometimes the ": 5" is rendered twice.
2024-10-13 14:14:39 +08:00
isolated-tmux send-keys C-l ': 1' Enter
tmux-sleep
isolated-tmux send-keys ': 3' Enter
tmux-sleep
isolated-tmux send-keys ': 5' Enter
Avoid erasing OSC 133 prompt start marker with clr_eol For multi-line prompts, we start each leading line with a clr_eol. Immediately before printing these prompt lines we emit the OSC 133 prompt start marker. Some terminals such as tmux interpret make clr_eol delete such markers, hence prompt navigation is broken. Fix this by printing the marker only after clr_eol. The scenario where this triggers is quite odd. I haven't looked into why the problem doesn't exist if I remove the recursive repaint request. See https://github.com/tmux/tmux/issues/4183 Closes #10776
2024-10-13 00:19:13 +08:00
tmux-sleep
# Screen looks like
# [y=0] prompt-line-1
# [y=1] prompt-line-2> : 1
# [y=2] prompt-line-1
# [y=3] prompt-line-2> : 3
# [y=4] prompt-line-1
# [y=5] prompt-line-2> : 5
# [y=6] prompt-line-1
# [y=7] prompt-line-2>
isolated-tmux copy-mode
isolated-tmux send-keys -X previous-prompt
isolated-tmux send-keys -X previous-prompt
tmux-sleep
isolated-tmux display-message -p '#{copy_cursor_y} #{copy_cursor_line}'
Disable tmux OSC 133 prompt marking test for some tmux versions < 3.4 OSC 133 was added to tmux 3.4. Also fix the test on macOS where we do have 3.5a in CI; for some reason we get copy_cursor_y=6 there. I didn't investigate yet but at least that's not the same bug this test was made to fix.
2024-10-13 01:32:27 +08:00
# CHECK: {{[46]}} prompt-line-1
Refresh TTY timestamps after nextd/prevd This fixes a macOS-specific bug. See 390b40e02 (Fix regression not refreshing TTY timestamps after external command from binding, 2024-05-29) and 8a7c3ceec (Don't abandon line after writing control sequences, 2024-04-06). Fixes #10779
2024-10-13 13:55:31 +08:00
# Test that the prevd binding does not break the prompt.
isolated-tmux send-keys Escape
tmux-sleep
isolated-tmux send-keys M-left
tmux-sleep
isolated-tmux capture-pane -p | tail -n 5
# CHECK: prompt-line-2> : 5
# CHECK: prompt-line-1
# CHECK: prompt-line-2>
# CHECK:
# CHECK:
Also refresh TTY timestamps after external commands from bindings Commit ba67d20b7 (Refresh TTY timestamps after nextd/prevd, 2024-10-13) wasn't quite right because it also needs to fix it for arbitrary commands. While at it, do this only when needed: 1. It seems to be only relevant for multiline prompts. Note that we can wait until after evaluation to check if the prompt is multiline, because repaint events go through the queue, see 5ba21cd29 (Send repaint requests through the input queue again, 2024-04-19). 2. When the binding doesn't execute any external command, we probably don't need to fix up whatever the user printed. If they actually wanted to show output and print another prompt, they should currently use "__fish_echo", to properly support multiline prompts. Bindings should produce no other output. What distinguishes external programs is that they can trigger this issue even if they don't produce any output that remains visible in fish, namely by using the terminal's alternate screen. Would be nice if we could get rid of __fish_echo; I'm not yet sure how. Fixes #10800
2024-10-21 16:25:13 +08:00
# Test repainint after running an external program that uses the alternate screen.
isolated-tmux send-keys 'bind ctrl-r "echo | less +q; commandline \'echo Hello World\'"' Enter C-l \
isolated-tmux send-keys C-r
tmux-sleep
isolated-tmux send-keys Enter
tmux-sleep
isolated-tmux capture-pane -p
# CHECK: prompt-line-1
# CHECK: prompt-line-2> echo Hello World
# CHECK: Hello World
# CHECK: prompt-line-1
# CHECK: prompt-line-2>
Reference in New Issue Copy Permalink