Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't move up while linewise visual mode #8

Closed
yo7 opened this issue Sep 29, 2015 · 10 comments
Closed

Can't move up while linewise visual mode #8

yo7 opened this issue Sep 29, 2015 · 10 comments
Labels

Comments

@yo7
Copy link
Contributor

yo7 commented Sep 29, 2015

On wrapped lines, I can't move up by hitting k while linewise visual mode (shift-v).

In the GIF below, I'm trying to move up on line 12 and keeping pressing k !! ..but I can't.

@t9md
Copy link
Owner

t9md commented Sep 30, 2015

Softwrap not work well in vim-mode.
Workaround is to disable it.

This is the limitation long existing from long ago.
I even wrote PR to official vim-mode but stopped.
It isnt easy to fix with minor change.

atom/vim-mode#785

@yo7
Copy link
Contributor Author

yo7 commented Sep 30, 2015

I didn't know vim-mode dosen't work well with soft wrap.

But in my case, it seems that the problem happens only with moving up. I can move down normally from wrapped lines.

@t9md
Copy link
Owner

t9md commented Sep 30, 2015

Yes, I already described issue on vim-mode.
I cant fix this issue very soon like I described above issue and related PR on official vim-mode.
This fix involve overall cursor movement handling change.

@t9md
Copy link
Owner

t9md commented Sep 30, 2015

Note, If you disable Line wrap and it fixed, then its same issue.
If you still can't move up even after you disable soft wrap, this is the bug I need to solve immediately.
Which is the result?

@yo7
Copy link
Contributor Author

yo7 commented Sep 30, 2015

I think it's the same issue. I can move up if I disable soft wrap.

@t9md
Copy link
Owner

t9md commented Sep 30, 2015

Ok thanks.
I didn't care this issue in vim-mode rerwiting process.
Now Im in the mood to start tuckling to solve this issue.
Thanks for reporting this and your GIF report is very explanatory I like it!

@yo7
Copy link
Contributor Author

yo7 commented Sep 30, 2015

Thanks. I'm looking forward to the progress!

t9md added a commit that referenced this issue Sep 30, 2015
Fortunately no spec broken.
@t9md
Copy link
Owner

t9md commented Sep 30, 2015

Currently cursor.moveDown(), and cursor.moveUp() move in relative position of screenPosition.
But when move 1 row up in screenPosition-wise, it still remain same bufferRow.
Movement in visual-mode is actually handled by the Motion::select and Motion::select only care its change of bufferRow.
So the movement not change bufferRow is equivalent to no-movement.

The issue user notice is or not is depending on selection.isReversed() state and the motion direction.
I think this issue only happen in visual, lineiwse interactive operation.
There is more consistent elegant way to solve this issue. but I don' want to affect other area of code in this time.
So fix should be OK at this time.

@t9md
Copy link
Owner

t9md commented Sep 30, 2015

After some evaluation and re-thinking, then I decide to release, I will close this issue, until then keep open.

t9md added a commit that referenced this issue Sep 30, 2015
Shrinking or expanding selection area is not matter, should always move
bufferRow-wise.
Now count like V3j work consistently.
As reverse version V3k.
t9md added a commit that referenced this issue Sep 30, 2015
explicitly set bufferRow rather than doing dirty adjustment done in
previous code.
@t9md
Copy link
Owner

t9md commented Sep 30, 2015

Released. v0.1.5.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants