Scenario 1
- double clicking on the
789abcdef entry with the mouse selects it as expected (see screenshot below)
- doing
ctr+c saves 789abcdef in the clipboard, as expected
- however, saying
copy this saves 789abcde in the clipboard (notice the missing f at the end)

Scenario 2 (same as scenario 1)
- dragging the mouse from the first character
7 up to the last character f in order to select it (see screenshot below)
- doing
ctr+c saves 789abcdef in the clipboard, as expected
- however, saying
copy this saves 789abcde in the clipboard (notice the missing f 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 saves 789abcdef\n in the clipboard (notices the extra newline at the end)
- saying
copy this saves 789abcdef in the clipboard (so includes the f but no extra space)

Scenario 4
- saying
copy last paint row 2 saves 789abcdef 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 saves 78 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 saves 7

Scenario 1
789abcdefentry with the mouse selects it as expected (see screenshot below)ctr+csaves789abcdefin the clipboard, as expectedcopy thissaves789abcdein the clipboard (notice the missingfat the end)Scenario 2 (same as scenario 1)
7up to the last characterfin order to select it (see screenshot below)ctr+csaves789abcdefin the clipboard, as expectedcopy thissaves789abcdein the clipboard (notice the missingfat the end)Scenario 3
Now at the moment, the way we select from cursorless behaves differently:
take last paint row 2selects one more character (notice the extra "space" at the end, even if there is no space on the line)ctr+csaves789abcdef\nin the clipboard (notices the extra newline at the end)copy thissaves789abcdefin the clipboard (so includes thefbut no extra space)Scenario 4
copy last paint row 2saves789abcdefto the clipboard so it saves the right thing.Solution / Idea
It seems we could solve it by:
copycommand, it seems we need to select one more character than what is shownThen we would have the following behaviours
take thiswill select the token since it is an empty selection. Can be a bit misleading but I can get used to itctrl+c, it saves78as expectedctrl+csaves7