When writing Lua code, autocomplete stops working after if once then has been typed. This means that whenever I go back and add more code to an if-statement’s condition, I get no autocomplete unless I delete the then and retype it afterward.
This happens regardless of the linter being active, and regardless of using parenthesis (parens are option in Lua).
Thanks!
The default package provides a Completion Rules.tmPreferences file which disables completions if a line contains then.
Maybe we should remove then from the list.
Hey Deathaxe,
Thanks for the quick reply!
This definitely seems like something that should get removed. From my perspective, this definitely seems wrong. I can’t think of any case where I’d want that behavior and I’ve been using sublime for Lua for years. I’d be happy to give it a test if there’s a way I can make the change locally, and report back after a few days of use to make sure that doesn’t introduce a different problem.
Is this something I can change locally? I don’t see a Completion Rules anywhere inside \AppData\Roaming\Sublime Text 3…
Something to note is that the cancelCompletion setting here stops the autocomplete panel from opening up automatically, but completions are still available; you can press Tab to insert the best completion or cycle between them, or you can can press Ctrl+Space (or Alt+/ on Linux) to open the panel manually):
That said, it’s possible to try the change out locally if you want to. The reason you don’t see the file that you’re looking for is that the packages that ship with Sublime are stored as packed packages in a location outside of the Data directory, since they’re common to all users on the machine that use Sublime.
The easiest way to effect the change is:
prvo and select the PackageResourceViewer: Open Resource commandLua (the package), then Completion Rules.tmPreferences (the file)That will open the file and show you the following:
<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
<key>scope</key>
<string>source.lua</string>
<key>settings</key>
<dict>
<key>cancelCompletion</key>
<string>^.*\b(then|end|do|else)$</string>
</dict>
</dict>
</plist>
You want to either erase the inner parts of the settings dict to remove that setting completely, or if you prefer you can modify the setting to some other regular expression (depending on your testing, etc). An example of the former is:
<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
<key>scope</key>
<string>source.lua</string>
<key>settings</key>
<dict>
</dict>
</dict>
</plist>
Once you make the change, save the file. That will create an override that makes your edited version of the file be usef instead of the one that ships with Sublime. As soon as you save the file the changes will be reloaded, so it should start working for you right away.
What this is doing is creating a folder named Lua (named after the package) in your Packages folder, then storing your modified version of the file there.
This override will remain in effect as long as that file is there, including if you upgrade or reinstall Sublime. If an official fix is made, you’ll want to remove your modified version of the file so that it stops blocking the packed version. The OverrideAudit package will give you a warning if the underlying package is updated so that you can verify if you still need your change or not.
Thanks for all the information OdatNurd. I never really understood how to interact with packages until you explained how to find them, and how overriding works. That all makes a ton of sense. I made the change locally and it working great.
Deathaxe. Thanks for committing the fix! I’ll be sure to remove my override as soon as it’s available.
Thanks again for the fantastic and quick support!