-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Fixes #1193, #1350, #967: Fixes daw bugs #1549
Conversation
does this also handle this test:
This PR looks great! Thanks! |
I've only touched the "aw" (lowercase) object, but as the test case for "aW" you posted is the same as the one for "aw" I fixed, I imagine the fix should be similar. I'll check it out. |
Want me to merge this and make that a separate issue? |
Nah I'm almost done with the bug fix. |
Actually, could you? I found some other bugs with "aW" that seem to be a bit harder to fix. Namely, tests like
result in everything being deleted. I can make the new issue(s). I'm actually surprised nobody has reported these bugs. I guess people don't really use the "aW" object much? |
As I was working on the "aw" object, I thought I would fix the other related bugs.
It'd be ideal if I didn't need to special case this, but from thinking about it, it does seem like it's a special case. Normally, when you daw with a "." right at the end, you also want to delete all the whitespace on the left of the word until you reach another word. In this scenario, however, you want it to stay in the same place.
I was working on a complete rewrite of the 'aw' object based off "boundaries", but decided that it was overengineering. However, while writing it, I came some more cases where our behavior doesn't align with vim. I'd like some feedback on whether those cases are worth fixing (imo, vim does some very bizarre things in some of these cases).
becomes
|one