on_query_completions behavior with leading spaces

[rwols]

I'm unsure if this is intended behavior, but I find it undesirable behavior.

Summary

When the unicode string of the completion trigger has a leading space, the inserted text eats the space to the left of the cursor.

However, when there is no space to the left of the cursor, that character remains intact.

Expected behavior

Trim leading spaces of the completion trigger before processing it.

Actual behavior

The completion trigger including its leading spaces are used to replace text to the left of the cursor.

Steps to reproduce

1. Copy this python script to Packages/User:

import sublime_plugin


class SpacesBehavior(sublime_plugin.EventListener):
    def on_query_completions(self, _, __, ___):
        return ([[' space', '${1:suddenly my space to the left is gone}']], 0)

2. Save it.
3. Indent the cursor a little bit.
4. Type the word "space".
5. Select this completion.
6. A space character to the left is now removed.

To showcase another situation:

7. Type the word foo.
8. Type a dot . as if you're accessing a member of the structure foo.
9. Select the space completion.
10. Observe that the space in front of the completion trigger is ignored now.

Environment

Mac OS 10.13, Build 3175, 64 bit

Related: sublimelsp/LSP#368

[FichteFoll]

This seems okay-ish to me. The space character in the completion is seemingly considered part of the prefix when completions are queried. In the first case, the prefix space is there, so it will be removed upon selecting the completion. In the second case, the prefix space is not there, but through fuzzy matching the completion can be matched anyway and the entire matched prefix is replaced with the completion.

Now, you could argue that special characters (e.g. word separators) should never be part of the prefix, because they perform badly with it anyway, but then you they could never be matched in the tab trigger as well.