autocomplete-plus icon indicating copy to clipboard operation
autocomplete-plus copied to clipboard

Autocomplete suggestion window interferes with snippets

Open helarqjsc opened this issue 9 years ago • 15 comments

Referencing TypeStrong/atom-typescript#433 The problem seems to be related to this packages, but if not, please, tell me where should I post it.

Basically, whenever I'm typing a snippet, autocomplete suggestion window appears and if I press <Tab>, autocomplete will insert its own stuff and the snippet will be ignored. I can currently bypass this problem in two ways:

  1. Type a snippet (e.g. cc), press <Esc> to close autocomplete window, then press <Tab> to insert snippet. It's quite inconvenient to do it every time.
  2. Use longer snippet names, so autocomplete won't match anything. Even more inconvenient, also long snippet shortcuts kind of defeat the whole purpose of snippets.

Can this be fixed? Maybe snippets can be inserted in the autocomplete suggestion list, the same way it's done in Sublime Text?

helarqjsc avatar Jul 03 '15 11:07 helarqjsc

Related : https://github.com/atom/autocomplete-snippets/issues/46

basarat avatar Jul 03 '15 11:07 basarat

I just switched from Sublime Text and this behavior is madness. Atom users either have to sacrifice snippets or sacrifice autocomplete.

jprichardson avatar Jul 24 '15 17:07 jprichardson

@jprichardson you can remap your confirm key to just enter with a setting in the settings view:

screen shot 2015-07-24 at 10 46 24 am

Also, are the snippets not in the autocomplete suggestion list? What snippet are you trying to get to?

benogle avatar Jul 24 '15 17:07 benogle

@benogle I think the ideal fix would be that when a snippet has been invoked (while still in snippet mode - with snippet parameters), that the autocomplete list should temporarily disable [TAB] as [TAB] is used to move to the next snippet parameter.

For example:

If I invoke a function snippet, and then name the function, if the name partially matches any other previous variable names (in autocomplete), a tab press should take me to the next parameter of the snippet and not autocomplete the variable and not autocomplete the variable name.

So...

var runTest = 'something'

// 'fun' snippet invoked
function runTest(arguments) { // <--- if I type, 'run' and press TAB, it should go to `arguments`
// since it's still in snippets mode, but it doesn't, it autocompletes to `runTest`.
  // body
}

Does this make sense? Sorry if it doesn't, I'll try to add clarity where I can.

Remapping to enter is a short-term fix, but when I'm not invoking snippets, tabs to autocomplete variables should still work.

jprichardson avatar Jul 24 '15 18:07 jprichardson

but when I'm not invoking snippets, tabs to autocomplete variables should still work.

Is this not inconsistent? I think it might be super strange to sometimes complete autocomplete things, and sometimes do snippet things even when the suggestion list is open.

Right now, I'm leaning toward moving the default from tab & enter to just enter so snippets are on a totally different binding.

benogle avatar Jul 24 '15 18:07 benogle

Is this not inconsistent? I think it might be super strange to sometimes complete autocomplete things, and sometimes do snippet things even when the suggestion list is open.

I'd expect autocomplete to be lower priority if in snippet "mode". Correct me if I'm wrong, but isn't this how other editors sublime / Visual Studio handle this? Not sure about Idea or Vim.

jprichardson avatar Jul 24 '15 19:07 jprichardson

Is this not inconsistent? I think it might be super strange to sometimes complete autocomplete things, and sometimes do snippet things even when the suggestion list is open.

Right now, I'm leaning toward moving the default from tab & enter to just enter so snippets are on a totally different binding.

From a UX perspective, you may have a point. I feel like I'm so use to the overloaded behavior ([TAB] serving a different purpose whether in snippet mode or not) from Sublime that I'm very biased. I'd really love to know what other editors do.

jprichardson avatar Jul 24 '15 19:07 jprichardson

I notice snippets are now listed as top results for autocomplete-plus, but this issue is still very relevant in that tab autocompletion interferes with the default tab for snippets:next-tab-stop keybinding.

I'd expect autocomplete to be lower priority if in snippet "mode". Correct me if I'm wrong, but isn't this how other editors sublime / Visual Studio handle this? Not sure about Idea or Vim.

I can confirm, at least for Sublime, both tab and enter confirm autocomplete suggestion normally, but when in snippet mode with tab-stops, tab is handed over to the snippet engine, and enter confirms an autocomplete suggestion.

Is this not inconsistent? I think it might be super strange to sometimes complete autocomplete things, and sometimes do snippet things even when the suggestion list is open.

It may not be consistent, but it feels great in Sublime. Normally I want autocomplete priority. But when tab-stopping through snippet insertion points, all I'm thinking about is completing my snippet. I never even thought about this in Sublime, but Atom is stopping me in my tracks every time.

Right now, I'm leaning toward moving the default from tab & enter to just enter so snippets are on a totally different binding.

At the very least, I'm okay with this. The default tab conflict is frustrating. If Atom is not willing to give tab priority to the snippet package, at least this would prevent frustration. Anyway, just my $0.02 :)

jesseleite avatar Sep 08 '15 18:09 jesseleite

Right now, I'm leaning toward moving the default from tab & enter to just enter so snippets are on a totally different binding.

To make things fun there's also some rational to only use tab, because enter is way too easy to accidentally type. https://github.com/atom/autocomplete-plus/issues/564#issuecomment-137279148

jeancroy avatar Sep 08 '15 20:09 jeancroy

In my opinion giving tab priority to snippets:next-tab-stop while in "snippet-mode" would be the best method. Other editors are doing it this way, too.

Maybe even a new option for snippet variables to enable/disable autocompletion?

For example:

'.source.php':
  'protected function …':
    'prefix': 'pfun'
    'body': 'protected function ${2:FunctionName:noautocomplete}(${3:$${4:value}${5:=\'\'}})\n{\n\t${0:# code...}\n}'
``

ManiacTwister avatar Jan 30 '16 13:01 ManiacTwister

This works for me:

'atom-workspace atom-text-editor.autocomplete-active':
  'tab': 'snippets:next-tab-stop'
  'shift-tab': 'snippets:previous-tab-stop'

clessg avatar Sep 17 '16 20:09 clessg

If I understand this correctly, this wouldn't be a problem if all snippets would show up in the suggested list, right? Because, in my case snippets are missing if they conflict with basic keywords.

For example: When I'm writing "def" in python, it only shows a generic keyword "def" but not the snippet trigger "def" which creates a function snippet. The method trigger "defs" however shows up.

fedario avatar Jan 16 '17 13:01 fedario

@clessg's suggestion worked great for me. Perhaps it should be the default?

msabramo avatar Jan 25 '17 14:01 msabramo

I agree with @kinari-01 - the snippets and autocompletes should be shown separately in the suggestion list.

grantstephens avatar Feb 06 '17 09:02 grantstephens

@clessg That seems like a band-aid solution. It would make much more sense for both snippets and autocompletes to be shown in the suggestion list.

helarqjsc avatar Feb 28 '17 07:02 helarqjsc