All syntax completions add tailing dot, sometimes

[deathaxe]

If I edit a sublime-syntax file, type - meta_ and let it complete by ST the following line is inserted.

- meta_scope: .

While adding the tailing dot is useful, when completing scopes, it is annoying when completing normal sections.

EDIT: This does not happen always.

[FichteFoll]

I was able to reproduce this once a few days ago, but couldn't do it reliably. It must be some interaction with the "is_completing_key" flag remaining true after the scope name completion popup has been closed, even though it should be set to false in this case.

Would be nice if we had reproduction steps.

[deathaxe]

I think I got it now.

The SyntaxDefCompletionsListener sets is_completing_scope to True, if completions are available.

PostCompletionsListener expects the completion to always be submitted before resetting is_completing_scope to False. If any other event/command than hide_auto_complete, commit_completion or insert_best_completion cancels the pending scope completion, the state remain keeps True.

With the next TAB being pressed anywhere else in the document, which triggers insert_best_completion , PostCompletionsListener runs through and adds the dot.

From what I can see here, the only sense this fragile construct has, is to automatically add a dot and trigger the next completion, if the previous one is submitted. This prevents a user from adding another dot by hand.

The simplest solution therefore was to drop that piece of code. I don't have any problem with typing a dot manually to trigger the next completion popup.

The more advanced solution was to add all possible commands/events to PostCompletionsListener, which might indicate a pending scope completion from being canceled in order to reset is_completing_scope only.

Those commands are move, drag_select and maybe more. on_deactivated() might also be handled as it cancels completions.

[FichteFoll]

Right, I intended to do some testing on the situations where the completions popup was closed without the command being called, but never got around to to. move seems like an obvious choice, as does deactivating a view. move_to probably needs to be added as well, and jump_back and soft_undo. Basically anything that changes the selection without inserting text. I wonder if there is a better way to detect this.

[deathaxe]

I wonder if there is a better way to detect this.

Me, too.

I ran into a situation, when I pressed TAB after a scope with the tab being inserted followed by the dot again.

IMHO, this functionality is some kind of hack. I would drop it. It is just used to trigger the next completion panel by committing the current one. If something like that was the default behavior in all languages - ok, but struggle with it just in one syntax?

What would we loose? The only difference was to need to type the dot manually after submitting a completion. I even find the automatic completion popup annoying sometimes.

[r-stein]

In contrast to other syntaxes you usually add dot completions until you reached the main scope, so it is clear that you want to add an other one. However I agree that it is inconsistent. I personally have a keybinding for that case (with ChainOfCommands):

    {
        "keys": ["ctrl+."], "command": "chain", "args": {
            "commands": [
                ["commit_completion"],
                ["insert", {"characters": "."}],
                ["auto_complete", { "api_completions_only": true, "disable_auto_insert": true }]
            ]
        },
        "context": [
             { "key": "auto_complete_visible" },
             { "key": "selector", "operator": "equal", "operand": "source" }
        ]
    },

[deathaxe]

@r-stein: Damn, awesome. This is the perfect solution.

I just tried the following:

1. Drop the EventListener stuff
2. Add a macro which does the same as the "chain" command.

   [
   { "command": "commit_completion" },
   { "command": "insert", "args": {"characters": "."} },
   { "command": "auto_complete", "args": { "api_completions_only": true, "disable_auto_insert": true } },
   ]

3. Bind the macro to "."

    {
        "keys": ["."], "command": "run_macro_file", "args": {
            "file": "res://Packages/PackageDev/Package/Commit Completion.sublime-macro"
        },
        "context": [
             { "key": "auto_complete_visible" },
             { "key": "selector", "operator": "equal", "operand": "source" }
        ]
    },

If the completion panel is visible and I press '.', the result is submitted with the next panel being displayed. If the completion is submitted via TAB (i have complete_with_tab true) completion is submitted without any other popup being triggered.

Now I have the choice how to go on.

Cool.

[deathaxe]

Btw.: "commit_completion" seems to be missing in the command completions. Is it a built-in command which needs to be added to _builtin_commands_metadata.yaml?

[deathaxe]

Committed my solution as suggestion to #152

[FichteFoll]

I ran into a situation, when I pressed TAB after a scope with the tab being inserted followed by the dot again.

I think I have an idea why this could be happening.

IMHO, this functionality is some kind of hack. I would drop it. It is just used to trigger the next completion panel by committing the current one. If something like that was the default behavior in all languages - ok, but struggle with it just in one syntax?

What would we loose? The only difference was to need to type the dot manually after submitting a completion. I even find the automatic completion popup annoying sometimes.

Maybe we could use this to clarify our intentions. My intention with this feature was to

1. reduce the number of key presses required for inserting common scope names (notably the ., since I have a auto complete trigger for that anyway), and
2. expose scope naming conventions to new or inexperienced users by providing a set of generally recognized and mostly standardized completions for context-sensitive scope segment names.

Aside from a few solveable issues, I believe my intentions are met. I mean, it probably can be considered a hack, but it works well enough imo and is worth keeping.

Do you have any issues with the feature other than it occasionally misbehaving? If the misbehavior is the only issue, we should aim to solve that before we look to remove a feature. If it's something else, then please elaborate on it because as far as I can see you never mentioned that. It might be worth looking into the feature being more easily disabled than having to edit syntax-specific settings.

Is it a built-in command which needs to be added to builtin_commands_meta_data.yaml

It's certainly a built-in command, and if it's not in there it needs to be added.

[deathaxe]

To elaborate: I really like this feature as it really does what you intend - it helps pretty much. The whole scope completions are very useful - don't want to miss them anymore.

What I find a hack is the way it makes use of the EventListener stuff to add the dot and trigger the next completion. It doesn't look too deterministic especially due to the way the EventListener has to search the ViewEventListener first. I am not sure whether it is the intended way of using the API supported by the core devs. OK the variables are published in the sublime_plugin but I wouldn't consider them to be meant for global use.

Fixing the feature would be better then removing. That's for sure!

[FichteFoll]

A lot of API usage probably wasn't intended, but that's why the possibilities are so great. I'm sure something as InactivePanes, which modifies the selected color scheme and dims it to better represent the focused view wasn't intended, but it still works because of how generous the API is in some regards. I do believe that sublime_plugin.find_view_event_listener is entirely intended to be used by plugin developers however, since no code in sublime_plugin makes use of it and there is not need to differentiate between view event listeners based on their class type from a ST-internal point of view.

Anyway, it's unfortunate that there isn't a better or specifically designed way to to certain actions based on which completion items were selected, so we have to try and work around that, but it is generally doable. In fact, I just thought of yet another way that would allow this, but it's going out of scope for PackageDev as we won't need it.

I'm not opposed to solidifying PackageDev and removing hacky and potentially unreliable behavior so long as it still works correctly. Anyway, for more see #152.