-
-
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
Implement additional text object commands #450
Conversation
To be clear, any and all feedback, no matter how minor or how major, is appreciated. I'd like to continue to contribute to the project, and I'd like to write idiomatic TypeScript, but I'm nearly certain this code is not optimal as-is. |
stackHeight++; | ||
} | ||
|
||
if (char === this.pairings[charToMatch].match) { | ||
if (char === toFind.match) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of the callers of this function (this.nextBracket
) are already passing an object from this.pairings[char]
as the toFind
, so I think this is more correct. This also allows callers of this function to use characters that don't exist in this.pairings
, such as "
and '
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch! That must have been vestigial.
I would also suggest adding ' and " back to our pairings
list, perhaps adding a flag so that we don't match them with %.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This pairings
bothers me a lot when I implement MoveToUnclosedRoundBracketBackward. And the first hack I did is moving the bracket matching to a separate method called nextBracket
in b0a2038 but now it seems nextBracket
is no longer a good name as we might match quotes. Something called nextPairedChar
looks better to me.
Besides, your PR is good enough for this fix but you may want to take a look at all text objects commands, maybe we can make this abstract class MoveToMatchingBase
more generic?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I plan on making the class generic enough so that it can handle a<
, i)
etc (and may add them to this PR now that I have some better confidence I'm going down the right track).
Will come up with some better naming, and add '
/"
into pairings
1ca5c4e
to
5a50f21
Compare
This is looking good so far, and I'm pretty hyped to have this functionality! 😀 The only thing I'd suggest to change would be how you use inheritance to share the matching functionality with |
Ok, I think I have most of what I need to get this PR to a merge-able state. One open question that I left at the top: is there a way to return something to indicate that this didn't match, so that for example an unsuccessful |
8f6fa0d
to
80a876e
Compare
Needs a few more tests, but I think this is almost there. |
80a876e
to
b40fb99
Compare
b40fb99
to
98ac31d
Compare
Ahh. Your question about a failed ci" is actually something I haven't quite got around to yet. For now could you just mark it with a TODO and return a range of length 0? It's not perfect, I admit. |
|
||
public async execAction(position: Position, vimState: VimState): Promise<Position> { | ||
const text = TextEditor.getLineAt(position).text; | ||
const charToMatch = text[position.character]; | ||
const toFind = this.pairings[charToMatch]; | ||
const toFind = PairMatcher.pairings[charToMatch]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about making these static methods rather than instance methods? There isn't really any associated state we need to carry along, is there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, I originally had it being stateful (where you initialized a PairMatcher with the character), but that seemed wasteful as well. Wasn't sure about preferences for static/non-static. Will change to static.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. I prefer static to indicate stateless, though unfortunately there are places where I don't adhere to that.
By "return a range of length 0" do you mean an IMovement with the same start/stop? I tried that, but it still didn't "cancel" the insert/change. |
98ac31d
to
0c44908
Compare
Yeah, there's no way to cancel, so we just return an empty selection. It's not great- we'll have to fix it later. |
Yea, I understand that there isn't currently a cancel. Maybe there's a bug in my code, but when I return a |
0c44908
to
8f523d6
Compare
8bacbcd
to
f82f8c8
Compare
@sectioneight these commands were on my list before I worked on Window/Tab and CJK stuff. Good to see you can help on this, they are quite important. |
2d02f18
to
f051e79
Compare
Disregard my previous comment, |
f051e79
to
42c71e1
Compare
NOTE: There is one limitation to this that I just discovered. If you have:
and you have your cursor on the closing I don't consider it a blocker, but if there's an obvious way to fix this I'd be open to doing it now. |
Ahh, yes. When I initially said that i" and i' would be harder, this was my concern. I'm not convinced there's an easier way than parsing the entire line. (Oops, fat fingered the close button!) |
We are using I'd like to see this PR merged as I don't want to see it Open for too long. But just make sure we don't release this feature without a fix, people are likely to run |
To be clear, the limitation is only on the closing quote -- |
My current thinking: handling quotes is going to take some more work, and I want to balance making forward progress with not introducing buggy code. I'm going to remove the single- and double-quote functionality from this PR and work out the proper algorithm to handle them (since it's really a different problem than handling the rest). That way we can (hopefully) get this PR merged this weekend and I'll spend some more time working through the edge cases of properly handling quotes. |
Ok, PR updated, I think the functionality contained is complete (although I marked it as "partially supported" on the roadmap until at least one other person tries it out and says it works). |
fe239b4
to
58bd2b5
Compare
This allows for e.g. 'ci(', 'ca"', 'di<' commands.
58bd2b5
to
5dd396c
Compare
Awesome work! This looks good to me. |
This allows for e.g. 'ci(' and 'da<' commands.
Fixes #449