Closed Aumnescio closed 1 year ago
thanks, should be fixed
Thanks!
But I'm afraid there is a new issue. I hope the below screenshot illustrates the problem well enough.
After reaching the indicated positions, pressing 'W' no longer does anything. However, moving a single character back will fix the next 'W'.
I suppose there is just some off-by-one error at the end of a line when there is punctuation character.
The 'b' motion seems to be working perfectly.
I feel like I fixed it by just removing the '+' from the pattern at line 82:
-- punctAtEnd = "%f[^%s]%p+$",
punctAtEnd = "%f[^%s]%p$",
I don't honestly fully understand the pattern syntax, and I'm not sure if this breaks something unforeseen to me, but it feels like it works very well.
Edit: Nevermind, its not really better. I think I got it to work for a second but now its broken again.
Edit 2: By removing the '$' from the "punctAtEnd" pattern at least makes the cursor land on the trailing punctuation, but then a lot more punctuation in other places are matched too.
-- punctAtEnd = "%f[^%s]%p+$",
punctAtEnd = "%f[^%s]%p+",
Also, the off-by-one error is happening with leading punctuation too, when the punctuation starts from the first column.
I can't reproduce the issue, it works fine for me. Looking at your screenshot, I suspect you might have virtualedit=onemore
turned on. Could you try turning it off?
btw, the %f[]
stuff is called the frontier pattern in lua, it's a little bit like \b
in js regex, but more flexible: https://www.lua.org/manual/5.4/manual.html#6.4.1
so "%f[^%s]%p"
basically means "a whitespace character, followed by a punctuation character, but only include the punctuation character in the match". It's a cool way of emulating regex lookbehinds in lua patterns :)
I use virtualedit = "all"
, and you're right, that does affect it. The end of line off-by-one error does not occur with virtualedit
disabled.
There is a off-by-one error in leading punctuation though. (With or without virtualedit
)
Edit: I suspect that disabling virtualedit
might just be hiding the bug? As it won't let the cursor go into that position past the line. Would love to be able to continue using virtualedit
, too. I've gotten used to it, its comfy and occasionally helpful.
okay, fixed the off by one from your screenshot.
In regards to virtualedit
, could you open a feature request for that? Then I'll try to get to it when I find the time. (The vim docs do mention though that virtualedit
might break plugins, since it alters the column count behavior.)
Sure.
Actually I think you fixed the issue. Even with virtualedit = "all"
, it seems to work just fine after this commit
Bug Description
When moving from one line of text to the next, the first word in the next line gets skipped. This only happens when the next line starts from the very first column (left edge).
Note: The "b" motion seems to behave correctly.The "b" motion skips over parentheses and brackets. Should I make a separate issue for that?Relevant Screenshot
Initial position:
Position after
The word "over" was skipped. The cursor should have jumped to:
To Reproduce
No response
neovim version
Make sure you have done the following