path completion: support code completion inside an existing path until next whitespace

[aeschli]

Testing #44460

Version 1.21.0-insider
Commit 9a04587
Date 2018-03-01T06:47:39.037Z

• create foo.html, bar.html in a folder
• in `foo.html' have

<a href="./boo.html"

and do code completion after b.

-> should show bar.html as a proposal. Accepting the proposal should replace /boo.html with ./bar.html

This would be consistent with other html completions, e.g. set the cursor inside href and pick hreflang

[octref]

This would be consistent with other html completions, e.g. set the cursor inside href and pick hreflang

I had no idea of this feature. I'll look into supporting it for path completion for March.

[octref]

Actually that's a rather strange behavior that I don't think many other languages support.
Do people use it?

I do see CSS supports it well. I think if we were to have this as a standard behavior of completions, other languages should have consistent completion behaviors with it too.

[octref]

Looping in @mjbvz to get some insight from TS perspective.

[aeschli]

It's replacement vs insertion which is currently different for each language.
It HTML it's consistently replacement, IMO we want to stick with it.

[octref]

But I found this case to be very common too (echoed by @mjbvz):

Let's say I have a line

<script src="./vendor/foo/js/foo.js"></script>

And I have decided to move vendor to static folder, so the line needs to be changed to

<script src="./static/vendor/foo/js/foo.js"></script>

I wish I can move my cursor to after ./, do a completion, and choose static.

[aeschli]

In Eclipse we had a modification key (Ctrl or Alt) to switch between insertion and replace mode on demand.
We don't have it in VSCode. The workaround is to add a space or complete before the '/'.

[octref]

OK, so the feature become two things:

1. Offer completions based on the path before cursor (if the value before cursor is ./b, use ./ as the path to get completion items (also with b as filter characters?)
2. Instead of replacing everything towards the end of the attribute, use whitespace as a heuristic to calculate the replacement range, so it becomes the range from previous / position to either a whitespace or the end of attribute value.

1 is easy but for 2 I'm wondering how can I possibly deal with folder with whitespaces.

[aeschli]

Yes, 1. is correct. The last segment has no meaning for the proposals. FIltering is always done in the UI, using the UI's heuristics (fuzzymatch, camelcase...).

Actually what we complete are URLs and URLs must not have spaces. So to be correct, we should URL encode the file name (so that spaces use become 20%).
Given that, extending the range until a whitespace is found makes sense.
Lets have test cases for all that.