UVviewsoft forums

Testing...

For Shift+End, on any line, the first press now selects from the current position, to a horizontal position which seems to be random, but it turns out that it is the position of the end of the first line in the file, for example in one file it may be column 54, and in another file it may be column 14. This happens on any line in the file, so on shorter lines it may be many columns past the end of the line, while on longer lines it may be the middle of the line. The second press then moves to the correct end of line position.

For Shift+Home, starting from a position which may the end of the line, or may be the middle of the line, pressing Shift+Home correctly selects to the left edge of the window, but the caret itself remains in its starting position (middle/end of line), instead of moving to the left edge. To be consistent, the caret should move to the left edge of the selection, in the same way that it moves to right edge of the selection for Shift+End.

Further, after Shift+Home makes the selection to the left edge (but the caret remains at the right edge of the selection), then Shift+Right shrinks the selection one column from the left edge (where the caret should be, but isn't).

Also, there is the question of whether Shift+Home should move to the left edge of the window, or whether it should move to the first character on the line, and then move to the left edge of the window on the second press, the same way Home by itself works when there is no selection? The same question applies to Shift+End moving to the end of the line--should it go to the last character including spaces, and then go to the last non-space character on the second press, like End by itself does when there is no selection?

In ConTEXT, Shift+Home follows the pattern of Home by itself, that is it moves to the first character on the first press, and to the left edge on the second press. I think this is likely the proper behaviour; and likewise for Shift+End.

For Shift+Ctrl+Home, the rectangular selection is correctly made to the beginning of the file; however, the (now multiple) carets remain at the starting column, rather than moving to the left edge (the same problem as with Shift+Home).

For Shift+Ctrl+End, it is the same problem, where the rectangular selection is correctly made, but the now multiple carets remain at the starting column, rather than moving to the left edge.

And actually, this same problem exists for Shift+Left and Shift+Ctrl+Left, where the selection is created to the left, but the caret(s) remain in the starting column.

So we are much closer... just a few little niggles left to work out.

>pressing Shift+Home correctly selects to the left edge of the window, but the caret itself remains in its starting position (middle/end of line)

I don't see this here. for me carets are at the column 0. I tried with empty user.json too. Try with empty user.json, repeated this bug? if no, find the option culprit.
if repeated on empty config, make sure you activated 'keybd column selection without Alt-key'.
if it was activated, give me exact small file, give me exact steps to repeat.

Okay, will do soon as I can... maybe tomorrow.

I fixed all issues (except that one i cant repeat)
https://github.com/Alexey-T/CudaText/di ... t-16430480

for Shift+Home/End to jump to indented position, I reused old options
"key_home_to_nonspace"
"key_end_to_nonspace"

Okay, did some very quick testing, and the only remaining issue I saw (besides the one you couldn't reproduce), is that, while Shift+Home now, goes to first character, then to left edge, and back and forth (that's exactly what it should do); Shift+End just goes to the last non-space character.

But I saw your next post, and checked my user.json, and I see that I have:
"key_home_to_nonspace": true,
"key_end_to_nonspace": false,
so that probably explains it.

The other issue remains, so I restarted with no user.json, and that problem disappeared.

So it tentatively seems as though all is good with your code, and I really appreciate it!

Out of time for today, but as soon as possible will work on finding what in the user.json is causing that issue, and also test changing key_end_to_nonspace to true. If you have any thoughts as to what lines in user.json to try changing/removing, it would help, since there are so very many lines that it would take an extremely long time to test removing them one by one, and restarting each time.

Maybe one of "key_xxxx" options.

It's "carets_primitive_column_sel": false

Investigating.

Seems fixed it.
https://github.com/Alexey-T/CudaText/di ... t-16439793
test pls.

don't say thanks, better 'spread the word' pls.

Tested every aspect of keyboard-column-selection that I could think of; no issues found.

This feature seems ready for prime time. Great!