Visual downwards move with big count goes to end of line and new configuration options #27
Conversation
The lose of one column issue with 'virtualedit' wasn't related with the longest line as previously thought, but with the first line (smallest one) of selection, so changing it fixes now for real (hopefully) the bug of losing one column after moving. Using "range" in functions that didn't used visual selection was a problem when (a:firstline + count) greater than the last line so that range was deleted and replaced with <C-u> at the function calls. The name 'are_same_line' was really referring to a column, so it was renamed after 'are_same_cols' Create function to initialize configurations variables to its defaults.
The variable g:move_map_key can also be a dictionary to permit enabling/disabling of parts of the default mappings using the entries 'vertical' and 'horizontal' and its subentries 'normal' and 'visual'.
matze
left a comment
matze
left a comment
There was a problem hiding this comment.
I still lost the first column and since I enabled listchars I see another issue: in visual blocks with multiple lines and different line lengths, trailing spaces are inserted when shifting left and right.
| let l:distance = v:count ? v:count : 1 | ||
| let l:min_col = min([col("'<"), col("'>")]) | ||
|
|
||
| " Having 'virtualenv' set to 'onemore' fixes problem of one more movement |
There was a problem hiding this comment.
Someone seems to write a lot of Python code as well ;-)
There was a problem hiding this comment.
I still don't find a way to avoid inserting trailing spaces after a left/right move. But found that just removing the spaces after those operations is a possible solution. It is not exactly the same as not inserting them, because removing after an operation can also delete existing (possible wanted) spaces but this solution still will do right most times and could be configurable for those who don't want it.
2 participants
The lose of one column issue with 'virtualedit' wasn't related with the
longest line as previously thought, but with the first line (smallest
one) of selection, so changing it fixes now for real (hopefully) the bug
of losing one column after moving.
Using "range" in functions that didn't used visual selection was a
problem when (a:firstline + count) greater than the last line so that
range was deleted and replaced with at the function calls.
The name 'are_same_line' was really referring to a column, so it was
renamed after 'are_same_cols'
Create function to initialize configurations variables to its defaults.
The variable g:move_map_key can also be a dictionary to permit
enabling/disabling of parts of the default mappings using the entries
'vertical' and 'horizontal' and its subentries 'normal' and 'visual'.