Cannot always move down using j

[rhys-vdw]

May be a duplicate of: https://github.com/JugglerShu/XVim/issues/386 (I'm not sure what formatting is used with my source files, if you know how to check I can verify).

I can always move up to the previous line using k, but j will stop at seemingly random times when moving down. If I go into insert mode I can move using the keyboard.

[#]G is also broken, taking me to a line which is usually about half of what I type in. (ie. 640G takes me to line 320).

Other move commands are similarly broken, such as }.

I'm using XCode 5.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[JohnTheAppleSeed]

this is likely it, as currently xvim treats \r\n as two line separators.

You should check with the top of my buffers-refactor branch that uses a completely different strategy if it's a bit better (but it's probably not 100% fixed in it either). I'm meaning the top of this: https://github.com/JohnTheAppleSeed/XVim/tree/buffer-refactor

[rhys-vdw]

Keen to try it out, but I'm getting this error:

/Users/MonkeyDevBeta/Projects/tools/XVim/XVim/XVimWindow.m:100:24: error: unused variable 'e' [-Werror,-Wunused-variable]
    XVimEvaluator *e = [stack objectAtIndex:i];

I have zero Objective-C experience, so I have no idea how to overcome this. Should I be using different compile settings?

[JohnTheAppleSeed]

ah that's because you're building in Release and that 'e' is unused because the DEBUG_LOG below gets compiled away.

just comment out the offending line.

[JohnTheAppleSeed]

(or build in debug, or disable -Wunused-variable from the project settings).

[rhys-vdw]

Amazing! so far so good. The cursor did appear to stop once, but hasn't happened again yet. Should I report any further occurrences in this thread?

Thanks!

[rhys-vdw]

Okay, so { and } are still broken. The other errors I reported are fixed.

[JohnTheAppleSeed]

yeah, I've not fixed everything in that branch yet ;) but most of it. it's ongoing work, and it's not actually what I intended to fix in the first place, it's just a happy coincidence that the refactor makes CRLF work better (and eventually correctly).

[JohnTheAppleSeed]

Could you elaborate on what is broken with { } ? because I've set one file to use CRLF here, and it does seem to work fine.

I know I made even further changes in that branch, but not so many of them that it should have made any difference...

[rhys-vdw]

Sure.

{: Moves the cursor to the last character of the previous line. }: Moves the cursor to the last character of the current line, or if the cursor is already there, does nothing.

I can email you a file I'm working on if that would be helpful.

[JohnTheAppleSeed]

Hmm, seems you're right, it didn't do that yesterday for me, weird. let's fix that, shouldn't be too hard, I guess it's a matter of the code doing (index - 1) instead of going to endOfLine.

[rhys-vdw]

Great! Works like a charm. Thankyou for your great work.

Just discovered that dd to delete a line needs to be executed twice to remove a CRLF terminated line.

[rhys-vdw]

Another problem: I have a file where one line has two line numbers superimposed on top of each other, and I cannot move the cursor past this line. I will save the file out before I remove the line.

[JohnTheAppleSeed]

yeah I'm not that much surprised, I'm sure there are still several moves that are bogus with \r\n that's not my primary target to fix them, I just do because I'm migrating code that's slow into more efficent code, that happens to support \r\n better, that's all ;)

as of dd and similar movements, those are lower level code that I've not reached yet and won't for a while, so you'll have to suffer it for a while I fear.

[rhys-vdw]

No worries, just thought I'd let you know. I am more than satisfied with the new functionality. Would you like me to continue documenting these here as I discover them?

On Thu, Nov 21, 2013 at 6:32 PM, JohnTheAppleSeed notifications@github.comwrote:

yeah I'm not that much surprised, I'm sure there are still several moves that are bogus with \r\n that's not my primary target to fix them, I just do because I'm migrating code that's slow into more efficent code, that happens to support \r\n better, that's all ;)

as of dd and similar movements, those are lower level code that I've not reached yet and won't for a while, so you'll have to suffer it for a while I fear.

— Reply to this email directly or view it on GitHubhttps://github.com/JugglerShu/XVim/issues/530#issuecomment-28963139 .

[rhys-vdw]

Just letting you know, if I press pause in the debugger while your branch of XVim is installed (even if it's disabled), the entirety of XCode dies blaming XVim.

Do you get this behaviour?

[JohnTheAppleSeed]

No I don't, but I've added like tons of commits yesterday.

btw, for new problem on my branch, please new tickets ;)

and as of CRLF issues, yeah, list them if you find new ones, I'm pretty sure they'll go away while I continue the refactor, but it never hurts, it could decide me to prioritize one refactor over the other.

[JohnTheAppleSeed]

as of crashes, if you want to help, instal a debug version of the profile (by selecting a debug build rather than a Release one) and when XCode crashes, please paste the backtrace in a new bug, and I'll see if that's XVim's fault or not. Xcode when you use 3rd party plugins says it's tainted, but it doesn't mean it's Xvim's fault. Especially since in that branch I've reworked how we hook into Xcode and it's getting cleaner and cleaner, so I would expect (but for temporary regressions) more stability overall. Typically, we used to have a lot of crashers if you used assistant editors (splits), and that's fixed in my branch.

[rhys-vdw]

No worries. Running with a debug build now. I'll get back to you here with any crash traces.

On Fri, Nov 22, 2013 at 6:28 PM, JohnTheAppleSeed notifications@github.comwrote:

as of crashes, if you want to help, instal a debug version of the profile (by selecting a debug build rather than a Release one) and when XCode crashes, please paste the backtrace in a new bug, and I'll see if that's XVim's fault or not. Xcode when you use 3rd party plugins says it's tainted, but it doesn't mean it's Xvim's fault. Especially since in that branch I've reworked how we hook into Xcode and it's getting cleaner and cleaner, so I would expect (but for temporary regressions) more stability overall. Typically, we used to have a lot of crashers if you used assistant editors (splits), and that's fixed in my branch.

— Reply to this email directly or view it on GitHubhttps://github.com/JugglerShu/XVim/issues/530#issuecomment-29053313 .

[JohnTheAppleSeed]

dd seems to be fixed for me on top of my branch

[rhys-vdw]

dd is still broken for me with your latest commit.

I'll describe what happens.

When editing a CRLF line, dd will remove the text, but not the newline. (ie. it clears the line.) When I undo this (either with u or ⌘+z) the text is replaced - but the line now has TWO line numbers. They are superimposed over each other.

Executing J on this line removes the "new line", fixing the doubled line number.

Thanks. Just respond if you'd like me to test anything else.

[JohnTheAppleSeed]

better now?

[nikki93]

Same problem -- should I switch to the buffer-refactor branch?

EDIT: Just tried it, problem solved! So what's the relationship between this branch and the main one?

[JugglerShu]

The problem is about handling line endings. Your file contains \r\n as a line endings and XVim in master branch is not handling it correctly. It means it handles it as a 2 separate line endings and consider there are 2 lines.

[JohnTheAppleSeed]

The buffer-refactor branch is a significant rewrite of several things, and I've reworked how XVim counts lines, and it doesn't treat \r\n as 2 lines anymore, that's why :)

[rhys-vdw]

Sorry for the slow response. Even with your latest commit I'm still having the same problem with dd. I understand that CRLF is not your focus, but I am happy to supply you the source file I'm working on if you'd like to try it yourself.