Parinfer tabs defeat snippet tabstops

[mtnygard]

Snippets can have one or more tabstops embedded in them with '$1', '$2', etc. After expanding a snippet, tab is meant to cycle between these locations.

With parinfer enabled (at least in Indent mode, not sure about Paren mode) this tab cycling is overridden by parinfer inserting a literal tab.

[shaunlebron]

Thanks for reporting. I actually couldn't reproduce this. But we are about to add smart tab stops, and it's good to know that we have to avoid creating this problem in the future.

In a cljs file I typed defn followed by Tab:

so I'm not sure what the problem could be, but this is our keymap, which shows we're not overriding tab key yet: https://github.com/oakmac/atom-parinfer/blob/master/keymaps/atom-parinfer.json

[nilshae]

I just noticed this issue. Here is what it looks like for me, when I type defn followed by Tab

I also checked the Key Binding Resolver and can confirm that the snippets:next-tab-stop command is overridden by the parinfer:next-tab-stop command.

[shaunlebron]

@nilshae thanks for reporting! I was able to recreate the bug.

Cmd + . showed the keybinding resolver that confirmed the priority:

Wasn't able to find a quick solution:

• parinfer keymaps take priority over snippets keymaps because _____ ? (can't find this documented or discussed anywhere)
• snippets does not provide an inspectable state for knowing if a snippet is being expanded