Request: Add support for multiline quotes about targets.vim HOT 13 CLOSED

That sounds like a good idea.

There might be conflicts with seeking though. Suppose the cursor is on bar in this text:

string foo = "abc";
string bar = "def";

Pressing di" should not delete the surrounding degenerated multiline quote leading to this:

string foo = "abc""def";

But instead it should seek, find the single line quote and delete its contents def:

string foo = "abc";
string bar = "";

So my first idea would be to accept multiline quotes should only after seeking has failed. That would mean:

• If the current line contains at least two quote signs, it will work on a single line quote.
• If the current line contains at most one quote sign, it will look for multiline quotes.

Does this sound reasonable?

from targets.vim.

Oh, excellent point. I hadn't thought about that. However, I think you shouldn't put any intelligence in the logic and allow people to explicitly specify what they want to do.

For eg. consider

The quick "brown fox
jumps" over "the lazy dog"

Let's assume the cursor is on the v in over. From the context we know that "brown fox jumps" and "the lazy dog" are our multi-line strings. However, for the plugin it might be difficult to identify which characters are within the quotes and which ones outside it. And, depending upon whether we press, dil" or di" or din", we can control exactly what we want to delete.

Besides, in the example you gave, people can do din" to delete def. But if they actually want to delete the text between "abc" and "def", they won't be able to.

Btw, kudos on an excellent plugin 👍

from targets.vim.

I can understand your argument that there's always din" to avoid seeking, but your suggestion would break compatibility with stock Vim. Also I believe it would lead to the problem of degenerated quotes more often than it would be useful.

Do you really have multiline quotes reaching into lines that contain other quotes? I would argue that this should be very rare. And in my personal opinion that should be avoided. Give your multiline strings some room to breathe. 😉

Btw, kudos on an excellent plugin 👍

Thank you!

from targets.vim.

Oh, ok. Makes sense since you're trying to maintain compatibility. I was thinking from the perspective of making the quotes consistent with the other text-objects.

In that case, the plugin works well the way it is.

from targets.vim.

No, I certainly agree that it should be possible to work on multiline quotes in cases like this:

string multi = `line1
line2
line3`;

Executing the command `di`` from anywhere within the backticks should lead to this:

string multi = ``;

Only when there is a single line quote found in the current line, that one will be selected instead to avoid selecting degenerated quotes.

This would still maintain compatibility because multiline quotes only kick in after seeking has failed.

from targets.vim.

Quote and separator text objects now work over multiple lines. Also next and last modifiers search over multiple lines. Thank you for your feature request!

from targets.vim.

Hey, last week was pretty crazy at work and I wasn't able to keep up with the changes. I updated and tried it out.

"Am I a string?". Yes you are.
This is "not a multi-line string".
But "this is a
multi-line string". Also,
this "is not a multi-line string"

1. Starting out on T in This or the period on the same line, di" will find the string on the line and delete its contents which in this case is "not a multi-line string". This is what you explained earlier and that's fine.
2. If the cursor is on the m in multi-line on the same line, di" again deletes the same string which is again correct.
3. If the cursor is on the B in But on line 3, di" will delete *.But * The behavior here seems to be find the previous quote and the next quote and delete the text between them. This seems different than the behavior of 1. But thinking about it a little bit I realized that it's because it can't find a complete string on line 3, so it assumes that it's a multi-line string and acts accordingly. And this is completely acceptable.
4. Now, if the cursor is on i in is, and I press di", it still behaves the same as in 3. However, if I go to the m in multi on line 4 and press di", it deletes this is a multi-line string This seems a little weird as within the same string, starting from two different positions yields different results.

I understand that parsing strings and trying to understand the context can be extremely difficult. So how about doing the following instead?

• If di" is pressed, find a quote located before the cursor and find a quote located after the cursor and delete the things between them.
• If din" is pressed, find a quote after the cursor, find another quote located after this and then delete the text between them and similarly for dil". This, hopefully, should resolve any inconsistencies in the behavior.

Thanks for your support; let me know how I can help :)

from targets.vim.

Thank you for your great example! I agree that point 4 is behaving incorrectly. This is due to how seeking works right now. I will update this soon to address this issue. In short, seeking should look for a full match on the current line and abort if none is found. When this is in place everything should work as you described.

The behavior you described in your bulleted list is exactly how it works right now. It's just the seeking that moves to the quote in the third line because no quote is found to the right of the cursor.

from targets.vim.

Hi, I'm facing another issue. I decided to post it here itself instead of creating a new one since I thought it's similar to the behavior of quotes. But please let me know if you want me to open a new one instead.

Consider the following in C/C++

SomeFunction(
  MoreFancyFunction( arg1, arg2)
);

If my cursor is on the M in More, pressing vi) selects arg1, arg2 and not the arguments to SomeFunction as expected.

from targets.vim.

Good judgement. This is a related effect of the current seeking implementation:

As there is no opening brace found to the left, it falls back to select the next pair.

Instead it should try to select a pair immediately and only fall back to seeking after that failed.

from targets.vim.

Yes, I think that should work. However, I'd still argue that don't do the fallback.
This way the user is entire responsible for selection of the text. Also, it'll probably make life a little simpler for you since you wouldn't have to think of all such corner cases.

I hope I'm not bugging you too much.

from targets.vim.

That's a good point. Pair seeking is purely optional as stock Vim doesn't do it. I'll see how complicated it gets and might drop this feature if get's too messy.

I hope I'm not bugging you too much.

No, thank you for all your valuable feedback! :)

from targets.vim.

Ok I completely rewrote seeking and I'm pretty pleased with the results. Please check again and let me know if you can still find any issues.

Thanks again! 👍

from targets.vim.