All the other copy commands not only set the system clipboard, but also
set the tmux buffer to have the selection. For consistency, the copy
pane PWD action should behave the same way.
Apparently clip.exe doesn't work properly with WSL 2: It doesn't exit when EOF is reached on STDIN. This is a workaround by making sure that SIGPIPE is sent on EOF.
With the current implementation, if your shell is :
$ echo 'foo'
your cursor is at the end of the line, it will copy `$ echo 'foo'` on
tmux 2.4, and `echo 'foo'` on tmux 2.3 and below.
This normalizes the behavior on both versions so that only `echo 'foo'`
is copied
This addresses a tmux/bash issue that occurs for commands with multiple
lines. When 'C-e' is pressed in a command, this confuses tmux so
newlines are yanked in copy-mode.
When a user wants to line-yank multiple-line command he is better off
when newlines aren't yanked.
This commit reliably enables this.
Fixes#13
When the current command line is the last/bottom line in the scrollback
buffer, then jumping to the bottom of the buffer:
- stays in the current line
- goes to the start of current line
This is, of course, not desired bc we get the wrong result.
The fix is to just 'down' movement in copy mode. The down movement
preserves cursor column.
Fixes#11.
If 'yank line' is tried when running in a remote shell (ssh) with
latency, the result will not be good.
I consistently yanked only the *last character* in the command.
This is due to latency: yank line feature works faster than the cursor
is moved in the remote shell.
To fix this issue, if remote shell is detected (ssh or mosh) wait time
is added to compensate for network latency.
Wait time of '0.2s' seemed to give good results, but at the end, wait of
'0.4s' is set. This should be more robust and allow for even greater
latency (I only wonder how could anyone work with that).