Snippets Trigger while Typing in Tab Stops

[HackingHackers]

Snippets Trigger while Typing in Tab Stops

[savetheclocktower]

Nah, I wasn't trying to second-guess the decision; just offering some context.

I don't think this is an issue for autocomplete-snippets; I can't think of anything they could do to fix the underlying problem. The problem is that Tab functions as a way of selecting the default choice when the autocomplete menu comes up, but Tab is also the default keystroke for switching between tabstops. @HackingHackers describes a scenario where they want Tab to do the second thing, but it's doing the first thing.

Both autocomplete-plus and snippets want to use Tab, but they both want that key because that's how both features have historically worked, so I don't think it's a problem — just an inherent conflict based on design decisions. I can't identify one particular thing that would fix this issue; just a bunch of possible workarounds which each user has to decide between. (In my case I just disabled autocomplete-snippets. 😄)

[HackingHackers]

Thanks @savetheclocktower for your helpful suggestions. I've changed my "Keymap For Confirming A Suggestion" in the autocomplete-plus package and it works well.

[rsese]

Thanks for contributing!

We noticed that this looks like a duplicate of #152 so you can subscribe there if you'd like.

---

Because we treat our issues list as the Atom team's backlog, we close duplicates to focus our work and not have to touch the same chunk of code for the same reason multiple times. This is also why we may mark something as duplicate that isn't an exact duplicate but is closely related.

For information on how to use GitHub's search feature to find out if something is a duplicate before filing, see the How Can I Contribute? section of the Atom CONTRIBUTING guide.

[savetheclocktower]

I would not necessarily have considered this a duplicate of #152, but they're both illustrations of the problem of what to do when typing inside of a tab stop. In general, an editor shouldn't stop suggesting snippets simply because the user is already moving through another snippet's tab stops. I could be persuaded that it makes sense as a package setting so that people who feel strongly about it can disable the behavior globally.

In your example, @HackingHackers, you've got some options. You could change the “Keymap for Confirming a Selection” option in the autocomplete-plus package settings, so that Tab no longer automatically selects the first item just because it comes up as a suggestion. You could increase the delay before suggestions are shown. You could disable the autocomplete-snippets package altogether if you don't like it when snippets are offered as autocomplete suggestions.

I get why autocomplete-snippets offers up suggestions on partial prefix matches — it aids discoverability — but it'd be nice if that didn't also opt you into the “accidental default” behavior that's being described. Not sure how to thread that needle. But I'd argue that this is a problem with how autocompletion behaves, not with how the snippets package itself behaves.

[rsese]

Thanks @savetheclocktower - happy to defer to you on this because of all the work you've done with snippets 👍

So just to clarify, you think think this is an issue for https://github.com/atom/autocomplete-snippets? If so, I can transfer this issue over to that package.

[rsese]

Gotcha, thanks for the extra context 🙇 And thanks for the suggested workarounds, super helpful for folks that run into this conflict.