Sublime Forum

Are API-injected completions working in ST3?

#1

Hi all,
I was wondering whether anyone had tried writing API-injected completions under ST3, and whether they’d had any luck. I ask because HTML completions don’t seem to work in build 3022: in ST2, typing “<” gives me a fuzzy-matched list of tags, and in ST3, it doesn’t do anything; and since I know they’re handled by an on_query_completions call, I thought I’d check before I went nuts trying to do it myself. For what it’s worth, I tried removing all my packages and testing it again—still nothing, so it’s not being interfered with by anything I’ve already done or installed.

Thanks in advance for the help!

0 Likes

Dev Build 3022
#2

It looks like the html_completions.py has been modified (from ST2). If you type “<c” then manually bring up the auto completion list, they appear properly.

Also, there is the following

if prefix == '': # need completion list to match return (], sublime.INHIBIT_WORD_COMPLETIONS | sublime.INHIBIT_EXPLICIT_COMPLETIONS)

When you enter “<”, the prefix is still empty, which explains why nothing is shown.

0 Likes

#3

HTML completions are only displayed after the first character is entered. This allows the completion list to display either only uppercase or only lowercase tags depending on what you enter.

0 Likes

#4

But after you enter the first character, aren’t you back in the text.html scope, so the autocomplete pop up doesn’t trigger? I did a quick test and I can manually bring up the auto complete options, and everything is populated fine, so I know it’s there. Well, that’s the behavior I see on Windows 7 x64. I haven’t tried it in anything else.

Edit:
Forgot to mention this. I also added “text.html” as an “auto_complete_selector”. By doing this, the pop up appears as expected. This was more of a sanity check than anything else.

0 Likes

#5

Alright, thanks; glad to know that it’s just a triggering change rather than an API change. Seemed worthwhile to check before I did anything myself to break it!

0 Likes