selection is off by one when selecting char by char starting from multi-cursors with one-char selection

[dermetfan]

Description of the problem or steps to reproduce

Sorry about the title, that's the best I can describe it.

Specifications

Commit hash: c31613b
OS: NixOS
Terminal: alacritty

[JDurstberger]

I would like to have a go at this, unfortunately I am having a really hard time to
reproduce exactly the scenario in you video.
Could you add steps-to-reproduce?

I guess this is just because I have not used micro that much yet :(

Figured it out:

1. create file with text:

config.xsession.windowManager != "Something"
config.xsession.windowManager != "Something"

2. postition cursor on first .
3. SpawnMulticursor (Alt+n)
4. Skip first Multicursor (Alt+x)
5. Select text to right or left (Shift+left/right)

Interesting enough this does not occur when you first move the cursors around and then start selecting text.

[sum01]

It's because the first cursor isn't technically highlighting the . yet, while the spawned multi-cursor seems to auto-highlight what it spawns on. This results in a 1-off, as the first Shift-right will highlight the . on the first line, but the second line is already highlighted, and thus it moves to the next char.

I tried it on nightly 1.3.5-17 and it still happens.
Simple 2-liner to test on:

aaaaa.dddddd.zzzzz
aaaaa.dddddd.zzzzz

[dermetfan]

You can circumvent this by highlighting the first . before spawning the first cursor, though maybe that should be done automatically.

[sum01]

I think a better fix for this would be to have the SpawnMultiCursor duplicate the current cursor's selection, instead of auto-selecting what it spawns on. So if the cursor is in place without selection, it merely spawns more cursors without selection.

[janxkoci]

maybe that should be done automatically

I think by default the selection is supposed to work on words, so it still shouldn't select the dot. Instead I agree with the proposal of @sum01 above.

Taking the two-liner example above and pasting it to Sublime text I can see that placing a cursor on any side of the dot and pressing Ctrl+D would select the respective word on the given side of the dot, and not the dot itself. I think this will be the expected behaviour by most users. (Well except maybe R users, who will correctly expect the whole line to be selected, as dots are not word separators in R, but rather a valid - and common - part of function and variable names. But that is for syntax-specific settings to worry about...)

[dmaluka]

I can still see this issue on the newest master.

From my perspective, the issue is that it doesn't automatically select the dot at the initial cursor, but does automatically select it at next cursors. It should behave consistently and either automatically select both, or neither.

Actually, from the code it looks like it does try to auto-select the initial cursor. So just need to debug why doesn't it work.