Open
Description
Scenario 1
- double clicking on the
789abcdef
entry with the mouse selects it as expected (see screenshot below) - doing
ctr+c
saves789abcdef
in the clipboard, as expected - however, saying
copy this
saves789abcde
in the clipboard (notice the missingf
at the end)
Scenario 2 (same as scenario 1)
- dragging the mouse from the first character
7
up to the last characterf
in order to select it (see screenshot below) - doing
ctr+c
saves789abcdef
in the clipboard, as expected - however, saying
copy this
saves789abcde
in the clipboard (notice the missingf
at the end)
Scenario 3
Now at the moment, the way we select from cursorless behaves differently:
- saying
take last paint row 2
selects one more character (notice the extra "space" at the end, even if there is no space on the line) - PROBLEM: doing
ctr+c
saves789abcdef\n
in the clipboard (notices the extra newline at the end) - saying
copy this
saves789abcdef
in the clipboard (so includes thef
but no extra space)
Scenario 4
- saying
copy last paint row 2
saves789abcdef
to the clipboard so it saves the right thing.
Solution / Idea
It seems we could solve it by:
- selecting one less character in visual mode (to mimic what happens when double clicking). It will also render better visualy?
- then, when we issue a
copy
command, it seems we need to select one more character than what is shown
Then we would have the following behaviours
- if we move the cursor in normal mode (with mouse or keyboard or going up/down/left/right with voice), it is the same as not selecting anything, then the cursor will actually be on top of a character (and not between 2 characters like in insert mode). And so saying
take this
will select the token since it is an empty selection. Can be a bit misleading but I can get used to it
- if we select 2 characters with the mouse, and issue
ctrl+c
, it saves78
as expected
- in order to select a single character with the mouse, it is actually doable by selecting 2 characters and then dragging back to 1 character. Then issuing
ctrl+c
saves7